Page 1 of 1

troubles with (regular) Zbrush-Displacement

Posted: Tue Sep 18, 2012 4:15 pm
by Polyxo
Hi All,
as there's a lot of displacement-talk these days I thought I should bring up my own problems too.
I don't ever get displacement created from Zbrush-models to render in any reasonable fashion with Maxwell.
Not only Vector-Displacement which was already covered in other threads (and which is still an open issue).
I mean "regular" Z-only displacement, harvested from a high resolution quad-mesh, in conjunction with a normal-map.
Whatever I have tried, results are just aweful. The applied maps seem to stay largely ineffective and in no case lead
to a smooth outcome.
When using on the fly with adaptive to check out what one can acheive with those maps, the result even is a desaster...
The mesh forgets that it is welded and just explodes. Does anyone know a solution?

Here's two folders with the same mesh once saved out in SubD-Level 2 (which actually should be sufficient)
and another one with subdivision-level 3. Each contain a full set of 2k-maps.
Can you guys bring anything to work which looks somewhat close to the hiRes Zbrush screenshot?

Image


Image


Image

Thanks for any input, Holger

Re: troubles with (regular) Zbrush-Displacement

Posted: Wed Sep 19, 2012 12:24 am
by Mihai
Try recalc normals and a higher smoothing angle like 80. But the displacement map seems wrong....there's black and white where it shouldn't be. For example the star shape that should only show shaders brighter than middle grey is also showing black. This makes it so it doesn't match with the obj you're trying to apply it to, so there is more risk for tearing.

Re: troubles with (regular) Zbrush-Displacement

Posted: Wed Sep 19, 2012 1:49 am
by Polyxo
Mihai wrote:Try recalc normals and a higher smoothing angle like 80. But the displacement map seems wrong....there's black and white where it shouldn't be. For example the star shape that should only show shaders brighter than middle grey is also showing black. This makes it so it doesn't match with the obj you're trying to apply it to, so there is more risk for tearing.
Thanks a lot for having a look!
Hmm... I thought i take the simplest possible object. If already this one needs recalculation, and smoothing adaption one should not dare
using this for anything real.

On the other hand Zbrush is used in so many High End-Productions -wouldn't all the GFX-Studios make serious noise if both
normal displacement and vector-displacement were broken? I mean - displacement it's the only way to post-process what one has done
in this program...

For these maps I used the standardized export procedure via multi-map-exporter.
I really wonder how these maps perform when tested from other platforms such as 3DSMax. rusteberg just posted vector-displacement rendered
from Max which I could not recreate acurately, both with Studio and with Rhino.

I also saved the z-project here if another Zbrush-User
would like to test other export-settings.

Re: troubles with (regular) Zbrush-Displacement

Posted: Mon Oct 15, 2012 7:07 am
by Tan Boon Meng
Hi Polyxo,

Just came across your problem. So did you solve this issue?
I saw that you export the maps from zBrush in 2K pixels, maybe something larger than that might help.
Depends on my rendering, most time i export the maps pretty big.

I cant get exactly like what i did in zBrush, but i tried to get a balance in between.
I will say 85-95% close depends on the subject.

Anyway im using Newtek Lightwave so it might be different.
: )

Regards.

Re: troubles with (regular) Zbrush-Displacement

Posted: Mon Oct 15, 2012 8:53 am
by Polyxo
Hi Tan Boon Meng,
Just came across your problem. So did you solve this issue?
No, that issue is still open, but at least understood now.
Further both NL as Pixologic were informed about that shortcoming and got in touch.
So there might be hope for a fix.

The output-errors when rendering with M~R are not caused by texture-resolution (2K is actually already plenty large for this small rectangle of
my test). They occur because Maxwell's engine performs triangle-based subdivisions while the files were output from quad-based subdivided geometry.
Essentially this leads to unexpected topology-changes, already in the first level of subd.

The best you currently can do with Geometry from Zbrush (but also Mudbox or any other sculpting-app) in my experience is export workpieces
at high subdivision-levels and to only add one or two levels of SubD at rendertime.
Of course that's a poor workaround but the effect then in absolute vertex shifting is smaller, the result will look better.
To handle large amounts of geometry and repeating parts instances may help.

Holger

Re: troubles with (regular) Zbrush-Displacement

Posted: Mon Oct 15, 2012 1:15 pm
by Mihai
I´ve had no problem with displacements from Mudbox though, also vector disp. I´ll try to create a similar example as yours in Mudbox to verify.

Re: troubles with (regular) Zbrush-Displacement

Posted: Mon Oct 15, 2012 1:37 pm
by Polyxo
I also had the impression that the results from 3DCoat look better than from Zbrush.
There may be some differences having to do with Normals which may have an impact.
3DCoat also offers a parameter called "roughening" the Low-Poly-Mesh when exporting
it for use with displacement.
That all said: A renderer which triangulates all quad-geometry in its first subd-step
definitely does not do the expected thing on displacement which was generated from
all quads High-Poly. One can quite easily verify this.