ZBrushCentral

important difference between different ways to export OBJ?

ZBrush Usage Questions
#1

I’ve been trying out marmoset toolbox and since it supposedly supported high polycount objects, i tried a zbrush model , 400.000 poly. (not even that much).

If I use the export button under TOOL , marmoset crashes on the obj until I decimate it to be under 150.000 poly’s.

same thing with the export button from the multi map exporter plugin that also exports an obj

but if I use the 3d print exporter plugin , I don’t even have to decimate , if I select obj format from this plugin and load it into marmoset , it loads fine. Luckily it seems to also keep UV’s.

So it’s not really a problem, since i’ve found a workaround to do it, but what does the 3d print exporter plugin do so differently from the other 2 export methods that makes it not crash marmoset toolbag.

#2

The problem is that marmoset likes triangles. A decimated mesh and a mesh for 3d printing is triangulated.

#3

I don’t think that’s the case. Marmoset likes quads just as much as it does triangles (even if it automatically triangulates, as every game engine does), and the exported OBJ from the print exporter doesn’t triangulate any more than the default exporter.

The obj files themselves are greatly different in structure (if you open them with notepad) and filesize. The obj exported by the print exporter looks pretty much identical to what a standard 3d program would create (aside from the comment lines), while the default zbrush obj format looks like a complete mess of numbers by any comparison.

The latter also includes few non-standardized changes applied to it in order to support zbrush specific information (such as polypaint), and at the same time it omits data that it doesn’t use, a result of how it treats models differently than other programs (things like smoothing groups/vertex normals; stuff that an engine like Marmoset would care greatly about). I’m guessing it shaves certain things in order to help keep the filesize down, but it could place the burden back on the importer as it would have to reinvent whatever information that program requires. It’s possible that Marmoset can do this to an extent (under 150k or so as you might have noticed), but past a certain point it just becomes too much to handle on top of everything else it has to juggle (in the same way zbrush might struggle if it has to calculate uvs on larger meshes). That, or the difference in how the OBJ file is written might just be enough to give other programs a headache on its own.

#4

The 3D Print Exporter does three things when exporting OBJs, as far as I can tell:

  1. It offsets the model from the origin.
  2. It scales the model.
  3. It only exports groups when combining subtools.

Of these the only thing that seems likely to be causing Marmoset problems is groups. If you export an OBJ from ZBrush then the faces for each group may be split between different parts of the file. If Marmoset assumes that all a group’s faces are in a single block in the file then that will be what causes the problem.

Incidentally, there’s no requirement in the OBJ format to group faces together. If a program can’t handle files like that then it’s not robust.

#5

yeah , I guess since marmoset only handles high poly meshes recently, they haven’t considered complications with groups.

Tested up to 3.000.000 polys now with the 3d print exporter , imports fine , but that’s when my performance in marmoset starts lagging a bit, but that’s fine. I