It seems like Gob crashes Blender with the currently 3.0 nightly. I tested it with 3.5.52 and .52
I wish there was an option to disable the live import, and make the import as one click like the export is. This becomes a dilemma for the add-on when there are multiple Blenders open with import enabled.
the automatic import is using a app timer which checks the timestamp of the goz exchange file, if that timestamp changed then it will start pulling the new content.
Please help. I’ve got deadlines to meet, and I’m running into a major problem with GoB version 3_5_52 running on Blender 2.93 LTS on Windows 10 x64. I’ve used GoB and ZBrush for many years and never run into this issue. What is happening is that I Imported a full character model from ZBrush into Blender on the lowest SubD level (via the GoB plugin), then spent hours getting it fully rigged/skinned and weight painted in Blender. Once I modified the pose of my character in Blender, I tried to Export the posed model back to ZBrush (again via GoB). However, every time I click the GoB Export button, it changes the filenames of every single object selected, removing any periods in the object name and replacing them with underscores. I named the object with periods in their names (example “Arm.R”) so that I can take advantage of posing/rigging symmetry in Blender, as this is the naming convention typically used. As you might have already guessed, GoB changing the filenames on export means that the objects are not recognised correctly back in ZBrush, and so it sends the objects as new subtools, meaning I lose all of my original subdivision levels on the imported objects in ZBrush. You can see in the image below what is happening. On the left are the original object filenames. On the right are the filenames which are changed once I click the GoB Export button.
this is a zbrush limitation since zbrush can have “.” in the object names as far as im aware and this limitation has been there since the early versions. Because of that the objects are renamed before sending them to zbrush.
Can you show the names in zbrush for your scene before you send the meshes to blender?
maybe something could be implemented to export and import in blender with a specific pattern so the names in blender will not be modified, however it can not export with “.” in the names since zbrush does not allow that.
EDIT: i just noticed that this is only true if there are not more than 1 tool if a subtool is added the names can contain a “.”
I will have a look how this could be solved
@JTenebrous
i added a option to enable the export of the raw names, i tested it a bit in zbrush but it seemed to behave a bit strange. maybe give it a try and see if it works for you. https://github.com/JoseConseco/GoB/tree/export-raw-object-names
You need to enable this option in the addons preferences:
@kromar - you are a legend, mate! This “Export Raw Object Names” has pulled me out of the fire here. Everything in the test fork above worked for me on the first go. I totally realised after I sent that message on Friday that, of course, older Zbrush versions certainly couldn’t have “.” in the filenames… I’ve been using it since 2005. I think the ability to have “.” in the filenames came in maybe the 2019 or 2020 versions when they finally added the ability to have multilanguage support, etc.
So, yeah, it may be relevant to keep the “Export Raw Object Names” as a checkbox… but also, enabling it should probably become the default since ZBrush has probably supported these additional characters for at least 2 years now… so the checkbox would only be relevant for older builds (or so I imagine!). Also, per your request, here is an image with the subtool names of my ZBrush file (many containing a “.”). The point is that, when these filenames are synchronised in Blender, the back-and-forth transfer of posed characters works as expected now, maintaining subdivision levels, polygroups (from face groups), etc.
location: <unknown location>:-1
Error: Python: Traceback (most recent call last):
File "C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\GoB\GoB.py", line 1237, in invoke bpy.ops.scene.gob_export(as_tool=as_tool)
File "D:\App\blender-Release_2.93\2.93\scripts\modules\bpy\ops.py", line 132, in __call__
ret = _op_call(self.idname_py(), None, kw)
RuntimeError: Error: Python: Traceback (most recent call last):
File "C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\GoB\GoB.py", line 1165, in execute
self.exportGoZ(PATH_GOZ, context.scene, obj, f'{PATH_PROJECT}')
File "C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\2.93\scripts\addons\GoB\GoB.py", line 876, in exportGoZ
goz_file.write(pack('<H', groupColor[map.value]))
IndexError: list index out of range
location: D:\App\blender-Release_2.93\2.93\scripts\modules\bpy\ops.py:132
location: <unknown location>:-1
glad to hear it worked out:D
During the testing i noticed some issues with the . in the names when you do not have subtools so until that can be ironed out it feels very unstable to make it the default. However i agree it should become the default once its not creating some random names in zbrush as i experienced.
Thanks for the update. I still get the issue with the file I attached in my post after your fix.
location: <unknown location>:-1
Error: Python: Traceback (most recent call last):
File "C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\GoB\GoB.py", line 1253, in invoke
bpy.ops.scene.gob_export(as_tool=as_tool)
File "C:\blender\3.0\scripts\modules\bpy\ops.py", line 132, in __call__
ret = _op_call(self.idname_py(), None, kw)
RuntimeError: Error: Python: Traceback (most recent call last):
File "C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\GoB\GoB.py", line 1184, in execute
self.exportGoZ(PATH_GOZ, context.scene, obj, f'{PATH_PROJECT}')
File "C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.0\scripts\addons\GoB\GoB.py", line 895, in exportGoZ
goz_file.write(pack('<H', groupColor[map.value]))
IndexError: list index out of range
location: C:\blender\3.0\scripts\modules\bpy\ops.py:132
@kkar i pushed another change. it was a bit a strange one it looks like the mesh has some face map information’s even when no face map exists on the object.
let me know if you get another issue with that version. (use the last link to get the new version)
In version 3.5.52 I was getting Blender undo freezing and other app instability. I tracked this down after restarting with a new Blender install and reinstalling addons until GOB broke it.
Version 3.5.55 is working fine but I wanted to point it out in case it’s possible to avoid that in new releases.
@Syance that is potentially fixed in 3.5.55 however there are reports of the import toggle breaking in blender 3.0 so maybe that is related to the instabilities you mention.
Thanks for raising the awarenes
I am unsure if it is known bug but version 3.5.52 breaks cloth caching. Behavior goes like this:
Simulation seems to go much faster than usual.
Somewhere arround 1s (frame 50) mesh goes into -1e10 scale.
2.1 if simulation is complex blender crashes.
When turning off the addon in preferences or via workspace filtering chaching works normally.
Also not sure if it’s the problem with the addon but more complex simulations seem to break the blender while addon is enabled.
