[Reaversword]

Hi guys, I bring you a little bit of peace and love.

Zbrush Vector Displacements maps working finally in our beloved MaxwellRender.

The first, is to warn you that Zbrush haves a "particularity", that I consider a Bug, but its intended in this way, as Pixologic says.

So, your Uvs in Zbrush SHOULDN'T touch UvMap Borders (Any Uv should have any coordinate like: (0,y)(x,y) or (x,0)(x,y) or (x,y)(1,y) or (x,y)(x,1).
If any uv is sitting in the UvMap border, Zbrush won't make correctly neither Vector Displacement Maps nor any other map.

Ok, all you need to do is next:

In Zbrush go to Preferences>ImportExport>VectorDisplacementMaps and stablish:

Flip And Switch = 3
Tangent Flip And Switch = 9

Now you can make your Vector Displacement Maps, tangential or not.


Now in Maxwell Render, for World or Tangent maps (no difference!!):

In the Displacement Node of the Material Editor:

Type: 3D Relative Tangent - zero black OR 3D Absolute Tangent - zero black
Subdivision Level: Very high (256 for a 2048x2048 texture)
Scale: (0.01,0.01,0.01) (or at least, for a Maya 1 cm <1 unit> plane.)


If anyone doesn't get it working, just post here, and I'll try to help him/her.


For if anybode is asking itself, the Zbrush diagnose test (The rounded spheres over the plane one) of Zbrush>Tool Palette>VectorDisplacement Map>Diagnostic>Create Diagnostic Files, haves some uvs in the UvMap border (you can see it re-importing .obj created by Zbrush diagnose test in Zbrush and going to Tool palette>TextureMap>Create from Uv Check, you'll see a red part in the generated texture).

If anyone want take a try, here you have it some stuff:

http://www.mediafire.com/?m970wm4ofo0ov7n

[dariolanza]

Great work, Reversersword.

This definitely will be helpful for many users.

Thanks for sharing!

Dario Lanza

[Reaversword]

Hi Darío.

A question:

Maxwell expects WORLD vector displacement maps, or TANGENT ones?. I take working the zbrush World maps number 3 and the Tangents maps number 9 with "3D Relative Tangent - zero black OR 3D Absolute Tangent - zero black" options. But still I haven't notice where is the difference (I it should exist).

The names are confusing me, because all Maxwell Vector Displacement Types are named as "Tangent".

[Polyxo]

I'd like to have a look at your file but Mediafire sucks bigtime.
Could you please upload somewhere else? Thanks.

Edit: Now I have it but Mediafire still sucks.

[Reaversword]

Polyxo, how many time have you needed to download 15mb?.

It works to you now?

[Polyxo]

Polyxo, how many time have you needed to download 15mb?.

This stupid countdown thing and these Buttons which are only there to make you accidentally download some
shit you don't want is what I meant. Dropbox or such saves downloaders from such annoyances.

It works to you now?

Unfortunately it does not work and I was actually surprised that you posted this.

In my understanding Zbrush Vector-Displacement can not work properly without previous changes in the Engine.

First off one needed quad-based subdivision. That's at least what Zbrush (or also Mudbox) expects to happen
and Catmull-Clark-Subdivision also takes place in other engines e.g. in Renderman or Vray.
Maxwell however with its Vector-Displacement and pretesselated displacement triangulates the mesh right away
which leads to very inaccurate results. I assume that you applied the mxm with the .exr as displacement to a
already heavily subdivided plane in Maya? Then you probably do not see the deviation that clearly.

I get nothing at all recognizable, at least when using a single mesh face which is visible in the foreground.
I gave it 11 rendertime-subdivisions, the same amount as in the Zbrush-file. In my understanding the .exr should
work correctly with just a single face as the basemesh in the Zbrush-file you provided is a single mesh-face too.
I only get a useful result when I heavily subdivide the Source-Mesh already (background) - but that can not really
be the idea behind it

Then there should also be a mechanism in place which automatically sets the appropriate intensity multiplier for the map based on its physical size.
I have no idea how this could work but one typically has no idea how large anything in Zbrush or comparable sculpting-apps actually is.
To complete the picture the model then gets exported as an .obj which again can not store physical size. Stuff comes in arbitrary size into any Maxwell-Host...
Ideally one would bring the item into any Host and could scale the model to any desired size and the intensity-evaluation of the 32-bit-map
would automatically adapt. I btw. only used the Tangent-map which I think is the correct one.

[Reaversword]

Polyxo, if you use firefox, you can use the addon adblock to block all that shit you don't want to see. Probably there should be an equivalent addon for Chrome.

Nope, I've not used a high subdivided mesh as low poly. I used a single plane of four vertices, of 1cm in Maya. But its a little bit difficult see it in Maxwell, cause get a focus image at this distance is a little bit disturb, so, better scale up the plane till 10 or 100 cms.

I haven't use any kind of subidivision on low poly (any like turbosmooth, or smooth "number 3 in maya", nor nothing like this), just raw 4 vertices plane. For other side, I've done all inside of Maya.

The subdivision in Zbrush was done WITHOUT any smooth, neither in geo, nor in uvs (with Zbrush>Tool>Subdivide>smt off, and with Suv off too), you can see linear subdivision for Uvs and the own geometry of the plane if you take a look at the borders. So Maps from Zbrush has been extracted with Zbrush>Tool>Vector Displacement Maps> vdSuV off and vd SNormals off
Neither I was gonna smooth normals of the plane (for leave vd SNormals on), nor UvMap was smoothed at subdivision (so vdSuV off)

About the "physical size", I know it, but for me neither world nor tangent gets varitation independiently of the size I choose, and this is odd.

About the scales, how I said, is 1 cmt in Maya (if you export the highpoly in Zbrush to .obj and load in Maya, you should obtain 1 cmt plane with the mushroom, of course). But I don't know it you stablish the Maya unit measure to meters, and import the highpoly if you gonna take a 1 meter plane or 0.01 meters one..

It's odd.

Let me take a look again.


EDIT:

Ok, Polyxo, in Maya I have, in the Maxwell Material, unchecked smoothing, and subdivision should be much more high!!. Up it from 11 to 256.

Now you say it.. I don't know what exactly "Subdivision" parameter means. You're understanding that 11 equals to 11 subidivision levels. In Vray, for example, would be the size of the triangle for make the displacement, so there you should need a value when more near to 0, more detailed... I mean, perhaps the meaning of "Subdivision" parameter in Maxwell is not equivalent to Subdivision levels as we know till now.. the documentation is here, but its not specified exactly the meaning of this parameter far than say, try to get it up till you finish satisfied with result:

http://support.nextlimit.com/display/ma ... +component


I've taken a render with "11" value, and I've got exactly the same result than you. You're really near to get it working!!, up it to 256!. Tell me about when you get it!.

[Polyxo]

Thanks Reaversworld,

if you use firefox, you can use the addon adblock to block all that shit you don't want to see. Probably there should be an equivalent addon for Chrome.

Does that also kill all fake download-buttons? Nevermind - that's not my main concern.

***

What you describe is interesting - you see that my result differs quite a bit.
I should add that I used Rhino which in its modelling workspace does not support Subdivision-Surfaces.
I can repeat the result in Studio though, with a single face from the primitives-library; output starts looking a
bit better with 8*8 plane - but here one can clearly see the issues caused by triangulation.

About the scale: I think it's pretty save to say that one typically does not exactly how large a sculpted item actually is,
one can not even measure them in Zbrush. You might know how large a primitive-plane is - but anything else?
The .obj file-format does not store physical size, so Zbrush exported meshes will likely appear in quite different scale
in various Maxwell-supported formats.
The current problem is that one can not simply rescale the exported mesh in the target-application - then displacement
will look distorted. Also the highpoly-version in my sceenshot does not have proper scale, the displacement is too high.
One could now start adjusting by touching the scale-sliders - but that again should not match the underlying idea of
32bit displacement. It in my understanding it has the depth baked in - it should just work.
At least in principle

I did not see your Edit -I'll check on this tomorrow -it's late here!

[Reaversword]

Polyxo, realize that Maxwell subdivision method appears to subdivide depending of the low mesh. In the documentation says you can balance your subdivision level with your low poly mesh resolution.

So, for a single four sided polygon, you are subdividing (I don't know how exactly) 11 times.
but, for a lowpoly mesh of 8x8 = 64, you are subdividing each of this 64, 11 times. So final subidivision would be 64*11 = 704.

I don't know if it is exactly in this way, but I should be near...

Yes, its supposed the 32 bit tangent should be scale baked. Respect the scale between softwares, I suppose .obj has an scale of 1, if your soft is "representing" cm, would be cm, if represents meters, meters then... but no one says that a "meter" in Rhino be the same meter of Maya, I suppose that software understand its own "1" unit and interprets all in its own way... how you see, I only can "supposse"!.

Yes, better tomorrow we go on!. time to sleep!.

[Mihai]

Polyxo, have a look at the Displacement page in the docs:

http://support.nextlimit.com/display/ma ... +component

regarding relative vs absolute tangent. It's not simply that 'it's supposed to just work'. I'm not sure what scale Zbrush models in by default, vs for example Mudbox. All I know is that if I set the output in Mudbox to relative tangent I can leave the scale at 1 in Maxwell and all is fine. If I subdivide the mesh enough (which is needed no matter if you use vector displacement or not), the results are fine. Don't know why everything in Zbrush is so freaking complicated....

[Polyxo]

Now I am completely lost.
To my understanding Catmull-Clark Subdivision divides by 4 in each subdivison.
10 steps of subdivision from the single-face basemesh (defined as level1 in Zbrush) equal 1048576 mio faces at resulting level 11.
Given the renderer talks Catmull-Clark too it was sufficient to reach this level, in order to fully represent the detail-level of the source-file.

There's no documentation about the triangulation-scheme Maxwell uses instead but it will most likely divide everything evenly.
Assuming triangle-based subdivision cuts each triangle in half in each subdivision-step (which is most common) one needed 20 subdivisions
to get the exact same face-count.

With 20 Maxwell-subdivisions applied however the mesh still looks shitty.
Things start looking somewhat better when increasing levels to much higher values than Catmull-Clark would require.
At level 256 as suggested by Reaversword on would end up with an entirely silly rendertime- face-count. Is that Trilliards or even more?
I think we can agree that such subdivision was absurd.
One further should point out that even at this entirely over the top crazy and resources-wasting subdivision the mesh still does not closely resemble the Source.
The idea is an identical representation, not something along the lines of...


My next point is Scale:
Reaversword has used a primitive in Zbrush and probably used the default export-scale for geometry and maps of 1.
It according to him came into Maya at a size of 1cm and at this size renders in a way which looks somewhat like the Source.
Inside Rhino however I need 1meter in size to make that same map look best.
I get utterly wrong results at deviating physical sizes of the mesh, regardless whether I use Relative Tangent or Absolute Tangent.
Again, this is so for Rhino.

Inside Studio I can indeed set the .exr-map to absolute tangent or to relative tangent (both with zero=black) and I get precisely
what I want (at least in terms of scale): Whatever physical size the object is at, the relative displacement hight showing on that object always
stays the same. No matter if at 0.01m size or 10m - one gets that mushroom.
Although the MW-documentation differentiates between both types I can not see a difference in Studio. Maybe the same mechanism
works in Maya already but certainly not at all inside Rhino.

I fail entirely seeing how Zbrush could cause anything of these problems. The map is perfectly fine.

[Reaversword]

So, Polyxo, finally Zbrush Vector Displacements maps works for you too, right?. I'm glad to hear about!.

One thing, the plane I used was a Maya primitive 1cm plane, the same plane which uvs I reduced a little bit for it doesn't touch UvMap border.

I'm agree with you, nevermind one be using a world or a tangent map, mushroom works at any scale in every cases.

And how I said, I have no idea if Maxwell is subdividing using Catmull-Clark or other method. I don't know, imagine when you set for example a subdivision of 150, for maxwell means 1/150 of a meter! (for the edge of a subdivided triangle). If was this way, this would work, but not would be Catmull-Clark way!. May be someone of the Maxwellrender team could be so kindable to clarify this issue..

So Polyxo, now we know Maxwell plugin for Rhino is fails, maybe NextLimit could take a look an fix it!.

Realize that you in Mx Studio won't has needed change Scale parameter (in Displacement material section), and I should scale it down in Maya plugin to 0.01 in each axis. Maxwell works by default in meters (1) and Maya in cms (0.01). Polyxo, whats the "natural" scale of Rhino?. Try to create a cube in MxStudio, import it in Rhino, create a primitive cube in Rhino and compare it, may be you can find the correct "scale compensate valor". It was possible create a cube in MxStudio, right?.
Doesn't matters, if it can help you, here you have a 1 cm plane from Maya. Maybe you can find this scale compensate valor to get it working on Rhino!.

Here you've:

http://www.mediafire.com/?xn3rtabqx6dy9l6

[Polyxo]

So, Polyxo, finally Zbrush Vector Displacements maps works for you too, right?. I'm glad to hear about!.

That was a good one !!
No.

Things are still completely broken, not only because I don't ever work in Studio.
Due to triangulation taking place both Studio and also Maya don't yield correct results. (not only with Zbrush - but with VD-maps from all sources, including Mudbox and 3DCoat btw).
Results don't look right but they also need ridiculously high subdivision-values for something which could be achieved with a far slimmer footprint.

It's really broken - I'd even appreciated if you changed the thread-title.
It's misleading otherwisely.

cheers, Holger

[JDHill]

So Polyxo, now we know Maxwell plugin for Rhino is fails, maybe NextLimit could take a look an fix it!.

Rhino is internally unitless, with scale being defined by arbitrary user-choice in the Rhino UI. When exported to MXS, geometry, which always exists directly in world space, is physically scaled to be its actual size, in meters. So, where in Studio, a 10m plane made from a 1m plane is 1m @ scale 10.0, exporting a 10m plane from Rhino, you will have a 10m plane @ scale 1.0. That is the only meaningful difference I see, so far, in the above discussion. I'll be taking a look at the example files today, to try and see what is going on.

[Reaversword]

...Inside Studio I can indeed set the .exr-map to absolute tangent or to relative tangent (both with zero=black) and I get precisely what I want...

That was a good one !!
No.

Man. If it works in Studio, it works.

Stop thinking Catmull-Clark is the way Maxwell is subdividing. This is WRONG. I'm telling to you think out of the box!.

Take a look at this:

Subdiv level of the mushroom .exr over a single plane > number of triangles

0 > 2 triangles
1 > 8 traingles
2 > 18
4 > 50
8 > 162
16 > 578
32 > 2178
64 > 8450
128 > 33282
256 > 132098

You can read the number of triangles in the Maxwell Render console!. I'm saying to you that forget about Catmull-Clark subdivision method.

If you find a method for get this numbers list in sense, I would know what is, but Catmull one is NOT.
How you see Subidv of 256 over a single plane are not trillions.. dude of yourself next time, and try to check if what you think is correct.

I'm not from Next Limit nor Maxwell Render team. I'm just a Maxwell user like you trying to help another one.

If it works in Maya and inside Studio, why you want to edit thread title!?. If system is broken in Rhino, man, NextLimit should take a look at Maxwell for Rhino plugin!.

So stay calm. Really, is a little bit hard trying to help others while people is continuosly getting angry with me!.