More Zbrush - messiah displacement observations

[WesComan]

Whoa! 56 minutes? I can render the sample zbrush head (see below) at 800x600 in about 50 *seconds*. I think something strange is going on in your scene.

From reading your queries it seems that you haven't turned displacement on (under Surfaces->Object (select the object in the list)->Render Geometry/Displacement (1)/Sub Level). Once this is set you will see that messiah does displace geometry at render time.

One of the cool things about displacement in messiah is that you don't have to crank up the displacement subdivision to get the fine detail...

http://img13.exs.cx/img13/2395/DispLevel.jpg

As you can see setting a higher subdiv level improves the sillouette and the structure of the head, but the fine detail is always there.

[chikega]

Nice example Tony! I agree with Wes, the displacement mapping should render rather quickly. Check your scene for other CPU hogs. As far as displacing actual geometry, messiah does displace. Remember Taron's crazy rock formation rendering in the render thread? It's not automatic at the subpixel level, but you can set it high enough to get it at or below the subpixel level. We had a discussion with Lyle about separating out the bump and displacement to save on memory and other system resources. :)

[tjnyc]

The displacement value was set to 3, so the values are correctly set. There was no other process that was taking up RAM or CPU from the task manager, so no problem there. I'm also running this on a P4 3GH HT w/ 2 GB RAM.

Cheers,

[AlexK]

We had a discussion with Lyle about separating out the bump and displacement to save on memory and other system resources.
Why would that save system resources? You'd have two textures instead of one and you'd have two channels to address while rendering. :shrug:

[tjnyc]

Okay, here are my settings for displacment, let me know what I'm doing wrong.

metaNURBS if on for OpenGL view of model
lo-res model is at 10,000+ ploys
Displacement map is 4096x4096
Object: Pre-generated
Displacement: 3
Subdivision: 2
Anti-Aliasing: 3
3 Direct lights no GI
Render at 800x600
Render time: 56mins

Cheers,

[AlexK]

Try lowering your displacement setting from 3 to 1 and adjust the Displacement depth with the bump value.
Oh and how about posting your scene for testing on another machine?

[WesComan]

Yeah, I agree with what MarvinTMartian said. Try setting Displacement to 1, and 'cos it's a reasonably hires object try setting the displacement sublevel to 1 (or even 0)

Cool character btw :thumbsup: If he opens his eyes I'm running!!! :eek:

[SergO]

I decided to compile a list of my views on Messiahs displacement, feel free to argue, correct me etc... I dont write this stuff in stone ;)

The Good, the Bad, and the Ugly (in random order) :)

-It's not Sub-Pixel

-It's displacing subdivided polys just like you would find in C4D or Lightwave

-It's a huge memory eater, like LW and others but not as bad... after extensive renderings I reckon Messiah can do roughly 30% to 40% more detail than the hugely memory inefficient Lightwave renderer.

-It's not render time displacement (subdivision occurs before any pixels are drawn) hence not really any different than setting the render subpatch resolution in LW or C4D

-It relies on bumpmapping to fool the eye into thinking it's Sub-Pixel displacement, in fact the same effect can be achieved in pretty much any software, by putting the texture on bump as well as displacement. Messiah may be doing some normals correction or something to enhance quality here.
It looks great in some cases, but it falls apart as soon as you ask it to do say, a pebbly floor or stone wall... the only way to do that correctly is with real sub-pixel displacement (or more memory than will fit in your computer), or by rendering a tiny patches of displacement with nothing much else in the scene (like the examples people keep showing).

-it's very sensitive to funky polys in your object, so make sure you dont have any 2 point line polys, n-gons, duplicate polys, unaligned polys etc... make sure its clean or it will crash ;)

-When using Sub-Ds there will be cracks and shading errors around triangle polys (poles as well I think)

-Without using Sub-Ds there will be cracks every where.

-Messiah will crash if memory consumption gets to 1.6GB.

-Messiah apparently has the necessary architecture to support proper Sub-Pixel displacement and will likely feature such an implementation in the future, so I read on another thread... yay! :)

Lol, the hype around this feature is quite funny really, all invented in the minds of users, inculding mine :)
After a short while of playing with messiahs displacement I realised it wasnt sub-pixel displacement...convinced that this was a nasty case of false advertising I even searched the manuals and pmg website for references to Sub-Pixel, and found none.
PMG has NEVER stated this feature to be sub-pixel displacement... The hype was created by users using the term incorrectly, and showing little render tests (spheres and the like) that were very good at making it look like Sub-Pixel, but of little practical use... Thus unintentionaly setting expectations of the casual observer sky high.

The shadow artefacts corespond to polys that are at such an angle to the light that the ray cant be traced correctly when combined with Phong shading (something like that), this is something that affect a lot of renderers, LW being one of them.
Using Parametric option would fix this since the polys are always the size of a pixel, but you'll alsways see this bug when you use displacement because it is always using Pre-Generated polys, even if Parametric is selected instead.

Cheers

SergO

[tjnyc]

Thanks for the explanation.



PMG has NEVER stated this feature to be sub-pixel displacement... The hype was created by users using the term incorrectly, and showing little render tests (spheres and the like) that were very good at making it look like Sub-Pixel, but of little practical use... Thus unintentionaly setting expectations of the casual observer sky high.


PmG does state it is "sub-pixel displacement", it is on the front page of their website.

Cheers,

[SergO]

LOL :D

I went straight for the Studio2 page and manuals, where they say Sub-Poly or just Displacement, without using the Sub-Pixel word.... but I missed that flagrant violation on the front page!!! pmg are probably confused about it themselves.

The suggestion of Sub-Pixel displacement in Studio had a large bearing on my pruchasing decision, I'm not terribly happy about that...
However, I'm still happy with my purchase, because I did a work with it that cant be done in LW (in one pass anyway). I'll show a wip tomorrow... once I figure out how to use my own webspace to post pictures on that is...

Cheers

Serg

[ThomasHelzle]

SergO:
Yes, I think your observations are very valid. I'm also a bit disapointed by the fact that it isn't "real" render-subpixeldisplacement since this was my hope too. I will still show spheres and simple stuff with my shaders, since I too hope this feature will be usable with larger objects too in later revs...
I will try to label it correctly as subpolydisplacement in the future if my old brain plays nicely :)

The only "correction" I want to make:
If you insert the "/3GB" switch into your boot.ini (WinXP Pro), messiah crashes later :), on my machine exactly when reaching my 2Gig of Ram (if someone has more Ram, it would be interesting to see how high it can go...)

Example entry:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /3GB

The only strange thing are your 56 minutes rendertime...
Have you tried the "swords"-scene I posted earlier?

[tjnyc]

SergO:
The only strange thing are your 56 minutes rendertime...
Have you tried the "swords"-scene I posted earlier?
Yeah, I'll try it out when I get home.

Cheers,

[Swissphil]

TJNYC: Is subdivision on for the Head model itself? I am not talking about subdivision on the surface panel in the rendertab, I talk about the one you get when you load the model and then hit the tab key while the object is selected in the items list. In your post you said Metanurbs is on for OpenGL view of model... can you have it on for OpenGL and not for rendering? Any way...maybe you want to check it in the setup tab if its really on...

In my first tests I didn't have Metanurbs on for the model and got huuuuuge rendertimes.

[lmilton]

I've had to be away from the forum for a bit and missed this thread (and many others). I'll try to address the concerns posed in this thread by responding to this post:

I decided to compile a list of my views on Messiahs displacement, feel free to argue, correct me etc... I dont write this stuff in stone ;)

The Good, the Bad, and the Ugly (in random order) :)

-It's not Sub-Pixel
While it's true that the subdivision isn't automatically set to be within the pixel area, using Parametric-Low RAM (PLR) does operate at the pixel level. But that's only if you're not using MetaNURBS (subdivision surfaces).

-It's displacing subdivided polys just like you would find in C4D or LightwaveNot exactly. When you work with subdivision surfaces (MetaNURBS) as you would in other software, in messiah the displacement is a form of "beneficial byproduct". That is, the subdivision must happen anyway, so the displacement is computed in that context *at render time*.

So, for those of you who are wondering why there is no change in RAM usage regardless of using Pre-Gen or PLR, it's because you're using MetaNURBS.

-It's a huge memory eater, like LW and others but not as bad... after extensive renderings I reckon Messiah can do roughly 30% to 40% more detail than the hugely memory inefficient Lightwave renderer.Yes, the subdivision can eat up RAM, but that's to be expected if you set the subdivision level too high. There's no cure for that; it's like loading up multiple fully rigged characters, it's going to take up more RAM.

-It's not render time displacement (subdivision occurs before any pixels are drawn) hence not really any different than setting the render subpatch resolution in LW or C4D Not exactly. As I mentioned above, when you use PLR on non-subdivision models, the sudivision happens when there is a "ray hit" (this can be eye, reflection, transparency, radiosity, etc.). The downside is that it can be very slow... as should be expected with raytracing.

-It relies on bumpmapping to fool the eye into thinking it's Sub-Pixel displacement, in fact the same effect can be achieved in pretty much any software, by putting the texture on bump as well as displacement. Messiah may be doing some normals correction or something to enhance quality here.
It looks great in some cases, but it falls apart as soon as you ask it to do say, a pebbly floor or stone wall... the only way to do that correctly is with real sub-pixel displacement (or more memory than will fit in your computer), or by rendering a tiny patches of displacement with nothing much else in the scene (like the examples people keep showing). You're missing an important point here. You'll have a tradeoff with displacement & raytracers: RAM vs. Speed. While we do have further optimizations to make to the renderer, no renderer can get around this problem completely. And those that try to "hack" around the problem often exhibit even more problems that ultimately become virtually impossible to fix without rewriting the core.

No, messiah is not like other renderers you've used. What you have in messiah is a more intelligent solution in the context of a raytracer & displacement. It uses our TrueBump technology in conjunction with displacement to allow you to have control over RAM usage while still providing great results with reasonable speed. And about fooling the eye, that's what this is all about. As a user, you shouldn't care what methods are used by a renderer as long as it allows you to get the desired result in a reasonable time. It's all in setting the right params.

With regards to the pebbly wall example you gave, you'd use PLR with non-MetaNURBS objects. This is the closest to true subpixel, just not automatic... yet.

-it's very sensitive to funky polys in your object, so make sure you dont have any 2 point line polys, n-gons, duplicate polys, unaligned polys etc... make sure its clean or it will crash ;)

-When using Sub-Ds there will be cracks and shading errors around triangle polys (poles as well I think)

-Without using Sub-Ds there will be cracks every where.

-Messiah will crash if memory consumption gets to 1.6GB.You should separate these from your list of concerns since they appear to be a bugs. You initiated this post under the context of sharing your views on the way you feel we've handled displacement in messiah. No prob, it just that bug reports cloud the discussion.

And if you've run into a crash, it would be great if you could put together a *simple* scene so that we can easily identify the problem.

BTW, you may get cracks in Zbrush generated maps/UVs. This is actually a problem with Zbrush and it will exhibit the same problem with the same data that it generated. However, we've been working on a solution for this.

-Messiah apparently has the necessary architecture to support proper Sub-Pixel displacement and will likely feature such an implementation in the future, so I read on another thread... yay! :)

Lol, the hype around this feature is quite funny really, all invented in the minds of users, inculding mine :)
After a short while of playing with messiahs displacement I realised it wasnt sub-pixel displacement...convinced that this was a nasty case of false advertising I even searched the manuals and pmg website for references to Sub-Pixel, and found none.
PMG has NEVER stated this feature to be sub-pixel displacement... The hype was created by users using the term incorrectly, and showing little render tests (spheres and the like) that were very good at making it look like Sub-Pixel, but of little practical use... Thus unintentionaly setting expectations of the casual observer sky high.
Keep in mind that the casual observer's expectations are already *way* too high with regards to sub"whatever" displacement and raytracers. They may look at what they've seen in, say, RenderMan and believe that they'll get the same results in raytracers in a reasonable time. That's the danger of users being armed with too little information about technologies that most don't really understand.

I'll just say that it's not lack of expertise or some strange coincidence that almost all raytracers use subdivision instead of true subpixel. Even some emerging technologies/renderers may look promising in demos & promo images, but you only have to actually *use* them in the context of production with full shading (texturing, reflection, radiosity, caustics, etc.) to realize there were tradeoffs made... and they may not be the ones you'd have liked.

I'll just wrap all this up and let everyone know that whatever bugs were encountered we'll fix 'em. We have more speed & RAM optimization in the queue. And, we have some even more exciting features coming for the renderer. Those that have been with us for a long time have come to expect good things from us, and we've done everything in our power to deliver. And with the phenomenal imagery of which messiah is already capable, we don't see any reason to stop now:D

Thanx for the feedback & support everyone!

-lyle

[lmilton]

The displacement value was set to 3, so the values are correctly set. There was no other process that was taking up RAM or CPU from the task manager, so no problem there. I'm also running this on a P4 3GH HT w/ 2 GB RAM.

Cheers,
As others have pointed out, don't set your displacement above 1.0. In fact, you'd save yourself a lot of trouble if you just use 0.0 & 1.0, for off & on, respectively.

BTW, for what reason where you setting the displacement value to 3.0? Maybe there's something fundamental that you're missing...

-lyle

[tjnyc]

As others have pointed out, don't set your displacement above 1.0. In fact, you'd save yourself a lot of trouble if you just use 0.0 & 1.0, for off & on, respectively.

BTW, for what reason where you setting the displacement value to 3.0? Maybe there's something fundamental that you're missing...

-lyle
I wasn't getting the finer detail at 1 so I bumped it up to 3 and lowered my bump value in the material. I've tried it out with 1 but I still do not get the finer detail like I was getting with ZBrush. I agree that I need to understand more of the ins and outs of the workflow with displacement in messiah. I'm going to try out the min/max shader utility to enhance the sharper thinner detail.


Cheers,

[chikega]

I wasn't getting the finer detail at 1 so I bumped it up to 3 and lowered my bump value in the material. I've tried it out with 1 but I still do not get the finer detail like I was getting with ZBrush. I agree that I need to understand more of the ins and outs of the workflow with displacement in messiah. I'm going to try out the min/max shader utility to enhance the sharper thinner detail.Cheers, Hey Tony, you've probably figured this out by now. But, that 0 and 1 is really an off and on switch - although it does allow you to vary the *amount* of displacement, it won't bring out any more *detail*. You can get the finer detail by bumping up the SubD Level. 3-6 seems to work well - but I've gone as high as 30 for grins. :D Obviously, make sure the object's been Metanurbed, first, though.

Also, the detail you can get out of messiah will depend in part on how detailed the map is that you're exporting out of ZB2. Obviously the higher the resolution of the map, the more details it will afford you (>2048). But from my own experiments, it seems the DPSubpix has more to do with the apparent smoothness of detail in messiah - so cranking up the DPSubPix to 3 will get you smooth results in messiah. 4, the highest setting, is the best, but expect a few minutes or longer for ZB2 to generate at that level. SmoothUV seems to help. And Adaptive, which will automatically generate and vary the DPSubPix depending on local details, seems to give mixed results in my tests. :)

[tjnyc]

Hey Tony, you've probably figured this out by now. But, that 0 and 1 is really an off and on switch - although it does allow you to vary the *amount* of displacement, it won't bring out any more *detail*. You can get the finer detail by bumping up the SubD Level. 3-6 seems to work well - but I've gone as high as 30 for grins. :D Obviously, make sure the object's been Metanurbed, first, though.
Yeah, the "vary" amount looks like someone needs to go on the low-carb diet. Was the 30 sub level with param(low RAM) or pre-gen? BTW, why do you have to have your model metanurbs for displacement?


Cheers,

[chikega]

I used Pregenerated Polys. Why did I Metanurb it? Because Lyle told me too. :) I added more to my response above.

[tjnyc]

Also, the detail you can get out of messiah will depend in part on how detailed the map is that you're exporting out of ZB2. Obviously the higher the resolution of the map, the more details it will afford you (>2048). But from my own experiments, it seems the DPSubpix has more to do with the apparent smoothness of detail in messiah - so cranking up the DPSubPix to 3 will get you smooth results in messiah. 4, the highest setting, is the best, but expect a few minutes or longer for ZB2 to generate at that level. SmoothUV seems to help. And Adaptive, which will automatically generate and vary the DPSubPix depending on local details, seems to give mixed results in my tests. :)
I generated at 4096x4096, no DPSubPix, as I tried at 1 and no noticeable difference in messiah and 3 which brought the house down. SmoothUV of course.

Cheers,

[chikega]

On my Zombie head, I used 2048 X 2048, with DPSubPix of 3, SmoothUV. Did ZB2 crash or messiah? At first I thought ZB2 had crashed - but, it was really thinking hard about generating that displacement map. It took 20 minutes for one to generate. Fortunately, it has a progress bar with estimated time of completion. In either case, we may be getting into memory issues - try out 2048 X 2048 and see what happens, Tony. :)

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.