[Polyxo]

Hey man,
I have no idea why you could think that I'm angry with you.
I also don't think that Maxwell uses Catmull Clark. I know it doesn't, but it clearly should.
This all might be a language-problem.

Man. If it works in Studio, it works.

Sorry, that's nonsense. This is Maxwell and not some limited toy-renderer where one could live with shortcomings of that kind.
As a matter of fact one at this time, neither with Studio nor with any host-program can accurately and memory-efficiently render Vector-Displacement,
regardless of source.

[Polyxo]

I see that you have edited your post.
That subdivision-scheme you show here indeed looks interesting.
No idea how this pattern works, but what I posted with giant numbers would be logical.
Only NL-employees could shed some light here.

What I know however is that one needs a predictable and compatible scheme for subdivision-meshes.
One needs to know how much Geometry one creates virtually. When not very cautions with the values in
the Subdivision-Box my machine runs out of memory before I count up to three.

[Reaversword]

I see.. well then only Next Limit can clarifiy the way, as you say.

Maybe Maxwell not be all accurate you hope, but the method works, better or worse, but works.

..by the way, Polyxo, have you tried to create a more high resolution texture?. Maybe a 4096x4096 gives you the detail you need, although.. lets see:

2048x2048 should be (for a plane with uv total area, excepts for the fact we need scale it down a little bit), a detail ready for generate 4.194.304 vertex.

with a Subdivision level of 256 over a single plane, Maxwell produces 132.098 vertex... we should keep adding subdivision levels till reach this almost 4 million 2 hundred thousand polygons to get exactly the same surface, But realize that if you have this example, the mushroom, using Catmull Clark subdivision method you would be subidividing zones where no detail is needed. I supposse this is the reason Next Limit -neither Chaosgroup with its Vray- uses this method. So do something like that would not be valid.

Probably, for get such control how you'd like would be great simply tell to Maxwell how many polygons you want the render engine renders. Do it with half million!. ta dá!. Hmm. more, less, etc... but we have that we have and Next Limit will have their reasons, I don't know. Just do the best you can with the tools you have!.

Test all with calm there in Rhino, and try to get in touch with the Maxwellrender support throguh the customer gateway to explain the problem with the Rhino plugin. Try to understand why it fails and get an explication. That's what I do with this issue of Zbrush VectorDisplacements, and finally I had the luck to realize the issue of "Uv touching the border particularity for Zbrush", but man, you'll need time, patiene and luck!. I'm sorry, I can't help you more!. I hope you can use vector displacement maps soon in Rhino!

[Polyxo]

But realize that if you have this example, the mushroom, using Catmull Clark subdivision method you would be subidividing zones where no detail is needed. I supposse this is the reason Next Limit -neither Chaosgroup with its Vray- uses this method. So do something like that would not be valid.
!

Just for what it's worth, Vray-Displacement does use Catmull-Clark for Quads and Loop Subd. for triangulated meshes. Source

cheers!

[Reaversword]

Wrong again Polyxo.

When softimage or 3dsmax does a tursbosmooth on polygons, or push "3" in Maya with a polygon selected, or you see a polygon smoothed in Modo.. THIS kind of subdivision for the entire object is the Catmull-Clark applied for Vray for Softimage with that method. But this kind of subdivison of Vray for Softimage is no related with the subdivisions generated for displacement maps (vector or not). How I say, this kind of subdivisions are used for the entire object, generating a homogeneous subdivisions, while in displacements maps, the method creates more geometry where is needed.

Maybe if you take a look at the Vray for 3dsMax section, you can realize what I'm saying:

http://www.spot3d.com/vray/help/200R1/d ... params.htm

In Vray for Maya docs I have not founded a mention to Catmull-Clark method. I know Softimage uses it to subdivide its geometry, don't know if Maya uses it, but I have no constancy of that


Cheers!

[Polyxo]

Let's leave it here.
I was in contact with one of the heads of Pixologic on this matter (and made him talk to NL too)...
The first thing he asked was whether MW's displacement would work similar to Renderman and Vray.

Just look at this clip. Do you think they would show that cage if the subdivision was triangle-based?
The underlying map was created in Zbrush btw.

[Reaversword]

Many people before apply the vector displacement mapping, first uses this kind of "polysmooth", this way to smooth polygons, and yes, is then when many softwares uses Catmull-Clark. One time done this step, then uses de vector displacements.

I don't know really about this issue, if result would be better with a quad subdivision method like Catmull or a triangulated one. All my meshes always haves polygons of four sides but I don't perform a subdivision (or turbosmooth) before apply it displacement maps... but the truth is that in really, I don't know why before apply displacements maps people chooses this method of smooth-before-displace.. In theory I understand displacement (not subidivision) should work well enough.. maybe with a more subidivided surface you need less memory to perform a correct displacement.. hmmm... I'm gonna test it. So many people can't be wrong!.

[Hervé]

mmmm... these are triangles right...?

http://www.youtube.com/watch?v=ovelfgNiyJk

[Polyxo]

Hervé,
One should not look in the direction of game-engines. They for interactive framerates work with brute force triangle based geometry-simplifications
and mostly Normal-Map swindle.
These morphs you showed get deformed by some Mesh-Modifiers (not by images) and they obviously don't get subdivided at deformation-time.
So that's something else entirely. Although those output-shapes are simple the triangle-grid in such low resolution can not represent them smoothly,
One can see facettes even with that diffuse material. Probably well enough for a game.

One has to understand that a triangle based replication of a deep Catmull-Clark subdivision can only get you some aproximation.
Already the first steps of (e.g. a Loop-Subdivision) lead to deviations and to cummulations of triangles at poles.
Whatever Maxwell does exactly, it's evident that it can not properly give you back ten subdivision-levels from Zbrush or Mudbox.

What I am interested in essentially is the most fuzz-free and integer representation of infinite levels of Detail.
Vector displacement could be the key with its "baked into" depth.
We can unfortunately not work with the full polygon-load in the Editor but VD has the potential to be the most reliable way to get the real thing back.

[JDHill]

Whatever Maxwell does exactly, it's evident that it can not properly give you back ten subdivision-levels from Zbrush or Mudbox.

Yes, it is evident, especially given that it would be impossible for it to do so, MXS files containing only triangles. Only in the case that Maxwell supported quads natively, would it make sense to discuss mismatches between its "subdivision" and that of another application. It is for this reason that I think it was a mistake to change from "Precision" to "Subdivision" for the label in the displacement UI -- though the term is technically accurate, it was already associated with a very different concept (SubD). So just please try to keep in mind that you are not dealing with SubD subdivision, and instead with control over what has more generally been called micro-poly displacement. Otherwise, you are guaranteed to run into confusion, as a result of trying to superimpose the one concept over the other.

And to address the previously mentioned Rhino vs vector displacement problem, it is not a problem. Base geometry with a scale factor will result in scaled vector displacement; while it is natural for an application like Cinema (and I assume Maya) or Studio to deal with [geometry * transformation], that is not the case in Rhino -- scaling geometry in Rhino yields physically scaled geometry, still in world space. A way of dealing with this is to block the base geometry, and then scale instances of the block; this works because instances are an exception in Rhino -- they are the only case in which it uses [geometry * transformation].

[Polyxo]

Hi JD,

So just please try to keep in mind that you are not dealing with SubD subdivision, and instead with control over what has more generally been called micro-poly displacement.

There's no way of keeping something in mind which was nowhere documented.

Yeah, mixing up what MW calls subdivision with the concept, common place in mesh-modelling applications
and especially Digital-Sculping-Applications is really to be expected. I am sure that apart from a handful
initated users noone really knows how that beast works. As said before - for as long as MW does not subdivide
with a quad scheme it would be helpful to know more about what it does currently.
I have a perfect idea of to be expected Polygon-Load when using Catmull-Clark. With Maxwell I have no clue.

Subdivision in mesh-programs gets used used for the exact same purpose as in the renderer.
But while Maxwell uses the same word it in fact does something entirely different.
The fact that other renderers indeed apply the Catmull-Clark subdivision-scheme (quads in - quads out) certainly doesn't help
with clarification.

And to address the previously mentioned Rhino vs vector displacement problem, it is not a problem. Base geometry with a scale factor will result in scaled vector displacement; while it is natural for an application like Cinema (and I assume Maya) or Studio to deal with [geometry * transformation], that is not the case in Rhino -- scaling geometry in Rhino yields physically scaled geometry, still in world space. A way of dealing with this is to block the base geometry, and then scale instances of the block; this works because instances are an exception in Rhino -- they are the only case in which it uses [geometry * transformation].

I'm happy and thankful that you found this trick to deal with this matter!

Still - from a users-perspective I would not call this "not a problem".
Having to turn stuff with VD to blocks means that the feature does not work out of the box and
means a complication in the workflow and something to learn. The object being a Block certainly had
consequences, e.g. when introducing File-Linking such as GoZ or similar bridges where the idea is update both
geometry and maps.
I perfectly realize that you can't do anything about these fundamental differences between Rhino and mesh-applications
but I as a user would of course prefer the not having to thing about anything solution found in Studio
or other hosts.

best, Holger

[Reaversword]

Guys, please, if you're using Maxwell for other soft than Maya, Rhino or Studio, and you can test if works to you, report it, ok?.
Let's make a Maxwell plugin report for Zbrush Vector Displacements issue.

From now, appears:

Studio > works
Maya plugin > works
Rhino plugin > not works

thank you all!

edit: So there is a trick for Rhino using instances and then is working? (Feel free to update the list).

[Polyxo]

One might try with something just a tiny bit more complex than a simple plane.
I've created a simple cube transformed to a sphere with some scales on it. I fail miserably both in Rhino and in Studio with it.

Here's a zip-archive.
EDIT: updated model with better PUV-map and better maps here
Please open the obj with that cube, apply the displacement and if you want the Normal-Map too. Do you get something usable in Maya without previous subdivision?
I'd be surprised.

[Half Life]

I wasn't going to post anything, but since you asked for other users to chime in, here is where I'm at:

Every time a new a version of Maxwell or Zbrush releases, the very first thing I do is check vector displacement -- it does not work correctly, and has not worked correctly (ever). You can get "close" results, and if you are the type of person who accepts "close" as "good enough", then certainly it can be used... however I have not, nor will I create any tutorial videos on how to use ZBrush vector displacement in Maxwell until I have a workflow solidified that will result in 100% accurate results every time (and not just "close-enough").

I despair of that happening anytime soon.

Best,
Jason.

[JDHill]

Studio > works
Maya plugin > works
Rhino plugin > not works

I write the Rhino plugin, and there is not any specific problem with it regarding vector displacement.

As said before - for as long as MW does not subdivide with a quad scheme it would be helpful to know more about what it does currently.

How many methods do you know for dividing a triangle into similar sub-triangles? We have already discussed this in another thread. The question is not specific to 3D applications, we are only talking about simple geometry.

The reason your above example fails is: you attempt to combine subdivision and displacement into one operation, when Maxwell only supports displacement. If you want a good result, you need to include the subdivision part in your mesh, and only the displacement part in your displacement map. Your modeling application may or may not support this separation: it may be necessary to bake the subdivided sphere to a mesh, and then paint your displacement on that.