ArionFX for Photoshop v3.0.5

Dear users,

We proudly announce that ArionFX for Photoshop v3.0.5 has just been released.

What’s new in ArionFX this time?

We have added a multi-layer OpenEXR file reader. As most of you may know, modern versions of Photoshop can natively open .exr files, but they ignore all the extra channels beyond RGB[A]. On the other hand, most modern render engines (Arion in particular) output a plethora of AOVs in the form of EXR channels (e.g., Alpha, Depth, Specular, MtlID, ObjID, …). Now, ArionFX for Photoshop can read -all- the channels contained in OpenEXR files, and conveniently lay them out as Photoshop layers.

Multi-layered OpenEXR file reader settingsMulti-layered OpenEXR file reader settings

Our importer can read 16-bit floating-point (or) integer OpenEXR files, and 32-bit floating-point OpenEXR files.

Naturally, the importer gets along fantastically well with G-Buffers saved from Arion, but it can be used with -any other- render engine as well. Actually, it can theoretically read -any- OpenEXR file, regardless of what it was generated with.

Additionally, the plug-in can read Arion’s native .agb file format, which is a lossless 32-bit dump of the G-Buffer as we store it in the GPU memory. AGB (Arion G-Buffer) files are an alternative to OpenEXR files for Arion users.

ArionFX for Photoshop v3.0.5 multi-layered OpenEXR readerArionFX for Photoshop v3.0.5 multi-layered OpenEXR reader

This new importer plug-in is released as part of the existing ArionFX product, and is available free of charge to our existing (and new) customers.

Feel free to grab the upgrade from the Customer Area if you are already a customer, or download the DEMO version from our website.

Thank you for reading!

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 stand-alone v2.7.0 — Changelog

Here’s the changelog for Asa v2.7.0.

– Fast GI.
– HI/LO GPU priority.
– Less intrusive DEMO watermark.
– Setup display in “Add/Remove Programs”.
– Revamped Attribute Editor panels.
– Revamped Matte Floor.
– Fixed crash in RCCONV with very old materials.
– Fixed thumbnail rendering in RCCONV.
– Now RCCONV uses the GPU to render shaderballs.
– Simplified IBL node.
– Fixed load of dressings.
– Fixed click-through on hidden objects.
– Fixed scrollbars in the AE.

Merry Christmas!

Arion for 3ds Max v3.0.4.Beta1 — Changelog

Here’s the changelog for Af3 v3.0.4.Beta1.

– Fast GI.
– HI/LO GPU priority.
– Less intrusive DEMO watermark.
– Setup uninstaller.
– Setup display in “Add/Remove Programs”.
– Inclusion of rcconv.exe and rcshellex.exe in the setup.
– Balloon tooltips for each attribute in the UI.
– Revamped “Render Settings” panels.
– Revamped Matte Floor.
– Simplified IBL node.
– Fixed crash in the material editor when abandoning a RCM root node (3ds Max 2015 only).
– Rearranged F10 dialog.
– ActiveShade notifications for Arion Lights.
– Fixed a crash/hang on render termination.

Merry Christmas!

New releases just before Christmas!

Dear Arion users,

We have just released a new round of builds for all our products:

Arion for Rhinoceros v2.7.0.
Arion for 3ds Max v3.0.4.Beta1.
Arion stand-alone v2.7.0.
ArionFX for Photoshop v3.0.4.

All builds feature all the new improvements that we have presented on the blog lately (i.e., better normals, faster coatings, …).

Fresh builds in the Arion product line

The major leap has been taken in Arion for Rhinoceros, because the previous official version was v2.4.4. Now that the Rhinoceros plug-in and the stand-alone are v2.7.0, all our Arion products are aligned feature-wise with RCSDK v2.7.0.

I will talk about some new features and our plans for the v3 Beta program and the DEMO builds very soon.

Thanks for watching!

No energy loss due to divergent normals

Dear Arion users,

The upcoming Asa, Af3, and AfR upgrades feature another big improvement in our rendering core. Surface normals are handled much better now. I will explain what this means:

The following applies to any generic object. But imagine a sphere modelled as a geo-sphere. At each point along the surface there are always two normals. One is the geometry normal, which comes from the flat triangles that approximate the actual sphere by tessellation. The other normal is the smoothed normal.

As the tessellation becomes progressively finer, both normals converge to the exact same vector. However, in practice there is always a more or less significant difference between both normals. This difference may become big in poorly tessellated or aggressively curved surfaces.

This subject about two normals is a classic in computer graphics. Ray-tracing happens on the base (tessellated) geometry, while shading is done using the smoothed (interpolated) normal. The existence of the smoothed normal is the reason why geometry does not look tessellated, but smooth, when shaded or rendered.

However, the divergence between these two normals has a wicked impact in the underlying math of a physically-based render engine, because there is a mismatch between the actual reality that the ray-tracing routines operate on (they hit the actual tessellated geometry) and the interpolated reality the material system operates on.

This divergence cancels out some of the incoming/outgoing energy at each bounce, and requires special and very careful handling.

This problem becomes even worse when bump (or normal) mapping are used. Bump and normal mapping explicitly bend the interpolated normal to produce a shading that does not really correspond to the (otherwise smooth) geometry.

Despite our proprietary RC-BSDF is completely 0-energy-loss since Arion v2.0 was introduced, this problem with normals has been around until v2.7.

Without getting into many abstract details, now the engine makes use of a small numerical ‘gap’ when surfaces are hit which allows the ray-tracing/RC-BSDF routines to make sure that no rays are bounced off inwards the surface (i.e., canceled out) when both normals diverge.

This results in:

1- Better rendering of curved surfaces at grazing angles in general.

2- Perfect (no energy loss) bump and normal mapping, even when the maps used are abrupt or the % is cranked up to a high value.

See some comparisons below. Note how the tier of images on the right does not exhibit black patches or odd darkening at grazing angles.


Arion normal and mapping improvements


Arion normal and mapping improvements

This gap I mentioned is called Trace offset in the UI, and can be configured. However, the default value should do in most scenes as long as they are modelled in proper scale.

Thanks for watching!

Speed improvement in coatings

Dear Arion users.

We are pleased to announce a very important improvement in rendering performance in the upcoming upgrades of Arion:

– Arion stand-alone v2.7.0.
– Arion for Rhinoceros v2.7.0.
– Arion for 3ds Max v3.0.3.

The improvement affects coatings (which are present on nearly every single Arion Material since they were introduced some versions ago).

Until now, the Importance Sampling scheme that was distributing samples between the coating and its substrate was based on the amount of reflectance (which is proportional to the Fresnel value). This used to make perfect sense, but in practice the visual importance of the coated reflection is much higher than the raw amount of reflectance. i.e., because of directionality, a noisy specular reflection is much more disturbing to the eye than a clean reflection with a noisy diffuse substrate.

So we have changed the Importance Sampling scheme, to give much more priority to the coating over the substrate. This results in coatings that render as fast (and usually even faster) than 2-layered materials. Until now, users were reporting that coatings were looking significantly better than the equivalent 2-layered solution, but were leaving much more residual noise. That’s no longer the case. :-)

Click to see a larger resolution comparison

It’s hard to measure the impact of this improvement in terms of a speed gain factor. But since most Arion scenes make a heavy use of coatings, it is evident that noise convergence will be significantly better in the upcoming builds.

Thanks for watching!