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!

Much faster coatings – Comparison

Dear Arion users,

Here’s a fantastic example (kindly provided by Jordi Martínez Soler) where the same scene has been rendered in Arion before and after the improvement in coatings mentioned in the post we did two days ago.

Click to see a larger resolution comparison

Both images have been rendered for the same amount of passes.

This improvement will be part of Asa v2.7.0, AfR v2.7.0, and Af3 v3.0.4.

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!

Piracy Armistice

Dear users,

Following the tradition of the past years, we would like to celebrate the Christmas season offering a very generous discount coupon on our shop.

The reason why this year we have used the name “Piracy Armistice” for our Christmas Promotion is the following:

“We have been developing software at RandomControl for the past 14 years. During all this time, we have released several products and many upgrades, and every single time we have experienced the same drama that all software development companies do. For some time, if you’re lucky and your product is welcome by the market, you have sales. But shortly afterwards, some guy steals your software, cracks it, releases it… and bam! Sales stop abruptly. All of a sudden, all your effort of months (or years) becomes… worthless! People are simply unaware of how severe this problem is.”

Cracking software, and also using cracked software, damages software development companies. This, eventually, damages the industry you are supposed to be a part of.

Christmas is a season of peace and love. So this year we would like to make an offer for a truce that we have called “Piracy Armistice”. Until the end of the year, our shop will allow you to buy our products at a 50% discount by using the discount coupon:

N0P1R4CY

Santa being attacked by a gang of pirates

-50% on our shop, merry Christmas!

If you want to buy any of our products, this is a great chance to do so at an incredible price. And if you are using a cracked copy of our software already, this is a great opportunity to act like a pro and do the right thing. :-)

We wish you all a Merry Christmas!

Simplified IBL node

Dear Arion customers,

In the upcoming AfR, Asa v2.7.0 and Af3 v3.0.3, we have simplified the IBL node, avoiding some redundant parameters that we used to have in previous builds:

Simplified IBL node

Thanks for watching!

ArionFX for Photoshop v3.0.3

Dear ArionFX customers and DEMO users,

We have just released ArionFX for Photoshop v3.0.3, which is a Point Release build with some basic clean-ups that catches up with the latest version of our RCSDK.

The new build fixes a little problem that there used to be in the Film grain filter. As reported by some users, every now and then a speckle was showing up. The problem, which is gone now, was caused by an occasional overflow in one of the formulas involved in Film grain.

ArionFX for Photoshop v3.0.3

The new plug-in features 3 other new improvements that will be common to the next versions of all our other products:

1- Better installer. Our plug-ins feature a proper uninstaller now which makes use of the roaming folder. Until now, our plug-in installers were simply copying the plug-in files to the target folder.

2- In-line context help for each configurable attribute, in the form of floating balloon tooltips. The screenshot above displays what they look like.

3- Better watermark (less intrusive and more elegant) in the DEMO.

Thanks for watching!

Arion for Rhinoceros v2.7.0 toolbar

Dear users,

Arion for Rhinoceros v2.7.0 is coming soon.

Among many other improvements that we will detail as soon as we release, we have been doing some improvements in the UI. For example, we have added a toolbar with the most common operations in Arion:

Arion for Rhinoceros toolbar

Thank you for reading!

New installers (and uninstallers)

Dear Arion users,

We have worked a bit on our software setups.

– Now all our plug-in setups feature an uninstaller. Before, only Arion stand-alone would.
– Now all our setups show up in the “Add/Remove Programs” area.
– Now all our setups feature rcconv.exe and rcshellex.exe. Before, only Arion stand-alone would.

In the special case of Arion for Rhinoceros:

– The installer auto-registers the plug-in on first launch.
– The installer handles the plug-in RUI (custom menu and toolbar).
– The uninstaller auto-unregisters the plug-in from Rhino.

New RandomControl installer

Thank you for reading.

LO pro — GPU low priority

Dear users,

We have added a new LO/HI priority switch in the Hardware Configuration panel of all the Arion-based products:

Arion’s low priority toggle

This toggle allows the GPU to breathe, so the system scheduler can gain control of the GPU at regular intervals (e.g., to update the UI). This is of no use for a render-dedicated GPU, but can be of critical importance for a display card which is used to handle the display and to render at the same time.

Arion’s low priority mode in action

A common request that our users and DEMO users have told us about is that Arion exhausts the GPU resources so heavily, that lag in the UI when editing, or when rendering in the background becomes frustrating. Until now, this could only be avoided by excluding the display GPU from the render. While this is a good sign that means that Arion is really exploiting the computing capabilities of the computer, it can become a serious annoyance in some cases. Specially for users with a single GPU in their system.

The new LO prio toggle…

1- …will allow those users (or DEMO users) with a single GPU (shared for display and rendering) to have a smooth UI experience, or even to switch over to other tasks while rendering in the background.

2- …will allow users with multiple GPUs (all of them but one used for rendering exclusively) to use the display card for rendering also, without lagging the UI or the OS.

This feature trades some rendering performance for a much smoother UI/OS, and is of course optional, and disabled by default. After some intensive testing, we have found that the impact in speed is highly dependent on the architecture of the GPUs. It ranges between 15%-40%.

Thanks for reading!