Here if there’s more than one UV group (regardless of whether they share space) you have to work on only one group at a time and it always outputs a mess. As it sees even the default polysphere as having multiple UV sets (even though it doesn’t), this makes for a pretty crappy time. After remapping with a “Spherical” projection from the Tool->Texture tab, the result is now that it outputs something that at least doesn’t look like a Jackson Pollock, but now has random artifacts, with “rings”, missing polygons, inverted polygons and so on.
Has anyone managed to get ZMapper to function with any of it’s presets.
Nothing has really changed since zb2. Try GUV or AUV tiles. The garbled mess is either because the mesh you are trying it on doesn’t have UVs turned on or the UVs are overlapping.
I am having a problem with ZMapper too.
I am using Z3.1 on my MacPro in VMWare fusion, and when I try to open a head model in ZMapper I get this error message:
“GL_invalid_enum”
is this an openGL problem with VMWare? Or am I just not doing it properly (quite possible, I am a noob with ZBrush. )
EDIT: this model has UVs laid out with Headus UVMapper, if thats of any relevance.
I am loving ZBrush as a whole though, it has made me neglect Maya recently…
Hi, yes the default polysphere in zbrush has a cubic mapping (ti is after all just a subdivided cube), there is no overlap, but zpbrush sees it as having two UV sets. Anything with mutliple UV sets results in garbage despite the fact that ZMapper only works on a single UV set at a time.
The second projection method (spherical) was done entirely in ZBrush with it’s own tools, it was in fact basically just a polysphere with just one stroke on it at the higher resolution, ironically this results in an overlap as zbrushes own projections don’t split correctly at the border!
I already have a very good UV editor in Bodypaint so it looks like i’ll have to use that however it means that anyhting involving multiple uv sets is out of the question with ZBrush. It would be nice if zbrushes own uv tools worked correctly from the off, and if it’s own default objects were correctly uv’d, and even nicer if zmaper was robust enough to not crap out if you have more than one uv set.
That is an OpenGL error message. ZMapper uses OpenGL so you need to check that it is enabled on your machine. I’m sorry I can’t be more specific than that.
mdme_sadie is right, this does appear to be a legit issue.
In zbrush 2. you could have multiple uv regions and zbrush would only calculate the uv region being displayed by the corresponding portion of the mesh that you had displayed. But in zbrush 3.1 it doesn’t do that. Any mesh that has multiple uv sets will not calculate a correct normal map, it comes out all jacked up.
I’m working on a game model that has mirrored, overlapping UVs. That could be the problem. I didn’t use Zmapper for ZBrush 2, so I’m not that familiar with it. I can create normals for it in Modo or XSI with the UVs laid out this way.
I have a character I’m creating. The base mesh was made in Maya 8, sculpted in Zbrush3. I tried to reconstruct in in Zbrush 2 so I could use Zmapper but it messed up my Uvs. So I redid the UVs and to wait for Zmapper in 3.1 cos I wasnt too pleased with the displacement Xnormal results.
When I tried Zmapper 3 it exploded. I took it down to the lowest subdivision, transfered the uvs from my low-poly model in Maya to the imported OBJ. It transferred fine.
Imported the OBJ back into Zbrush went up the subdivisions, it worked fine, no explosions, but as soon as I took it into Zmapper, it explodes if I try the high res preview , and if I try to create a normal map, I get a mess.
I did try using automatic mapping on the Zbrush OBJ and that worked fine but that implies that I’ll either have to redo my uvs for the millionth time, or try another method for creating the normal map cos Zmapper does NOT like my model! :mad:
It’s an OpenGL message. Essentially Zmapper is using higher level GL functions than can be supported by emulators. Right now bootcamp is the only solution. As for me, as much as I love Z3, I’m doing more in Modo 301, which has a pretty nice sculpting set. (I like that I can directly sculpt my mesh, displacement, and bump maps at reasonable poly counts.)
It’s simply getting too frustrating to be a Mac Z3 user, but I think Pix has made their interest in the platform well enough known by now.
I can defend Pix all day long, but the disappointement with the latest Zmapper is close to the last straw for me. If I have to keep doing my baking in other tools, I might as well use Mac-native solutions like Modo, Silo, etc.
It’s sort of clear to me that Pix didn’t even bother to test Zmapper in the emulators like Parallels and VMware, and and to me that speaks volumes about their commitment to the Mac platform.
]