Renderman displacement prob.

[stew]

Tell us a bit more about the scene - what shader did you use, what is the scene made from (polys, NURBS)?

[artistx]

Just a hunch, but I think your brownian is causing the problem. If I remember correctly brownian is a sort of noise function. Some of those noise functions take into account distance to increase speed and reduce errors. They fade off with distance. Take off the brownian and see what happens. If it happens with a painted texture map displacement I guess my theory would collapse. Also, what renderer are you using? This way, other specific renderer users can help you out.

[rendermaniac]

What space are you displacing in? In PRman "current" space is camera space which might cause issues. If it is polygons check the UV's, but I doubt it's this as they wouldn't change as much.

How have you created the shader? Is it from SLIM and could you post the code? Can you post a differnt camer a angle to see the difference?

Simon

[DanielKochlowski]

Ihave a scene in maya, nurbsplane 10,10,10, directional light,
slim: blinn, default, dispalcement simple bound 0.06, do diplace, Kb 0.010, brownian 5,5,5,5

is this scene the effect is very obvious, the further from the camera the less displacment (also less detail).

I tried the same with a tif. file and the effect is not that extreme but still not very good, the displacement far away from the cam is very blurry

@ rendermaniac: how can I change "current" space to something different and where? worldspace would sound good to me

Thanks

Daniel

[rendermaniac]

If it's like that in SLIM then it probably isn't a space issue. (you can change it by connecting to an Enseble if you want to play with it though).

I think you have the gain set too high though - bring it down to the default of 0.5.

Also do you get displacement further back if you render a larger resolution image? IF so it is probably anti-aliasing.

Bring down your values a bit - especially gain! Frequency may make a bit of a difference too.

Simon

[elhuppi]

Just go to the Renderman Render Globals and to the Reyes section. At the Shading Rate type in a smaller value, like 0.25, that´s a good quality level. And then your problem should be solved.

cheers,

Alex

[playmesumch00ns]

0.25?? Are you crazy?? I've got better things to do with my life than wait for 3 week renders to finish. I'd advise 0.8 - 0.5. If you have to go lower than that then there's something wrong with your shaders.

The rather minging problem you've got there looks like it's the result of freqeuncy clamping.

By default noise functions will average out to 0.5 when you get far away from them. Hence your problem. This is the result of noise being a bitch to antialias. It's not impossible, just nasty. Ian Stephenson's managed it, but only for 2D. Look here (http://www.dctsystems.freeserve.co.uk/inoise.html) .

To combat this you can use multiple levels of noise that have different frequencies and different stengths at different distances. So when the camera gets further away, a lower frequency noise takes over.

As for your noise shifting around when the camera moves, this is indeed the result of calculating the noise value in camera space. You can fix this in a single line of SL. If you're just using slim, it's probably easier to select your geometry in Maya, the select Renderman>Primitive variables>__Pref: freeze

This attaches the world-space vertices of your model at the frame you issue the command to your mesh as a primitive variable. __Pref is picked up by most slim shaders and will stop the noise moveing when you move the camera.

[elhuppi]

Crazy?? I don´t think so! I´m not sure on which 286er you are working on, but on my workstation
there is no problem rendering with 0.25 shading rate. :-)

For a test scene like Daniels above I got rendering times like 20 sec. (without rib to be written).
For a more complex scene like this one (http://www.cgtalk.com/showthread.php?s=&threadid=92735&highlight=fiery) I had only rendering times like 4-5 min. , which isn´t too long at all in my opinion.

But perhaps you made some other experiences with renderman on that, so this was just my advice for Daniel.

Cheers,

Alex

[Mauritius]

Alex is exactly right. The filter size for the frequency fading (not clamping, as the image posted clearly shows), is obviously derived from ShadingRate (as one would expect). The only way to reduce the effect for the Daniel, in lack of any SL or advanced math knowledge (which I saucily assume), is indeed to lower the ShadingRate.

The problem in this very case btw. is not that of antialiasing noise, but the simple fact that the BRDF is changed by the displacement shader -- if you look at the surface from a distance.
Hence, to really combat the effect, visually, in a succesfull manner, an alternative BRDF that approximates a Brownian noise distributed microfacet model would have to be used (blended in) once the Nyquist limit is getting close and the displacement fades out. In lack of such a BRDF, again, lowering ShadingRate will likely get you there.

Don't forget that higher render times can still be cheaper (time wise), than going to the math and shader coding involved with solving this problem in an analytic manner (TD/shader writer time is most often more expensive than buying another few machines for the render farm).
Taking a pragmatic (aka real world production driven) pov, doesn't neccessarily mean to avoid taking the iterative road (heck, even recursive, sometimes) at all costs. ;)

And in Daniel's case, your whining about increased render times is pointless anyway. The surface shaders are simple enough (and no textures). So going down to a ShadingRate of 0.25 will not seriously -- probably not even perceivable -- impact render times.


Cheers,

Moritz

[playmesumch00ns]

So when he lowers the shading rate to 0.25, what happens when he pulls the camera out, and the noise in the distance fades out again? 0.1, 0.01? Even with such a simple scene that would take aeons to render. Whether you're going to be pedantic about the name or not, frequency clamping (I take the name from Advanced Renderman btw. - who in their right mind would literally clamp the value of a noise function to 0.5?) manifesting itself in such an ugly way is the result of a bad shader.

In general it's a really bad idea to use a single noise function for anything, which is why I suggested using multiple levels of noise. The best solution in this case would be to paint the displacement map rather than use a noise function, as your renderer's tetxure filtering will likely be much better than any solution you could come up with to hide the "frequency fading".

My "whining" about increased render times is more a matter of principle than anything else, Mauritius. If you're having to drop shading rate less than 0.5, either you've got an insanely detailed scene, or there's something wrong with your setup. As someone with thousands of hours of real-world production experience, you surely know that getting your shader writer/lighting TD to spend a few hours optimizing a badly written (or Slim-ed) shader can save you weeks in processor time.;)

In answer to your question, Alex, I'm rendering on a 200-dual-box dedicated render farm. :)

[brainspoon]

after some digging in the shaders i found that filteredvsnoiset and filteredsnoiset (in noises.h) are causing this behaviour, but i don't know how to change them to work in a better way.

it would be okay if they dampen the octaves in the shaders instead of averaging the results of the noises. then there will be still displacement that but with less detail.

[Mauritius]

So when he lowers the shading rate to 0.25, what happens when he pulls the camera out, and the noise in the distance fades out again?

It always fades out at the same distance. I guess we both know that in the original image, the ShadingRate simply was much too low (5-10, I'd guess). Going down to 1 won't likely be enough, maybe 0.25 will, maybe not. In any case, shader writing won't solve anything in this case, as we're talking about displacement.

And while were at it -- you might have forgotten, but ShadingRate also determines the crispness of a picture in every aspect. E.g. texture lookups, as filter sizes are based on it everywhere in REYES.
You rather general statement that st. is wrong, if ShadingRate has to be lowered below 1 or 0.5 is nonsense imho, for this plain reason alone.
Numerous times in the my production past, a ShadingRate of 0.5 or 0.25 was choosen for the sole reason, the stuff rendered was meant for broadcast. At PAL res, the additional crispness makes a big difference to the picture's final look and there is no other way, you're gonna get it.
If the AD tells you: I want that picture crisper, no shader writing will get you anywhere, for the simple reason that shaders are only called at ShadingRate ...

badly written (or Slim-ed) shader can save you weeks in processor time

But this is not the problem here. He only used a simple displacement appearance with a Brownian connected. Even if you analytically antialias the Brownian, this will still lend to the same effect, maybe showing up at a [very] slightly higher frequeny.
If this was solely about the noise texture, I'd agree with you (and your reference to Ian's antialiased Noise would make sense too), but in the displacement case, you must derive a BRDF from a microfacet model with a Brownian distribution -- doubtfully something that any of even the most gifted shader writers will manage to wrap in a few hours -- a few days sounds more reasonable to me -- if even.

If you bake to textures, this solves nothing. Texture filtering will fade the bumps out too and lead to a wrong BRDF in the distance -- and ShadingRate plays the same role again -- see my comment about crispness above.
For the Brownian it makes no sense anyway, since this already does a decent job of antialiasing itself.

The fact that most often the texturing, reflections and shading model mixing creates enough high frequency to not see this in "real world" examples, doesn't change the fact that the probme exists, and in this very case, the original poster asked about, your going to get nowhere by 'optimising' the Slim generated SL (what do your propose to do btw.?), but by lowering ShadingRate, you will get somewhere at least and with no effort at all.

I quote Larry Gritz from the '98/'99 SIGGRAPH coursenotes on RMan shader antialiasing:

"We've restricted our discussion to color, and displacement is ever trickier. Consider a surface that is displaced by a noise field [sounds familiar?]. If we use filtered noise to antialias, what happens if we approach the Nyquist limit and the bumps fade down? A flat surface catches and reflects light much differently than a rough surface, so you may notice a light or color shift that you didn't want. This is a common problem when antialiasing bumps or displacements, and I have yet to see a satisfactory solution that works in the general case."


Cheers,

Moritz

[playmesumch00ns]

Moritz:
Texture filtering works a darn sight better than frequency clamping, as it preserves the detail of the noise much better. When the camera-space derivatives get large in the distance, texture filtering will still average out to close to 0.5, but not exactly 0.5, and some variation will still be present. Likewise with Ian's integrated noise, which in essence does much the same thing as texture filtering.

The problem I have with frequency clamping is that it takes effect much too early. The noise filter must bail before aliasing starts to become apparent, whereas texture filtering actually deals with the aliasing problem directly.

All this is, of course, rather academic, since at the moment no ideal solution exists for dealing with the real problem: what happens where the macroscale noise function needs to blend with the microscale BRDF. My point was that, while not ideal, using textrue filtering will give a much better result than frequency-clamped noise.

If you wanted a good BRDF for this, I think an Oren-Nayar would give a fairly good approximation, although I quite agree that writing one specifically is not something anyone would want (or have time) to do, and you'd still have the problem of how to blend it with the macroscale noise convincingly.

brainspoon:
The filteredsnoise macros are indeed causing the unwanted effect. Unfortunately, the Brownian function is already implementing the possible solution you propose. filteredsnoise is called at a higher frequency for each octave in your noise. Therefore higher-frequeny octaves are clamped out before lower-frequency ones.
You can remove the frequency clamping (and see why it's there in the first place) if you substitute the call filteredsnoiset( P, fw, t ) with snoiset( P, t).

[stew]

Originally posted by Mauritius
If the AD tells you: I want that picture crisper, no shader writing will get you anywhere, for the simple reason that shaders are only called at ShadingRate ...
Don't forget the filter - before you go down to a shading rate of 0.01 to make the image crisp, you should make sure you're not using a 2 pixel box filter.

[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.