Blender 3.2 Experimental .obj import and Mirror X axis for GOB

[loresuto]

I'm using GOB 3_5_66 with Zbrush 2022.0.5 and Blender 3.2.

Is it possible for GOB to use the Experimental .obj importer available in 3.2? I'm not sure how GOB handles the import of .ztl files from Zbrush, but if it does use the .obj importer, the new one is so much faster.

When I select "Flip up axis" and "Flip forward axis", the model is incorrectly mirrored in the X axis in Blender. Is there any way to have a "Mirror X axis" check box so the two apps will match in orientation?

Thank you!

[kromar]

the thing is that zbrush uses they own .goz format for exporting so it would require a new gob ui in zbrush to handle the exporting with a custom format. And that comes with a lot of effort.

Can you make a ticket for the flipping issue with some examples so i can reproduce what you experience? the default should match in orientation so i would be interested to see what is happening for you.

[loresuto]

The exporting of the .goz from Zbrush is very fast. It's the import into Blender that takes a long time. Do you know what Blender/GOB uses to interpret the .goz format? I wondered if "behind the scenes" Blender was translating the .goz to a more standard format, like .obj, on import.

I tested an .obj import of a hi-poly model created in Zbrush, and it took about the same amount of time to import (about 80 seconds) as when I use GOB to transfer from Zbrush to Blender. As a comparison, the new experimental .obj importer in 3.2 was under 10 seconds.

I'll make a demo and ticket of the flipping issue.

Thanks!

[kromar]

no the addon ins extracting the goz file but im aware of some things in there that make it really slow. You might be able to sped it up if you dont need certain data to be imported and disable it. Im aware that UV and polypaint is quite slow.
Im aware of certain things that could be done to improve the speed and would like to tackle this but there are some other issues that need to be done before this and i dont have to much time nowadays to work on the addon.

you can enable the performance debugging which should print some timers to the command line so you can see where your import spends most time and try to disable what you do not need. I noticed that its not possible to disable polygroups at the moment which should be simple to add, i will see if i can add that option to avoid spending import time if not required.

[kromar]

i added a option to disable the polygroup import as well if you want to give that a try

v3.5.74
https://github.com/JoseConseco/GoB/archive/refs/heads/master.zip

[loresuto]

Woah thanks! Polygroups are indeed the biggest bottleneck.
I'm using a 7 million poly model from Zbrush. The mesh takes about 20 seconds, the Polypaint takes 27, and the Polygroups take 58!
Since I generally only use Polypaint, disabling everything else helps quite a bit.

Still, the transfer is relatively slow compared to the Zbrush to Keyshot bridge, which I usually use for rendering. It transfers the same model into Keyshot with polypaint in less than 8 seconds.
So I wonder what the bridge is doing differently than GOZ that allows it to transfer so quickly?

[kromar]

There are a couple of reasons, first thing is that its not a native implementation so python comes at some cost, however from what i seen the main bottleneck is currently the way the data is pushed into the mesh container in blender, that seems to be very slow the way its currently done with the addon. Since lots of features have been added over time to the addon some things loop multiple times to assign data which costs a lot of time as well.
Im not a expert in this so i dont know how much faster i can make it. That however will need to wait a bit due to other issues.

[loresuto]

What would it take to make it native vs. python? Is that even possible? Are you the only one working on this addon currently? I would have thought that Pixologic would have developed GOZ for Blender years ago, but now that Maxon has bought them, I can't see that happening.

[kromar]

Since it uses a proprietary format it will not be accepted into the blender code base so it would be a custom blender build. Then it would be implemented in C i assume which i have no experience with. So yes its possible but it will be a lot of work for someone with C and blender coding experience.
Yes im the only one working on it for a couple years.
It would have been great if Pixologic would have implemented it, im not sure why this never happend, maybe also due to licensing issues.

[loresuto]

Thanks for your continued development!

[kromar]

i started to do some improvements to the import, starting with polygroups and could already cut off a significant amount of time. This is not yet where it could be so i will keep chipping away on that import time. There for sure is a lot more potential to make it faster but comes with some bigger refactoring and will take some time.

If you want to test what im doing you can use this branch (note it can be unstable at times): https://github.com/kromar/blender_GoB/tree/performance-tests

[loresuto]

That's great. This version would still be (much) slower than just disabling polygroups in the last version, right? I only use the mesh and polypaint from zbrush.

[kromar]

Yes its still slower, i just focused on that first since it was very slow. I seen a couple of other things that are slow so i will try to improve those and that would make it faster without the polygroups. I let you know when i suceed in that