Seamless link from Rhino to Blender. Even on a mac

The 3dm import plugin from @nathanletwory already brings Rhino and Blender very close together and I would like to go a bit further with this free rendering solution, the transfer should work somehow like with Keyshot - Screenrecording

There seem to be many simple ways to do this. But Rhino for Mac never fits with a solution.
It is way harder than I expected to finde a solution. I need some help to find the right way.

Are there any other simple ideas how to this like Keyshot?

It should be possible to do some sort of socket communication between Rhino for Mac and Blender. With the rhino3dm module I see no clear obstacles to do that.

I’d suggest building on 3dm_import so that you’d reuse the data handling parts and then a client listening to a server thread running in Rhino. Whenever that data server in Rhino sends something it’d be with the fileformat serialized in the same way as Rhino Compute would do. Then have a simple protocol to signal the Blender client there is data, and send that data. Receive essentially the same way you would a Rhino Compute response, except you get directly data which you’d decode.

Actually.

I just wrote a C++ sample for the ChangeQueue - and this is actually something that could also be used for this kind of automated link between Rhino and Blender, written in either C++ or a .NET language:

Essentially you’d spin up a ChangeQueue that lives for the duration of the link (or why not just for the entire duration of the Rhino session…) and listens to notifications by the changequeue mechanism. Each time a change is made you’ll be notified (BeginNotifyChanges + EndNotifyChanges) so that you can handle them (Flush). This works the same in either language.

Whenever you’ve received the data you’d prepare it to send to Blender with the protocol of your choice - a local socket would work fine (TCP, UDP). Use the opennurbs encode/decode mechanism as used by Rhino Compute together with rhino3dm to handle on Blender’s side…

edit: and yes, the ChangeQueue also works on the Mac (the Raytraced mode uses it…)

Thank you very much, sounds good. But I can’t follow you everywhere yet.

Until now I had planned to transfer always all Data: (the meshes and materials) to Blender.
Blender then compares by name and type what needs to be created, kept or updated.
(Has worked for me in small tests with a few changed lines in the Blenders OBJ Importer already well.)

I would love help to do this with 3dm_import. But I can’t follow you here for now:

Whenever that data server in Rhino sends something it’d be with the fileformat serialized in the same way as Rhino Compute would do.

At the moment I assume that rhino3dm basically needs the saved .3dm file. And 3dm_import therefore also depends on it?

Maybe I need a better understanding of rhino3dm.py development. And from Rhino Compute I just get to know for the first time.


The ChangeQueue way is overwhelming for me. I think it’s enough to just transfer everything that is available. And in Blender the procedure is decided with the data. Keyshot is not very intelligent here either: Overwrite Mesh - Keep object position and material - thats it I think (Nothing is deleted, for example.) But it still works so well when you’re working and rendering.

The changequeue is a great mechanism for getting all the mesh data, lights and materials out of Rhino, preprocessed and all. It also handles block instances properly, something that will enable you to set up instancing properly in Blender.

The changequeue also will help you in detecting changes to the model in Rhino without having to first save the file and then hope some filewatcher fires at some point.

It is trivial to set up that part in Rhino.

There is no requirement to have a saved file. As long as you get data in some way to Blender that the rhino3dm module understands you have all you need. I actually unnecessarily mentioned the compute module, since rhino3dm module by itself already knows how to encode and decode Rhino data blurps so it can be easily sent over socket communication.

Sure, you can do that. And with the changequeue running you’ll have indeed that initial burst of all data, but while the changequeue is running in Rhino it will then only need to send what has changed (meshes, materials, lights).

My point is that you can have a mechanism that handles all data for you. And on top of that allows you to handle any changes made to the model while they are being made. This technology works great - it is how Raytraced (that is the Cycles engine) is interactive in Rhino viewport. It is just important to realize that the changequeue technology isn’t limited to the viewport…

This would allow you to create an even more seamless link that using file import/export via disk where you have to deal with the discrepancies between three file formats instead of just two, not to mention the file writing and reading overhead for the more complex models.

All right, that sounds wonderful.
I’m going to approach it that way. It will only take a little while. :slight_smile:
Thank you very much!

Don’t forget to pick my brain. I gladly help out where I can.

1 Like