Renderman for Maya / Renderman Studio displacement hints

September 1st, 2009



I’m about a month into using Renderman Studio v2, and I’d like to share a few random hints about how to get things working how you’d expect them to. This list is generally for people who are used to the mental ray/Maya way of doing things.

This first collection is about one of PRMan’s strongest points: displacements. It’s absurdly fast due to how the REYES architecture handles micropolygons, and it barely has any RAM footprint at all.

1. Object scale is incredibly important when working with displacements in RFM. Your displacement map is calculated in world space, so if you scale up your mesh in Maya, it’ll do weird things to a 32-bit displacement, and you’ll end up having to tune your alpha gain & offset to match the scaling ratio.

Freezing your transforms doesn’t work, because it’s reading the map in world space.

The proper way to fix this issue is to scale your mesh in Maya, freeze the transforms, export it out as an .obj, then import it at the lowest subdivision level into your sculpt, recalculate all your maps, then export the mesh again from ZBrush (UVs might smooth or shift, always re-export your .obj after calculating displacements).

After that, reimport it into Maya (make sure you check “Merge UVs” under the export options!). This way ZBrush is calculating your displacements at actual scale, and you can use the magic numbers: alpha gain of 2.2, offset of -1.1 on your map. Remember to turn off quadratic filtering on your image as it softens your displacements.

Note: Alpha gain / offset of 2.2 / -1.1 are for versions of ZBrush prior to 3.5. From 3.5 on, use 1 / -0.5.

2. Your shading rate affects how much of the displacement map is actually used, and you have to set this multiple places depending on your scene setup (subsurface render passes, renderradiosity render passes as well as the “quality” tab under render globals). In general, you can think of a “1″ setting for shading rate as production quality, but it’s possible to go higher (more on this below).

Worth clarifying that you don’t necessarily need to set this to the *same* value if you’re, say, doing an environment light with color bleeding. There’s a strong possiblity that a 64-sampled renderradiosity map will look totally fine and have enough detail with a sample rate of 20(!!!) and save you a ton of map calculation time.

3. Is your displacement, hair or other micro-detailed feature not sharp enough? Try cranking your sample rate all the way down to .1. — zero isn’t an option, it’ll set it to 1 automatically.

4. Getting weird blobby surface artifacts when rendering displacements (or subsurface effects)? It’s likely due to PRman’s credo of avoiding raytracing at all costs.

What you’re seeing is the result of your pointclouds or raytraced shadows being calculated against your un-displaced model, then just the points that invoke raytracing are comped over your render, and unless you force Renderman to calculate displacements against everything, you’ll end up with an ugly, blobby, posterized mess.

Click on your object, then go to the attribute editor and manage attributes. You need to add a “trace displacements” attribute to your object. (Attributes->Renderman->Manage Attributes).

Be aware, however, that if you’re using lots of rays (for raytraced shadows, for instance) that each of those rays is getting calculated a bunch of times and it can all add up in your render times.

5. While not strictly a displacement tip, it applies due to the way “trace displacements” is handled: when doing pointcloud passes for environment lights (RenderRadiosity etc), make damned sure that raytracing is disabled for your pointcloud passes or your render will quite likely never complete in your lifetime.

6. Getting a ghost of your mesh’s wireframe when using displacements and raytraced shadows? The fix is the same as tip #3 — turn your shading rate way way way down. Generally .1 is the magic setting to fix this. If you’re using other passes (subsurface, radiosity etc) make sure to set your sample rate there as well if you’re seeing artifacts on those passes as they preview render. This is a brute-force fix that looks good without tweaking any other settings.

There’s another method to fix this issue that isn’t quite so brute force: adjust your trace bias up by small amounts until the self-shadowing (that’s what those ghosts are) go away. Render times will likely be much quicker with this method, but shadows won’t likely be quite as detailed or accurate.

7. Magic numbers for 32-bit ZBrush displacements in Slim:

Assuming you’re using a combine node:

Do displacement: checked
Use shading normals: checked
Base: -0.50
Kb: 2.2

Note: Base / Kb of -0.50 / 2.2 are for versions of ZBrush prior to 3.5. From 3.5 on, use -0.50 / 1

Add a bump, make it an image file with 0 filter, set to a value of 1.

Pretty much the same thing as Maya… the math’s the same, even if the numbers are different, so it might trip some folks up.

More hints to come in the not-too-distant future.

Entry Filed under: CG, Geek, Tutorial

7 Comments Add your own

  • 1. Sachin Shrestha  |  September 2nd, 2009 at 11:59 pm

    Another important point while rendering displacement is Displacement Bound. That basically decides how tight your displacement is and avoids creating artefacts in the render. You should try using as small a number as possible but of course, that depends on how much displacement you really want. This attribute helps a lot for fine detailed displacement stuff and is the first attribute one should tweak to get rid of displacement artefacts.

    Also, there is an “Extreme Displacement” mode in some rendermen (excuse the pun) which helps optimise memory management for large displacements.

    And you could try increasing the flatness attribute to higher number (thereby decreasing the quality of mesh tessellation tolerance) which can speed up your renders. But this would make sense if you have mild displacement or the object is not really close to the camera so you wouldn’t need very fine detailed displacement.

    And there’s always the option of baking out your displaced geometry and then using it in the scene instead of calculating displacement per frame. It will blazingly fast and you can trace against it too! But that would obviously work for static objects.

  • 2. Trey  |  September 3rd, 2009 at 12:09 am

    Thanks for those tips, Sachin!

    I’m making a point of collecting as many tips as I can to ease the transition for folks used to the mental way of doing things. There’s really not a lot of practical workflow how-to stuff out there for PRMan/RFM right now, and I’m not the only guy putting a priority on getting up to speed in PRMan as insurance against MR’s Maya implementation continuing to be a broken, buggy memory hog.

    Lots and lots of folks are jumping on the bus right now due to either Maya 2010 breaking more than it fixed, or academic pricing.

    But anyhow, I found out after about a month of scouring that little things like “how do I get a decent holdout/matte object?” and “how exactly does the scattering routine work?” and “why do area lights kinda suck?” questions that most folks will have on day 1 of using RFM aren’t really answered particularly well out there, if at all. I’m hoping to fill the void a little, so keep the tips coming!

    –T

  • 3. Sachin Shrestha  |  September 3rd, 2009 at 11:23 am

    Sure Trey. I’ve bookmarked your site and will drop in some troubleshoot tips or info I manage to gather at work.

    -Sachin

  • 4. Brian  |  September 3rd, 2009 at 3:30 pm

    Another point is that the displacement is not necessarily calculated in world space: If you add the renderman attributes to your displacement shader you can toggle between shader and world space.

  • 5. Trey  |  September 3rd, 2009 at 3:37 pm

    Nice to see you drop by, Brian!

    (tip moved up to main body)

  • 6. Trey  |  September 5th, 2009 at 4:26 am

    Here’s a useful one that I can’t believe I forgot earlier:

    Magic numbers for 32-bit ZBrush displacements in Slim:

    Assuming you’re using a combine node:

    Do displacement: checked
    Use shading normals: checked
    Base: -0.50
    Kb: 2.2

    Add a bump, make it an image file with 0 filter, set to a value of 1.

    Pretty much the same thing as Maya… the math’s the same, even if the numbers are different, so it might trip some folks up.

    –T

  • 7. Trey  |  September 14th, 2009 at 1:03 am

    Crazy Pixologic and their whole changing random things because it amuses them.

    In ZBrush 3.5, when working with 32-bit displacement maps, sometimes you’ll need to use Alpha Gain of 1, offset of -.5 (Kb / base in Slim) — but not always.

    True to form, without the multi-displacement plugin (which isn’t available yet), results are unpredictable. Sometimes it’ll stick with the old 2.2 / -1.1 guideline.

    Don’t get why Pixologic goes and breaks/sabotages things that work predictably in practically every update, but I’ve come to expect it now :)

    Truth be told 1 and -.5 makes sense and it’s the value that the maps should have been generated at all along, it’s the lack of consistent behavior that’s annoying.

    Also: ZBrush writes out a single-channel 32-bit grayscale map by default now — which rocks if you use PRMan (not so much with Mental). It makes 8k map file sizes (and network spool times) much more reasonable. Maya will complain about the maps because the TiffFloat reader only does 3×32, but PRMan reads 1×32 just fine on render.

    –T

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed


Global

Categories

RSS CGTalk Maya Feed

RSS Slashdot