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
  
  
  
  
  

Noise, cellular and mix maps

Dear users,

As said in a previous post, the Material System in Arion is getting incredible improvements for version 3.

Another example: A wood material made entirely of procedural noise, cellular and mix maps. The material stretches properly on any object and does not need properly unwrapped UVs.

Wood material made with noise, cellular and mix maps


Thank you for watching!

2-sided materials

Dear users,

The Material System in Arion is getting incredible improvements for version 3.

An example: The new 2-sided material allows the use of two completely different materials for the front side and the back side of a thin object (without a volume). This can be used to simulate sheets of paper, tree leaves or, like shown on this example, a set of playing cards. We have updated the Arion v3.0.0 page with some high resolution examples.

2-sided material on playing cards


Here are a couple more examples also using other cool new features that will be announced soon:

2-sided material


Thank you for watching!

Importance Sampling drive

Dear Arion users,

Emitter materials and Light objects in the next builds of Arion will feature something called “Importance”. This value allows the user to alter the prevalence of a light source in the Importance Sampling table.

The IS table is a structure that determines how often each light source is sampled. This table is built during warm-up and it automatically assigns a value to each light based on its power output, and its size.

This a priori criterion makes sense, because power and size are the most evident factors that tell how much light a source will contribute to the scene. However, there are situations where a certain light source is really critical to your scene, yet it does not receive as much importance in the IS table as necessary. For example, imagine a very small and dim light that is illuminating the foreground of the scene. You may want it to be as noiseless as possible, while other larger, more powerful fill lights in the scene may not need as much sampling.

With this new feature one can give more importance to one light source, stealing sampling time from others.

Note that this feature does -not- alter the unbiasedness of the result. The render will be unaffected. Only the noise distribution will change.

This example below features a classic example where this IS drive may be very useful. The scene has two rooms. Both are equally important to the observer. However, the IS values assigned automatically give more prevalence to the larger emitter, making one room be over-sampled, and the other one under-sampled. Compensating for this with the IS drive, one can get both rooms clean in much less time:

Arion Light Manual Importance Sampling

Thank you for reading!

Arion for Rhinoceros v2.7.0 — Changelog

Here’s the changelog for AfR v2.7.0.

– BSDF clamp.
– Per-component GI bounces.
– Fixed Save G-Buffer.
– Metropolis Light Transport sampler.
– Embedded files in document and library files (e.g., .rmtl, .renv, …).
– Fast GI.
– HI/LO GPU priority.
– Menu entry to ‘Set Arion as current renderer’.
– Menu entry to access ‘Render Properties’ directly.
– New UI toolbar.
– Toggle ON/OFF menu and toolbar depending on whether Arion is the current renderer.
– Less intrusive DEMO watermark.
– Setup uninstaller.
– Setup display in “Add/Remove Programs”.
– Inclusion of rcconv.exe and rcshellex.exe in the setup.
– The setup auto-registers Arion on first launch.
– The setup installs a demo scene called “Arion DEMO.3dm”.
– Added access to the main render attributes and the camera properties through RhinoScript.
– Balloon tooltips for each attribute in the UI.
– Revamped “Render Options” panels.
– Revamped Matte Floor.
– Simplified IBL node.
– Fixed a crash/hang on render termination.

Merry Christmas!

Arion 3 page update

Dear users,

We have just updated the Arion 3 presentation page with a new render featuring a tennis ball.

That render makes use of Arion Scatter 3ds Max modifier for the ground (over 2.4 Million instances on this shot) and support for Ephere’s Ornatrix Hair and Fur plug-in for 3ds Max for the ball’s fibers (about 1.5 million fibers with 24 segments each).

Arion 3

Thanks for watching.

HDR Light Studio integration in Arion

Arion v2.5.0 features a re-designed environment editor that includes support for Lightmap’s flagship real-time light editing software; HDR Light Studio.

HDR Light Studio lets you easily create and edit HDRI environment maps in real-time. As you develop your custom HDRI map you see its lighting effect in real-time on your 3D scene.

This video shows the workflow of the HDR Light Studio integration inside Arion, and some various possible uses.

For more information about HDR Light Studio © integration in Arion v2.5.0 and a quick start tutorial, please visit The Arion Knowledge Base here:

http://support.randomcontrol.com/pages/viewpage.action?pageId=918240

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!