Just tried out the latest version of your (@nathanletwory) importer and I have to say it’s coming along really nicely!
Until now I had a clunky self written exporter from Rhino that spit out objs and an accompanying txt with layer and material infos and the correspondent Blender importer that imported the objs and pushed them to the respective (child) layers and materials… Pretty inelegant!
Now this is pure joy! Directly importing 3dm files! Incredible!
Now I’m looking forward to the addition of the Material Table to rhino3dm.py!
(Not there yet as far as I can see - just checked with a newly built version )
As far as I understand there is no texture mapping support included yet - or am I wrong? Probably another part that needs to be added to the module? Or would that also be a task for Compute?
I tried to get to such a static object update with my clunky exporter/importer scripts but I failed to undestand how one would find out if an object was changed since the last export. Do you have an idea how to do this?
Maybe a first step in the direction of an automated transfer would be the ability to set a fixed 3dm filepath where new/changed objects are being pulled from whenever a certain “Update” button is pushed?
And as soo as materials can be handled ( ) it would probably also be very useful if one could decide if materials would be replaced with incoming ones of the same name or not. Maybe a global setting “Replace all” / “Ask for each incoming duplicated material” / “Never replace Materials”…
Oh sorry, my imagination takes me away on this… Very Exciting times ahead
Thanks for the info @stevebaer! As I managed to get my local build working I have to say I’m getting quite used to it inbetween
But I’m sure the pip install will be of great value at a certain point!
Thanks for keeping the API up to date as well!
I’m not even sure what this really means If I were to guess, I doubt we are going to do anything like this in the near future. There are plenty of other technologies we are working on to keep us busy.
There are two parts to this issue: the high level data describing the mappings, and the uv coordinates plus (baked) textures for mapped objects. The first we should be able to just read from the 3dm, and when render meshes exist possibly also the uv coordinates. Baking textures will always have to be done by Rhino, unless you want to write the code to do so yourself.
The current idea is to track object and material IDs and record them in custom properties on Blender IDblock data. For materials I’d use a name and render hash combination. For layers probably also just the ID, maybe also name.
@mnewberg This certainly tickles my own interest, I’ve worked with a protocol called Verse before, and doing something like that (collaboration protocol) again always has stayed with me. I don’t know if and when I have time for that, but I’m certainly interested,
All of this is really great. Really cool to get direct .3dm importing into Blender.
This is geared more towards rhino3dm.py: the API doesn’t seem to expose document settings, unless I have missed it somewhere. This is particularly important for things like getting the units of the Rhino file, in order to scale it correctly in Blender. Are there plans for this or is it not part of the scope of the .3dm?
@tom_svilans not everything is wrapped yet, still huge parts missing. rhino3dm.py will be evolving rapidly in the coming time. import_3dm for Blender will be adapted to accomodate for new supported API as it comes available.
As far as I understand, the importer brings MESHES from Rhino to Blender.
Could there be a way to import NURBS as well? How far away is this possibility?
I am working in the Automotive Design business.
We mainly use Alias and Maya. One can exchange files between them, wich is the main reason to stick to Maya. To be honest, I am not convinced about the development of it.
That makes me interested in everything that points in the direction of a substitute.
What would also be really interesting is how you plan to handle blocks and group hierarchies. It’d be great if there was an option to convert them to group instances. To me, one of the main reasons to stick with one of the major software combinations (ACAD/3DSMax, Vectorworks/C4D, etc.) is to get proper object hierarchy and layers over from CAD to a modeler, so you’re not left with a pile of unsorted meshes and all blocks exploded to individual meshes. Of course you can always go through 3rd party apps to convert filetypes, but thats not exactly what i’d call a workflow (Change, export, convert, import, adapt textures etc…).
Rhino.io for C4D worked quite nicely, maybe thats worth having a look at. They even had some file update capability, but i wonder if that is not owed to C4Ds file merge option and not the exporter…
Importing NURBS directly from Rhino to Blender would be fantastic.
That should help me skipping a couple of very time consuming work steps and maybe getting rid of Unity now that EVEE is coming along.
Hi Nathan,
I just stumbled over this Thread !
Having a direct Import inside Blender.
That Sounds really Great!
I would Love to try
Where can i get this?
Is this for 2.7 pro 2.8?
)
) it would probably also be very useful if one could decide if materials would be replaced with incoming ones of the same name or not. Maybe a global setting “Replace all” / “Ask for each incoming duplicated material” / “Never replace Materials”…
Verse both way would be something superbly interesting