Looking for some suggestions to solve or find a work around for a merge subtools issue I’m having.
I’m trying to merge 12 tools together that make up a character and his clothing. Each tool is set at 7 subdivisions (I need at least one of the tools at that level which ,as I understand it, means all the tools have to be at the same level to remain intact on merging)
I try and merge visible but The process quits halfway through giving me an error message:
Incorrect memory size in list-in Object:
I assume that the high sub d level is causing this?
I then tried to merge the tools several at a time but that threw up a different message saying Zbrush couldnt reconstruct all the subdivisions.
I did try the same thing on the remaining group of tools and this time it worked- the tools did merge.
Entirely possible. Most problems with ambitious high poly operations in Zbrush come down to not enough memory to do what you want, and this expresses itself in different ways from hangs to failed operations with cryptic messages. “7 levels of subdivision” doesn’t mean much in itself–a mesh with a 4 digit polycount to start will produce a much denser mesh when subdivided 7 times than one that was only double digit to start–but trying to merge 12 subtools at 7 levels of subdivision is definitely pushing things. Merging subtools becomes a more laborious process the denser they are.
There is a per subtool polygon limit, and an operation cannot result in a subtool that exceeds this limit. Even if each subtool only had 5 million polygons, trying to merge 12 subtools x 5 million polys will result in a single subtool with 60 million polygons! Even if that operation completes, it wont be much fun to work with that subtool on most systems.
However! I don’t see that particular error message much myself, so I won’t rule out an issue with one of your subtools either.
In any event, it’s easy enough to figure this one out. Duplicate your entire tool or work on a copy in a new file, and remove the top three levels of subdivision from each subtool. If you can now merge all your subtools without issue, then you know what your problem was. If you still get that error message, then we need to take a look your individual subtools for issues with the geometry.
Subtools exist to help users avoid having to cram too many polygons into a single live mesh. If you were going to re-combine all those subtools, it would generally be into a new fused mesh where the points of the individual subtools have been welded together. This will remove any overlapping interior geometry, and free up more polygons of your maximum potential to go to the surface of the mesh for the purpose of fine detail.
In order to keep from losing any detail when you reduce your meshes to make them more manageable in these operations, you may need to project the detail from an original high poly mesh, onto a more polygon-efficient fused mesh.
Thanks once again for your detailed and swift response Spyndel.
I have had some luck by leaving three of the subtools out of the merge for the time being, bringing the current total in at 21 million polys.
This suggests that the omitted subtools may be causing the issue; each of which have a morph target which was applied on their original import as obj’s (these were hard surface objects created as low poly objects in my 3D package.
I have found that subdividing imported hardsurface obj’s without this morph target changes the topology slightly from its original state (adds some smoothing).
Subdividing without Smt on leaves edges that are too harsh I find. There my limited experience ends!!
Simply merging tools with a Morph Target stored does not produce this issue for me, although you will lose the MT in the resulting subtool, as would be expected. I think it’s much more likely a polycount/memory issue on your system.
The act of subdividing a mesh with smoothing (smt active) with subtly alter a mesh’s form at all levels of subdivision. This isn’t typically much of an issue, except in regard to creating texture and displacement maps for pre-existing models/UVs in another program.
In this scenario, you would store a MT based on the imported mesh, and switch to it just prior to generating your maps (without changing subdivision levels again–this will alter your MT!). Otherwise you would be generating the maps for a mesh that was no longer exactly the same–a common cause of displacement issues.
If simply exporting the base level geometry from Zbrush directly and creating the maps for that mesh, there would be no need for the above.
