algorithmic modeling for Rhino
-=NIK'S ZBRUSH COMMANDER=-
Work in progress, but I wrote a little Python script that can command the astoundingly powerful mesh modeler ZBrush to operate on meshes from within Grasshopper. It takes some work to create a ZScript macro for custom routines, but you can record those in ZBrush and then merely need to edit them into my script, inline, as bulk multiple-lines you just paste in, no problem as long as you strip the ZBrush button definition at the beginning.
ZBrush has a very high initial learning curve because of its non-standard interface. However, it has the world's most powerful quad remeshing and now mesh Booleans too. I needed a replacement for slow and especially non-robust marching cubes (Cocoon/Monolith/Dodo/Aether etc. on Grasshopper) that tended to bog down or blow up. IntraLattice was a step in a good direction but it can't merge fattened lines that merely cross each other with no breaks or that physically overlap on purpose to have many curve on in to a hub. But with $800 ZBrush 4R8, the latest version, that I can create English language ZScripts for, I suddenly have, often in the blink of an eye, or at worst a few seconds, right back into Rhino Grasshopper, a perfectly joined, airtight and smoothed mesh blending of upwards of thousands of input mesh pieces that overlap in ways Rhino will never Boolean union.
There is no complicated installation of anything since it's all done in Python.
The ZBrush program itself pops up while it works, and is then automatically backgrounded to bring you back to Grasshopper. It keeps running though, for fast iterations with no program startup time.
This is a general toolkit to expose myriad very advanced features of ZBrush into being just another Grasshopper plug-in like the rest.
It works by accepting a Grasshopper mesh and writing it to disk as an OBJ file, then incorporates ZBrush settings for a given command into a text format ZScript file, also written to disk from Python based on Grasshopper inputs, then ZBrush is told to run the script via Windows command line, and the exported OBJ output is read back from disk back into a Rhino Grasshopper mesh, in about a hundred lines of code.
Despite a change in mesh definition in Rhinocommon from version 5 to 6, I made it work on both versions.
So far this is only one command, the newly improved mesh Boolean union. It gives quad meshes, but they still look healthy when quickly triangulated in Rhino (as seen on top, above).
The ZBrush ZRemesher is utterly astounding in ability to transform any mesh into a direction following, error free quad mesh that can be converted to NURBS actually, via T-Splines smooth mode. That will be the next port to Grasshopper. I hope architects pick up on this more orderly manner of patterning surfaces than the alien slime of random point Voronoi.
Commercial software has the best code, not open source stuff, so far, so this is serious work to bring world class tools into Grasshopper where we can rapidly prototype computational strategies.
Here is a thread with several examples of ZBrush Boolean union remeshing applied to 3D trusses, compared to both IntraLattice and marching cubes:
The same strategy of generating script files I used to port OpenFlipper, here, for triangle remeshing, which can now be combined with ZBrush Boolean unions of arbitrary assemblies of mesh units:
UPDATE: I revamped the workflow so now components feed raw ZScript into a sequencer. Then only a single ZScript is assembled and sent to ZBrush so Python never gets ahead of ZBrush (!):
I was wondering if is possible the "fixed ZRemesher model" to load back from zbrush to the existing GH/Rhino file.
Congrats for your hard work on this plug-in.
Great work so far!
I was thinking of this basic approach about your plug-in.
(I have to make my shelf clear...is just one idea/proposal not request LOL).
First to write a basic version of the plug-in like the GoZ for GH, to build a "basic" interaction between the two softwares.
With this way the users they can transfer there models to ZB and after they can made there modification inside ZB (remesh, divide, ZRmesher, nanomesh booleans etc).
After they can load back automatic the modified model to GH.
The difficult parts, is to build the code for the interaction between the two softwares, and to find out how to send multiple models to ZB as Sub-tools in ZB to work later as a parts for booleans or nanomesh etc.
At the bottom of the the page they mention:
"If you work with an application not listed above and want to add GoZ™ to it, please contact us for information on how to access our free GoZ™ SDK".
With this generic approach you don't need to build different toolS for ZRmesher, booleans etc.
Thanks for your time.
Thanks Nik, can't wait to spend some time with it !!!!
Big fan of the shadow box. Any chance that can become a component. Although, I think it may be difficult as it requires to draw on the box. ZB also has a quite nice array tool which seems could be implemented as sliders.
Holy crap dude! This is crazy cool!! We all know that booleans can be the bane of rhino's existence... Will be using this a lot, especially with the ability to quickly remesh.
Very interesting Nik!!
Thank you for developing it!!!
I think with all this research from your part, the step to ZB is to "polish" the GH model with Dynamesh etc, and you are ready to "bake".
I am right?
Something like the last path in the work-flow.
Because the way back to GH is almost impossible, with so big files from ZB.
Real amazing job.
I was thinking this scenario, but i am not sure about.
From ZB you can bake a normal map / displacement map.
I don't know if GH can read the normal map and to use it
for the render on the GH low-poly model.
Is just a thought.
Wow ，It’s a great
Dude, This is mind blowing!
I'm a Grasshopper and Zbrush user. I will give it a try when I'm home tonight.
One of the most useful tools for mesh modeling is Panel Loops. it would be a great addition.