Hi @dale,
yes, I had the Community version of Visual Studio 2017 C# installed and extended it today with the C++ package. Is there maybe any additional package I need to have installed?
Hi @romio82,
That’s probably the case. I have Visual 2017 Community installed on a box next to me, and it builds the Python library just fine. Re-run the Visual Studio Installer and make sure to check this C++ stuff.
– Dale
Yess, thank you @dale, this was the decisive input!
I installed the packages you mentioned, deleted the local repo and cloned a new one and now it builds!
I still get an error at the end of the building process but the needed files work well with Blender.
Thank you @dale, @stevebaer and @nathanletwory for your help!
I also tried your Importer, Nathan, and it works really well already! Of course it needs some polishing here and there and the functionality needs to be a little extended (Layer Names, Cild Layers, Material Names and maybe Diffuse Colors at first would be important first steps in my opinion, but this is not yet supported by rhino3dm.py), but it’s a great first step which opens up lots of possibilities!
I will try to work myself into this and see what I can contribute… Is there a simple way (apart from dir()) of finding out which Properties and Methods get added to rhino3dm.py?
Great to see the first version of the .py API online yet! Is this going to be extended constantly while new properties get avaliable?
Ah, amazing times ahead! Thank you all!
@romio82, note that a lot you mention isn’t possible yet, as rhino3dm.py doesn’t expose everything needed yet: layers (working on that now), materials, lights, etc. But you knew that already (:
Yeah, I knew that… But not yet doesn’t mean never, right? 
Btw. I think it was me who lifted the veil of secrecy on your work.
Please excuse me if that was too early!
As I said before, it was all just too exciting 
no worries
That is the plan. This is also going to be the best place to find what properties and methods are available.
Nested layers are a fact
1 Like
I just published the 0.0.7 version of rhino3dm.py to PyPi so you should be able to just pip install --upgrade rhino3dm now.
Very cool guys. Any plans to deal with bidirectical changes? So if I make a change in the Rhino file it shows up in the host app (like Blender), and if I add any geometry, edits, attributes in the host app’s Rhino layer, it then is written back to the 3Dm file, and I can continue with that updated file in Rhino? …because static imports are real-time time obsolescence.
1 Like
Perhaps at some point - at least automated update from Rhino to Blender. @ejnaren essentially asked something similar, albeit in the static mindframe: update existing objects after (re-)importing the same 3dm file.
I suppose the other way around could be possible too.
Best would be to create a 3dm server to which any client that implements whatever the protocol/API the server provides. An interesting idea, but until then I’ll have at least the static import/export to hash out the code to handle the data (:
If you need more advanced and custom bidirectional workflow check the amazing project by dimitrie stefanescu : https://speckle.works
It might help you. And dimitrie is also amazing at support. Just like @nathanletwory wink wink 
I’m so confused. I though the whole point of RhinoInside is so people who work using different tools can also use Rhino and the work can continue to evolve in all these einvironments. That’s THE problem to solve in my opinion.
Having a way to create immediate obsolescence by importing a Rhino file to app A, and now this Rhino file cannot be further edited, or even continue to be referenced in app A, let alone app A and B at the same time, seems to be an odd choice. I don’t understand what problem this solves, for who. Having an importer called .3dm vs .fbx? Why? …there’s got to be another reason, right?
That is fine.
rhino3dm isn’t Rhino Inside, but rather part of the Rhino Compute deal. For RhinoInside Blender would need a .NET API - it doesn’t.
What we can try is to leverage the Rhino Compute part and make it so that we get better integration of the two tools using these new libraries. Right now I use only the rhino3dm.py package, but that is purely for reading. The next step is to also add the compute part, such that we can utilize the Rhino core for things like meshing breps, meaning one wouldn’t have to ensure saving a 3dm with render meshes in it.
Further in the future I’m sure I can come up with ways to make this all more automated, data transfer between the two using the Python modules we have now available, together with the compute technology.
Now, a .fbx vs .3dm is big in the way that we don’t have to rely anymore on an intermediate format. These extra steps are where often data loss happens, and in most cases makes it really hard to keep data linked to each other making interop a costly process.
Already the importer I wrote, despite the fact there are only few lines, gives much better control over how and what data is used.
I agree that we should work towards fluent interop that just works in all directions. These technologies and libraries will help a lot.
It is just that the fancy names and technologies Rhino Inside and Rhino Compute in and of themselves aren’t magic. We need to apply them with the necessary effort.
I see, this is just the plumbing. The running water is not there yet. Got it. Thx!
I sort of know where the water is, but since I’m no geologist, nor mechanical expert I’ll just have to do some random drilling and hope for the best.
I do think though that with every hole drilled, every pipe fitted, I learn more, theoretically increasing the chance for success and total world domination.
Reminds me of this…
And this…
I’ll never understand your industry.
Gustavo, this post is listed under rhino3dm and is not part of our Rhino.Inside project what so ever.
Oooh. Then yeah, I was very confused. I thought it was all the same things. That makes more sense now, well… at least it makes more sense that it didn’t make sense to me. Makes sense?
1 Like