Adding GoZ to Rhino now make much more sense

Thanks for the suggestions… I added your comments to the feature request.

This is an excellent idea; I know several people that have been praying for this to happen for a long time, myself included. It would make working between Rhino and ZBrush much easier and more efficient. I use a similar bridge between Rhino and Keyshot, and it improves the workflow tremendously.

This works like GoZ a bit. The export-import mesh between apps. I’ve used that between Modo and Rhino but I’m sure it works also between Zbrush and Rhino. I can`t set up it as a GUI button yet but it works as a script. It supports more software than only those three.

2 Likes

thanks
trying to test it, in the rhino paste script I get an exception

Has it worked on your machine without this issue?

thanks a lot
Akash

I’ve seen that you have made the script file by yourself. Maybe you have pasted it wrongly. Grab my files. I`ve tested it with Rhino 7 Beta and Zbrush 2021.1.2. All works fine. Remember that amazing plugin works also with Blender, Modo and Houdini.


Rhino_CopyToExternal.py (882 Bytes) Rhino_PasteFromExternal.py (2.2 KB)

Maybe someone smarter than me will do some button in Rhino for that to be easy installed after updating. I would have to get those two scripts as buttons all the time in Rhino. Even after updates.

1 Like

Great in theory but the practical side of this can fall into an area that would challenge Rhino in that the mesh geometry coming over from zBrush, not on all models, could be a bear for Rhino to try and handle. People have been known to not really watch their polygon count and run into the millions when they’re making models. The decimation master is amazing but it then brings the mesh back from quads to a tri-mesh.

The back and forth would be great to have…I’ve already run some simple test cases of mesh - Quad - Sub-D - Polygons/NURBS… wasn’t the best of results but maybe there are some areas of finetuning that will be ironed out in full Rhino 7.

Hi Arthur -

Please start a new thread with an example of something that isn’t working for you.
-wim

Before moving some high polygon mesh from Zbrush - decimation master, Zremesher or Dynamesh with lower settings is a must.

But there is also another possibility. When you will create some higher polycount (thousands not millions) mesh in Rhino and you will move it to Zbrush to sculpt it a bit and do Zremesher there and come back later.

I’ll start a new thread…and title it “Adding GoZ to Rhino part 2”. It’s not so much that I’ve any specific problem but there are definitely a few workflow challenges which are very much specific to the intended outcome that’s needed.

Thanks for the feedback, I added your vote to the open feature request (RH-56606). I don’t know when or if this will rise in priority though.

I personally have used this workflow a number of times on real projects and found it works very well with obj export for each object I wanted as a tool in ZB. Then append these as sub tools once they are dynameshed and (live)boolean as needed. Polygroups also come back to Rhino as separate meshes which can be handy or avoided if you merge them first. I will also use decimation master in ZB first and sometimes also ReduceMesh in Rhino after that too to merge planar areas.

Of course, making a more direct link may save some time and add features so once the developers have time to look into it they will.

With the help of a number of people here, I ended up with this Macro:
! -Export Pause GeometryOnly=Yes SaveTextures=Yes SaveNotes=No “/Users/akash/Zbrush Work/FromRhino.obj” VertexWelding=Welded YUp=Yes Enter DetailedOptions AdvancedOptions Angle=0 AspectRatio=6 Distance=0.0005 Density=1.0 Grid=0 MaxEdgeLength=0 MinEdgeLength=0.0001 EnterEnd

And if it was a subD object then it can usually be directly worked on in Zbrush. It comes in very cleanly as a fairly dense quads. [Just hit the command+D a number of times to add up devision levels]

for the way back to Rhino. the best way I found by now, is to send a decimated version. [perhaps a million poly at most] Lock it! and make no attempt to edit that mesh in Rhino.
I’d imagine a stronger computer will be more responsive…? My old machine can manage a 10 mill poly object in ZB easily. Yet in Rhino 1 mil poly is already too much for it.
there for the ZB mesh in rhino is used locked while creating additional parts. Then these parts are exported to ZB for Live boolean, and the sculpting work.
The finished part decimated and exported as .STL, I’ll again open in Rhino to verify all dimensions remains as intended.

Would Love an easier quicker way, but I think the main thing here is about how Rhino is poorly handling high poly mesh.
and the ZB with will be to be able to import rhino Curves converting them to ZB curves [to use with the power of Curve brushes].

with best regards
Akash

Hi Akash,

I have made a grasshopper plugin to optimize the workflow between Rhino & Zbrush:
https://www.food4rhino.com/app/chameleon

Chameleon - Zbrush Live Link Tutorial from Marc Gibson on Vimeo.

Hope this helps!

Cheers,
Marc

It looks very nice on F4R. But it’s marked as Windows only…?
Being on a Mac here. Any chance this may work if packed, as is, into a Mac installer ?

with thank
Akash

@MWG This is pretty amazing. How are we able to do manual sculpting edits in zbrush pushed back to rhino?

Hi Mark
I thought to give Chameleon a try on my Mac even as it is only listed for Windows…
It all seems to works without an issue in GH, I followed your excellent tutorials but unfortunately it won’t run ZB…
I have a feeling it is [only] an issue with the link, as I’d imagine the Zscriptes will be identical for Win and Mac…?
Running ZB 2021.5 here on Catalina and Rh 7.2.

Separately, are you thinking of adding the new Dynamics simulations ?

thanks a lot, it’s very impressive and interesting, I hope I’ll be able to work with it eventually.

With best regards
Akash

Maybe there’s a way to list the path that the Solution component accept…?
Or does it only likes .exe ?
image

Hi Akash,

Thanks for letting me know - I haven’t tested on a Mac (I don’t have access to one at the moment) but am open to working out a solution once I can get my hands on one. I am not sure how well it will translate in the component’s current state. Does it still write out the Obj and Zscript files?
It is currently set up to call the “zbrush.exe” file however I can update this to be filetype agnostic in the next release.

Thanks for the suggestion regarding the new dynamic features - I am definitely keen to incorporate some of the new commands that Pixologic has introduced.

Hi Mendler,

One method is to just use the “ZB_Send” component without the “ZB_Receive” component - this will allow you to send your geometry to Zbrush without forcing it to return to grasshopper straight away. You can then duplicate a second ZBIO component with just the “ZB_Receive” component plugged into the Zscript input and a button plugged into the “Run” input. This will allow you to click the “Run” button to pull geometry back into grasshopper once you’re done sculpting.

Hope this helps!

Thank you Marc

Yes it does, so it is ok with using the Mac file-path system, It really only feels like the issue is just as you wrote:

I will be really nice and kind if you would update the file type.
There could be other issues, [hopefully not] that I can’t see without having the ZBIO component first accept Zbrush.app.

Thank you very much.
Akash

:slight_smile: