What happened to Zmapper?
The functionality is reportedly built-in now.
where?! All i see is one normal map dropdown in the tools menu. What about all the other options that were in zmapper?!?!?!
What are you trying to do you can’t do in the current Normal Map generator?
-K
First, where is the pixel padding in the polypaint drop down?? I’m guessing it’s the UV map border option now? Why is it only allowing a value of 16 max?
Second, Zmapper was fast. I’m not sure why but the normal map baking in 3.5 is a lot slower on the exact same .ztl. Our studio was also able to view the baked out map on the lowpoly without having to go through any extra steps. What is the workflow for viewing your lowpoly with the baked out normal map??
Third, and a BIG issue…why in the HELL are the .ztl’s opened in 3.5 not backwards compatible with 3.1. This kind of sucks, especially when you find out after the fact and didn’t have a backup copy of the .ztl.
I’m not sure that backwards compatibility has anything to do with Zmapper. 
There are many new functions in Zbrush 3.5 and I’m sure the file format changed. This is not unique to ZBrush, most applications with a significant upgrade can’t open newer version files in older products.
The normal map generator has some key new features, including the often requested feature to generate maps from HD geometry. That re-write probably accounts for any speed differential. The openGL preview was not always accurate to how a normal map was displayed in other engines and renderers, limiting its utility. GoZ, when its released in a few weeks, will restore some of this workflow as maps will be carried over to the enabled application, thus giving a native display of the normal map in its intended environment.
An alternative if you’re working heavily in OGL might be to investigate xNormal.
Not sure about the UV border limitation, but you should probably open a feature-request ticket if you need an overpaint border bigger than 16 on a routine basis (I’ve not come across this one before.)
Hello Wayniac and Kerwin
Kerwin is pretty much correct. The reason that you can not read a 3.5 tool in 3.1 is because the file being written has 3.5 in the file and since 3.1 has no idea that a 3.5 version exists it will not be able to open it. What you can do is export your high level into an obj from 3.5 and then import it into 3.1 and do a reconstruct subdivision levels. However, 3.5 memory management improvements allow you to get higher poly counts in 3.5 in 3.1 so depending on the system you may run into issues if your poly counts are extremely high in 3.5.
Normal maps take longer in 3.5 because they have been improved in 3.5 and the normal map quality was improved greatly. We have improved the code to create a more accurate Normal Map and yes when you do have HD on the model it will have a longer process time.
Why do you need a UV border bigger then 16? That is the border you would need for a 8K map which is the biggest size ZBrush can do.
Paul
Thanks for the response guys. Sorry for going hyperbolic there. It’s just after having set up our pipe a certain way to have unexpected things get thrown into the mix makes for a hair raising afternoon. I’ll have a look tomorrow and see if there’s any way we can get 3.5r2 in the pipe.
As for the 16 (that’s actually the max limit in our pipe) we’ve found it works well with mip mapping game textures to have the extra elbow room. Just not sure why limiting it to 16 was put in rather than allowing the user the freedom to decide for themselves what value they wish to have.
Also, is there an option to toggle off the sphere loading up in the viewport on start up?
I haven’t tried it myself, but there is a hack of the DefaultZScript.txt discussed here: http://www.zbrushcentral.com/zbc/showthread.php?t=75134
I opened a ticket on it, but for now there is no supported way to kill the initial poly sphere.
(StartupDocument.ZBR still works for default scene setup.)
-K
Actually, after some tests here with the new normal map feature the normal maps that are being created, no matter how they are swizzled, will not display properly in the Gamebryo engine. Wherever the uv islands meet up there’s a nice fat seam. Flipping the green channel worked best but still getting those seams, which is something we did not get using 3.1.
A BIG request would be to add the zmapper plugin functionality to 3.5 asap. Legacy support is something that should be a given for any developer imo. When a pipeline gets built up around a certain methodology kinks arise when developers begin gutting previous features. I don’t really care if the zmapper plugin for 3.5 bakes out HD geo or anything like that. Just being able to have that same functionality back would help ease the pain for any studios that happened to be using it.
We really needed the new reproject features from 3.5 but now that we’ve used it the new ztools aren’t useable back in 3.1. It’s like not being able to open an .obj file from XSI 7.5 in XSI 6.5. We CAN export out the high and reconstruct subdivs in 3.1, HOWEVER, the point order is now changed and it destroys any morphs we had set up on our base meshes previously.
When I was told that 3.5 would have zmapper functionality built in I was under the impression that ALL of zmapper functionality (the multiple levels of tabs and all the features contained therein) would be PART of 3.5. What we got instead was a multipage set of features compressed to a handful of buttons that auto-magically doesn’t even work in our pipeline.
Although I’m very happy to see some of the great new features in 3.5 it has come at a very high cost to us in terms of rework and disappointment in the lack of legacy support for Zmapper/.ztl’s etc. Those are things that SHOULD work and where they won’t, allow the users to have legacy support in whatever way possible. That makes transitioning a pipeline to a new update less painful, keeps your customers happy, and boosts your reputation as being a business that knows how to do business.
With that being said let me state once again that 3.5’s reprojection abilities are just PHENOMENAL boosts to the workflow. The headache we will incur due to the lack of zmapper/ztl support etc is relatively minor in comparison to the many new features found in 3.5!! So, thanks a TON for this update Pixologic. You guys rock!
I have nowhere near the tech savvy as most (any?) here, but this thread has a few things I want to ask about / comment on:
“GoZ, when its released in a few weeks, will restore some of this workflow as maps will be carried over to the enabled application”…the problem with this is that at this point Max support isn’t there…so it will likely be far more than “a few weeks” before some of this workflow is restored.
For me the worst part is that 3.5 either moved or removed a fairly large amount of buttons, UI elements, and workflow…which for me means that as I try to learn this not-so-friendly application, EVERY tutorial I’ve been using fails…as I try to learn how to get normal maps generated and moved to Max / FinalRender, the tutorials invariably get to a step that no longer applies, and I don’t believe there are any manuals available at this point for 3.5.
GoZ, as it LOOKS in your videos, might make all of this moot for me, but you aren’t doing GoZ for Max at this point.
No option yet to not have the polysphere on screen. Will be sent to development team for discussion.
Paul
Is it possible to export out the low resolution and the high resolution obj’s and then import them into zbrush 3.1 and reconstruct history? I haven’t done it myself, but I think I remember it being a possibility? Hope that helps.
Yes. Using reconstruct subdiv is handy for that purpose.
-K
Thanks Kerwin,
I attempted it, and it worked really well. LOVE ZBRUSH!!!
So how do i make normal maps if the classroom tutorial can’t be followed in 3.5 >< id really like to know how.
1- I try to do a test for compare the normals from the 3.1 and 3.5, and the results is that the 3.1 Zmapper output is much detailed and corrispondent. I usually use the Zmapper “3DS Max8_TangentSpace_BestQuality” preset and it work perfectly in max. Now are days that i try to have the same result with 3.5, is it possible that in a newer version of ZB you do a step back. Is it really difficult for a programmers team made a tab with a salvable preset for a different programs (as Zmapper does)? And integrate at the same time the usefull tab of Zmapper? And I found pretty funny that ZBrush is the first program I ever seen that can’t be opened with a clean & empty interface without “balls or spheres like that” but at least for that there is a solution, I found the link in this thread :lol:.
Preferences -> Icolors will let you set and save changes to the colors virtually everything in the UI. As for your LCD and “dots”, I don’t see this problem in monitors made by Wacom, Dell, and a couple of old Apple monitors we have around here.
http://www.pixologic.com/docs/index.php/Creating_Normal_Maps
I disagree that normal map generation is “2 step backward” assessment. The new Zmapper supports HD geometry which is major feature for ultra-high resolution maps. It also supports bigger maps. It is different than the now obsolete Zmapper plugin, and a couple of minor convenience features were sacrificed (notably an OpenGL preview of the map and one-step projection which is now a two-step process.) Also, Zmapper functionality is built-in and fully integrated with the program, which means greater consistency of function in the future.
Thanx for the reply Kerwin. This is what I got:
1 - ZBrush 3.1 + Zmapper
[
]
As you can see in the old Zmapper with “3dsmax 8 tangent preset” the Colors are Different, and the details are a little bit Crisp and Refined…
Can you help me to have the same quality and colors, where I’m wrong?
And is it possible have a white background?
My workflow is ZBrush—>3dsmax.
Is there a preset for Normals to load?
Bye