Realistic skin tests

Render time ranged from 60sec to 120sec for the ones with the brightest highlights. Raw renderings without any post-production. Click each image to see the full resolution version.

Model provided by ten24. Rendered with a development version of Arion 3.

Arion realistic skin tests
  
  
  
  
  

BSDF clamp (no more fireflies)

Dear Arion customers,

What I am about to present here, may be one of the most important features in unbiased rendering ever. :-) Not kidding, probably.

This feature enters in the field of cheating, but the negative impact in the quality and purity of the render is often 0, while the benefit of removing fireflies entirely is probably the long lasting dream of every unbiased render engine user.

In most practical uses, the following is true:

With this feature, you can get rid of most (often ALL) of the fireflies in your render without (generally) affecting the render or losing visual components.

Here’s a visual example, rendered from a WIP kindly provided by Marco Podrini (podro).

Raw, unclamped scene. Lots of sun fireflies:

BSDF-clamped scene [clamp=8]. Identically-looking render, but the fireflies are gone:

How does this work?

WARNING: I will get a bit technical here. So read the conclusions in bold only if you want.

When a light path hits a surface, the mathematical model (BSDF) of the surface material is evaluated to determine the intensity and direction of the outgoing light ray. Since this is part of a stochastic (randomized) process, BSDF evaluation involves the material properties, and also some factors related to the probability of each outgoing direction. For this reason, likely paths usually evaluate to low-power BSDF values, and unlikely paths evaluate to high-power BSDF values.

That is perfectly normal and completely correct. Unlikely paths will output high-power samples, but will not happen often, so they will accumulate to normal-power values over time. In the same fashion, likely paths will output low-power samples, happening very often, so they will also accumulate to normal-power values over time.

Some unlikely (hard to generate) paths, such as complicated caustics, can be characterized this way. As a special case, fireflies could (in theory) be characterized this way too. As a matter of fact, they are very unlikely paths that happen sparsely, and carry a high amount of power that is expected to dissolve by accumulation over a long time.

Unfortunately, some completely legitimate paths fall into this category too. So simply removing such paths would kill fireflies at the expense of destroying many other legitimate visual components.

In v2.7.0 we have added a setting with which you can (optionally) constrain the output range of the RandomControl BSDF.

Note that the output of a BSDF is in the range [0..INF), despite most normal output values are in the range [0..1]. For this reason, using small clamp values (e.g., 4, 8, …) makes sense.

- The higher the clamp value is, the more power you’re letting through, and the less that you’re clamping.
– The lower the clamp value is, the more aggressively you’re clamping.

– Low BSDF clamp values kill fireflies very aggressively, but may darken some highlights in the scene.
– High clamp values leave the scene nearly (or completely) intact, but may let some fireflies through.

i.e., It is best to pick a BSDF clamp value that is high enough to leave the physical-correctness of the render as unaffected as possible, while removing as many fireflies as possible.

Here’s the same example as above, using an ‘excessively low’ [clamp=1] value. As you can see, fireflies are fully gone, but the frosted glass panel gets darkened a bit. In the render above, [clamp=8] was used, and fireflies were equally gone, while the brightness of the render remained completely unchanged.

BSDF clamp 1

This new feature, which is particularly effective in sun-lit scenes, will be part of v2.7.0 and be accessible in the upcoming Asa and Af3 Beta builds.

A couple more examples. This scene was kindly provided by Jose Manuel Linares (mane162) some time ago.

Unclamped (normal) version. Some sparse, but annoying speckles here and there:

Clamped version. Identically-looking, yet completely speckle-free:

Thank you very much.

Ways to use the Arion AOVs to denoise a conflictive render

Arion becomes more robust version after version and we’re already offering a very powerful set of features which allow the user to fight fiercely against noise and render times. However, sometimes your scene is either too complicated, or you’re unsure where your noise is coming from, or you’re about to meet your deadline and need an easy way to stay out of trouble and get a clean render.

In this short tutorial we will study the case of a render that is mostly clean except for some caustics.

NOTE: This particular example has been set up to generate excessive noise and fireflies from specular surfaces.

Method #1: Using the Main and Caustics AOVs

To achieve our denoising goal with this method, all we need to do is enable the Caustics AOV and let Arion render until most of the image is clean.

The Main AOV:

The Caustics AOV:

By subtracting the Caustics AOV from the Main AOV, we get a clean render of the full GI, minus caustics:

We can carefully denoise or despeckle the Caustics AOV to remove all the fireflies:

Now we can add the despeckled Caustics AOV to the Main AOV and get the final (clean) image:

Method #2: Using the Direct/Indirect AOVs

This method is similar to the previous one, but requires fewer editing steps.

Note that for this method, you may need to enable the Lights AOV as well, as direct vision of light sources is not included in the Direct/Indirect AOVs.

Here is the Direct AOV:

Here is the Indirect AOV:

And here is the Lights AOV:

Just like in the previous method, we carefully denoise or despeckle the Indirect AOV:

Then we add it back to the Direct AOV, without forgetting to add the Lights AOV as well, in order to restore the full image:

As you can see, using Arion’s v2.5.0 AOVs, it’s possible to get out of a difficult rendering situation without sacrificing quality, when the deadline is about to expire.

Note that, in both cases, denoising the Caustics/Indirect AOVs is virtually non-destructive to the final image, because most of the sharpness and evident details in the render are present in the Main/Direct AOVs, which remain intact through the process.

Note also that, strictly speaking, all these operations must happen in HDR (linear) space so addition and subtraction of AOVs is correct.

Thank you for watching!

Finite sampling and exit colors (II)

In the example images below, a low number of bounces was used for the specular and glossy components, while a little higher value was used for diffuse bounces. This resulted in a nice 45% faster rendering for a visually indistinguishable image:

As explained in our previous post, each render component features an Exit color, which can be used to compensate the darkening coming from a too low path recursion depth. Some very important speed increases can be achieved on dielectrics and Sub-Surface Scattering materials if exit colors are used properly:

Here are some more examples, where every SSS material is using an exit color, and the total number of SSS bounces was cropped to 6. As you can see, it renders not only faster, but also cleaner:

Thanks for watching!

Finite sampling and exit colors (I)

The Arion v2.5.0 rendering core features a brand new set of controls to constrain path-tracing depth on a per-feature basis.

i.e., now you can control the maximum number of specular/glossy/diffuse/refraction/scattering GI bounces independently.

This new feature will be available to all the v2.5.0 releases of our products. For example: you can see what the UI looks like in the Arion stand-alone in the image to the right.

Cropping the maximum number of GI bounces in a scene allows for a significant speed increase in exchange for a controlled darkening of the GI in hard-to-reach areas.

Note that this feature does in no way break unbiasedness. However, if you want to stay fully physically-correct and render times are not your main concern, then you can just crank the GI limits up to their maximum values to fully disable bounce cropping.

For those of you curious about technical details, this feature works by keeping separate bounce counters during the path-tracing loop. As soon as one of these counters reaches the limit set by the user, the path is aborted, contributing to the framebuffer either nothing (by default), or a user set exit color.

Exit colors have different practical uses:

1- You can use them to learn how many bounces your scene needs for optimal performance. You can enable them and keep increasing the GI bounce limits until the exit colors disappear from your scene. Then disable them and render normally.

2- You can use exit colors to greatly optimize dielectrics and SSS. For example, you can set a skin-like exit color for a skin SSS material (*) to get super-fast clean SSS with very few bounces.

(*) Exit colors can also be configured either globally, or on a per-material basis.

We will post some visual examples of this all in our next post.

Thanks for watching!

New Caustics AOV

As mentioned in previous blog posts, Arion’s compositing capabilities have been greatly reviewed and extended for v2.5.0. An example is the new Caustics AOV.

As you probably know, Arion features a ‘Disable caustics’ switch (which you can enable either globally or per-material). This switch dims sampled contributions proportionally to ‘how caustic’ they appear to be. This solution effectively removes caustics from the render.

In general, and in true unbiased/physically-based rendering spirit, one should never want to remove caustics from a render. However, in practice, sometimes most of the noise (or even fireflies) in an image come from caustics.

The ‘Disable caustics’ switch is fine. However, it leaves you with no control in case that you only want to remove only some of the caustics, as it is an all-or-none switch.

So, for v2.5.0 we have done the following:

1- We have improved the way the ‘Disable caustics’ switch works, making it filter caustics more finely than before.

2- We have added a new AOV which gathers the contributions that the ‘Disable caustics’ switch would trim out of the final render. This AOV works regardless of whether the ‘Disable caustics’ switch is ON or OFF.

In other words, now you can render normally, and then deal with caustics separately in post-processing.

To obtain a caustics-less render in v2.5.0 you can:

1- Either render with the ‘Disable caustics’ switch turned ON.

2- Or render normally, and then subtract the Caustics AOV from the Main AOV in post-processing.

Both operations are equivalent. Here’s a little example, where the Caustics AOV has been subtracted from the Main AOV:

Once you have a caustic-less image and a Caustics AOV you can do things such as:

– Denoise or despeckle the Caustics AOV, and then add the result to the Main AOV.

– Dim whichever caustics are bothering you and add the result to the Main AOV.

– Pump the caustics up for artistic effect.

IMPORTANT NOTE:

In order for these post-processing operations to work (correctly), you must work with 32-bit raw (untonemapped) EXR output. Additions and subtractions of AOVs only work as they are intended to if they happen in unclamped linear space (a.k.a. Linear Workflow / LWF). Doing operations such as the ones mentioned above with tonemapped 8-bit or 16-bit output would ‘seem to work’ but be technically incorrect, because each channel would be LDR-clamped and gamma-corrected.

A little status update:

We’re still working on Arion stand-alone v2.5.0, MAX LIVE v2.5.0 and RHINO LIVE v2.5.0. We will release each of them as soon as they are ready, which should hopefully happen during the upcoming weeks (Aug/Sep).

Thanks for watching!

IBL Importance Sampling

Arion v2.5.0 features a brand new Importance Sampling system for Image-Based Lighting that immensely improves render speed in HDR-illuminated scenes. The speed improvement becomes really massive as soon as the HDR environment starts to be heterogeneous enough (i.e., contains some particularly bright spots such as the sun, etc…)

IBL-IS (Image-Based Lighting Importance Sampling) analyzes the HDR environment map, splitting its surface in areas classified by brightness. From then on, the brighter areas are sampled more often than the darker areas, so variance (noise) is reduced much faster. The speed improvement ranges from faster to extremely faster.

The most typically extreme case for IBL-IS is an HDR photograph of the sky, because most pixels are even in brightness and color, except for the sun ball. With regular stochastic sampling, the sampler would need to hit the sun ball by chance. But thanks to IBL-IS, light paths are automatically driven towards the sun area more often than they are to the rest of the sky.

In other words, it is now possible to render efficiently any HDR environment with fast and nearly-immediate hard shadows, even if the map features tiny bright spots, a sun ball, studio light gear, or anything that you can think of.

This feature is a blessing for product-viz and exterior shots.

So here you have some examples of the IBL-IS feature in action.

The images below were rendered using IBL-IS (v2.5.0) and stochastic sampling (v2.x.x) for the same amount of time. Difficult HDR environment textures were used for demonstrative purposes.

Example #1:



Example #2:



Example #3:



Example #4:



And last but not least, here’s another demonstration of the power of the Arion MLT sampler.

This is a render of an inflatable pool with full physical underwater caustics. Subtle dispersion was enabled to add some natural color fringing. The image was illuminated with an HDR environment map.

This render does not use the native sky/sun system!

Thanks for watching!

Renewed Shadows AOV

For v2.5.0 (stand-alone + MAX + RHINO) we have re-done the Shadows AOV. This is one of the various fixes or improvements that we have made in the rich compositing/AOV system introduced in v2.4.x.

Our new Shadows AOV has some very interesting properties:

– It catches shadows coming from every feature in the engine (emitters, sky/sun, env).
– It catches shadows coming from the GI as well (not just direct shadows).
– It catches the HDR color and power of the incoming light/GI in the unshadowed areas.
– As expected, it is decoupled from the reflectance of the BSDF of the shadows catcher.

To allow for this all, the Shadows AOV is now HDR RGB (compared to LDR grayscale as it was before).

Here’s a visual example, where the following channels have been rendered for a test scene:

– Main.
– Shadows (backdrop set as shadows catcher).
– MtlID mask (backdrop set to mask).

And here’s a quickie where the rendered objects have been incrustated in a photographed backplate:

Note that one of the key properties of this renewed Shadows AOV is that it is an HDR RGB channel, where (all) the incoming light arriving to the shadows catcher is captured, keeping its real power and spectral color. This provides a much more complete solution to render/photo incrustation than a simple direct-lighting only, or grayscale-only Shadows AOV.

Note also how the new Shadows AOV (as expected) is decoupled from the reflectance of the BSDF of the shadows catcher (although the GI cast by the shadows catcher correctly affects the GI received by itself). This allows the user to set a shadows catcher that resembles the final backplate, if desired. However, using a default lambertian for the shadows catcher is often more than enough.

Here’s the same example, where the backdrop is textured. The Shadows AOV has a slight red shift now, but the checkerboard is absent as expected.

Thanks for watching!

Swimming pools and MLT power

We are posting this in response to some ignorant (or maybe deliberately disinformative?) comments that have been made on other forums about our latest blog post.

The fact that Arion can render some hard caustics paths with practical efficiency is not new. We released our MLT sampler many months ago. The fact that we can render proper sun caustics (e.g., swimming pools) now is a combination of MLT helping a lot + some improvements we’ve made in our physical sky system lately + the ability to alter the sun diameter at will (so the sun is found more easily by stray light paths).

We have -never- cheated in our software. We have -never- implemented a single feature that uses interpolation, and we have -never- implemented a single feature that is not unbiased in Arion (or fryrender in the past). Additionally, and very importantly, we have -never- insulted or deliberately lied or disinformed about any other rendering solution, because that’s not our style.

Below you can find one of the test images that we posted yesterday, rendered with our Path Tracing (PT) and Metropolis (MLT) samplers for a few seconds. You can also find the same scene, rendered clean with MLT. These images are quite descriptive (I think) of how much MLT can help when it comes to exploiting hard-to-find light paths vs. PT, which samples all paths evenly. I believe that these images also evidence that the clean render is not the result of cheating, post-processing, or interpolation, but raw unbiased accumulation.

The thumbnails can be clicked to be viewed in their original resolution (2048×2048).

For those Arion users curious about the parameters used:

– Splatting = ON
– Super-Sampling = 1
– Water = normal dielectric water (roughness = 5%)
– Sun diameter = 2ยบ
– Sampler = MLT

Here you can see two more examples where MLT is really decisive. One is the classic dispersive prisms test, and the other one is a heavy physically-based volumetrics test (Arion supports volumetrics since v1.5, released a long while ago).

Stable noise pattern

This feature affects RCSDK (all products) in general, and MAX LIVE in particular.

We have been reviewing and reworking the QRN seed a lot in the past days. Besides fixing a small bug in v2.x (we were sometimes repeating some seeds in the first frame if multiple rendering devices were involved), we have finished a feature that never worked in fryrender when the QRN seed was configurable, or in previous versions of Arion:

Now when you select a fixed number of passes, it is guaranteed that all devices in all stations will compute the exact same sequence of QRN seeds, and in the same order.

That is, there is a function that tells for each pixel at each pass what QRN seed will be used, and that function is ‘universal’ across all stations and devices.

Furthermore, the rendering loop makes sure now that if you set a fixed number of P passes, the accumulation buffer will keep the first [0..P] samples for each pixel and rule out any other seeds that might arise early due to the difference in speed between devices.

This sounds a bit complex if explained so technically, but the impact in the engine is very easy to understand:

Now, when rendering an animation (even if multiple devices or computers are involved), the noise pattern will be completely stable across frames, no matter what.

We have rendered a motion-blurred animation kindly provided by our friend Luima Morillo which you can watch below:

NOTE: The video has been rendered at a fixed number of passes (4) per frame to produce a deliberately noisy animation, for you to see the stability in the noise pattern.

NOTE II: Video compression smudges the actual noise a lot, so here’s a bunch of raw (uncompressed) frames:

This improvement is part of RCSDK v2.5.0, which is what we are working on as of this moment. v2.5.0 will bring upgraded builds for:

– MAX LIVE.
– RHINO LIVE.
– Arion stand-alone.

Thanks for watching!