Advertisement

You're blocking ads, which pay for BlenderNation. Read about other ways to support us.

[non-Blender] Fixing the Energy Loss of Rough Materials

10

Kram1032 writes:

For a long time, very rough materials have been a challenge to render: Physically based models exist but most suffer from a severe problem of energy loss. The reason for this loss is that the existing models only ever considered a single bounce along the surface, completely neglecting higher order bounces.

To tackle this problem, Eric Heitz, Johannes Hanika, Eugene d’Eon and Carsten Dachsbacher reinterpreted what's considered the industry state-of-the-art microsurface model, the Smith surface scattering model as a more easily solvable volume scattering model.

It turns out that the Smith model can be derived as a special case of the microflake model of volumes which can be reinterpreted as a BSDF that corresponds exactly to the Smith model except that it includes higher order scattering and thus gets rid of the energy loss problem.

To see some of the stunning results or get a more in-depth explanation check out the video or this blog post where you'll find the paper, a supplementary tutorial implementation paper (with source code and test cases), slides and an existing plugin for the experimental Mitsuba renderer:

Video and Narration by Károly Zsolnai-Fehér
Image Design Credit: Felícia Fehér

10 Comments

  1. While I love the results, What I'm afraid of is that this material might be just as slow as a volume tracer.

    One thing I'm wondering is given the capability of cycles nodes to do advanced math with multiple surfaces, might it be possible to duplicate this directly in the node editor?

    • The paper also mentions how fast this works. It is indeed slower than a regular single-bounce rough material.
      How much so, as one might expect, depends on the chosen roughness. The paper mentions slowdowns between 1x (no slowdown for very low roughness values) and 3x (for some cases of a roughness value of 1 which is "fully rough") depending on the specifics of the scene. - So it only slows things down if that's actually necessary to fix the scene. And in some (maybe even most) cases, as you can see in the results, the changes are rather significant.
      Though it's possible that some optimizations like the roughness blur cycles already has might help with this.

      I don't think a direct copy of this would be possible within Cycles' Nodes as of yet. Though perhaps, by using both the supplementary material and the existing Mitsuba renderer plugin, somebody with some knowledge of Cycles could build a patch for Blender.

    • what could be done in Nodes is a rough simulation of the effect by enhancing brightness and slightly boosting saturation based on roughness values. It would never work perfectly but perhaps it could work good enough.

      • Hmm, well something like that might work. Some people already do simulate roughness by super finely distorted meshes at a super high resolution. Since this technique essentially tried to simulate exactly this statistically, it would basically be a perfect match.
        It's possible that, to some extent, it's reproducible with similarly super high res normal maps. Not entirely sure. But if shaders could in principle do it, a simple low depth but super fine cloud noise texture either as normal- or as displacement-map should probably do the trick.

          • not at all a bad approximation I'd say, but it looks like, in the mid-ranges, it still loses energy (although less so). Note how, at the end of the animation, it seems to brighten up again. Since that happens for roughness=1 and "normal" diffuse kind of already is a rough material hack (although not quite) at the end it should be fairly correct. (The not quite comes in because you can actually also assign various roughness values onto diffuse materials if your model allows for it.) But in between there it looks like there is a sudden bump in brightness when diffuse takes over enough. It's possible that that's actually accurate but it seems to me like that implies some energy loss in between.

            It's certainly usable like that though.

  2. So, I guess we can expect this to be implemented within Unreal Engine 4 in like, what, a week's time? lol

    Those folks work pretty fast at implementing new methods.

    • I'm fairly sure this is too slow for games. UE4 doesn't worry about unbiased realism, afaik. They rather fake stuff. They fake it well but they still fake it. This technique is specific to unbiased raytracers like Cycles, Lux, etc.

      • Yeah, they'd find a cheaper means of achieving a similar result for real-time visuals. The industry isn't quite there yet, but it's certainly heading towards more attention to emulating finer micro-surface rendering.

Leave A Reply

To add a profile picture to your message, register your email address with Gravatar.com. To protect your email address, create an account on BlenderNation and log in when posting a message.

Advertisement

×