FluidRay RT 0.9.3 Released | Real-time material preview | Better UI

FluidRay RT 0.9.3 is available for download.

This new version brings a lot of improvements in user interface interactivity and ease of use:

  • New browser view with real-time material and texture preview
  • Much improved attribute editor, more compact and with a new color picker
  • Autofocus in the graph view when selecting elements in the scene
  • Search filter in the Outliner and Browser

New FluidRay RT 0.9.3 UI

Light Path Expressions

When working with a rendering software, soon having only the color image as output won’t be enough. A lot of tweaks can be done after the rendering is complete, with photo editing software like Photoshop, or with compositing software like After Effects, NUKE, etc. Examples of tweaks could be overlapping the rendering over an image background, changing the color of a certain light, changing the brightness of caustics, etc. The possibilities are limitless. The reason why it’s done after the rendering is complete is because the rendering can take some time to complete, while image compositing is usually an instantaneous operation.
In order to be able to perform all that compositing work, it is often necessary that the rendering software is capable of outputting more information than just the color image, such as the alpha image(transparency), the Z-buffer, separate light images, and many others, depending on the effects you want to achieve. All these output images are commonly referred as AOVs (Arbitrary Output Variables).
Most rendering software have predetermined set of AOV types, used in the most common scenarios, such as alpha, Z-buffer, etc.
Light path expressions is an idea first developed by Alejandro Conty at Sony Pictures Imageworks as part of Arnold Renderer, and it’s becoming widespread in the rendering industry. It is a simple and elegant solution to express arbitrary AOVs, that is based on regular expressions.
A typical light path expression (LPE) could be: “CD*L”. “C” stands for camera, “D” stands for diffuse, “*” stands for zero or more times, L stands for light. The meaning of the expression is: output the color leaving the light, hitting zero or more diffuse surfaces, and landing on the camera.
Among the many symbols that can be used in LPEs are “G” (Glossy), “S” (Specular), “T” (Transmission), and arbitrary labels.
With this framework, the possibilities offered by light path expressions are limitless.
If you want to learn more about LPEs, here is the wiki page from the inventors: Light path expressions in Open Shading Language.

 

Edit:

To be more precise, as somebody already noticed, the way of representing light paths using regular expressions was first proposed by Heckbert and then further developed by Veach. Sony provides a particular specification of light path expressions, which is becoming widespread in the industry. They also provide an open source implementation inside the Open Shading Language project.

CPU better than GPU?

We’ve been asked a lot lately about why FluidRay RT doesn’t use the GPU for rendering. In this post, we’ll try to answer that question as extensively as possible.

Even if there seems to be a trend toward GPU rendering, GPUs still have a lot of limitations.
For example, the GPU memory is limited (in the order of 1-10Gb) compared to the amount of main memory available (up to 256Gb). This puts serious limitations to the amount of textures and scene’s polygonal complexity. Secondly, GPUs are a hell to develop on. Drivers are often unstable and what works on a driver version may not work on another. Some features are supported only by NVidia cards and not by ATI cards and vice-versa.
Consequently, complex algorithms like bidirectional-path tracing, metropolis sampling, light-path expression and programmable shading are very hard if not impossible to fit all in a general purpose GPU renderer.
For these reasons, a GPU only renderer might lack features, or perform really well on some specific scenes, but very poorly on others.

Some people are opting for the hybrid solution of using the GPU only for the ray intersection part of the algorithm while implementing the rest of the algorithms on the CPU. This still suffers from the GPU memory limitation problem though.

Another possibility is out of core textures and geometry. In this case, you have 2 possible solutions: you either 1. run part of the intersection and texture sampling code on the GPU and part on the CPU or 2. you design some caching system that transfers bits of geometry/textures from system ram to the GPU when the GPU needs it.
In the first case, you would completely loose the speed advantage of having the GPU, because the GPU would be constantly waiting for the CPU to send back the intersection and sampling results. You would basically have a GPU renderer that runs at the same speed (in the best case) of a CPU renderer, most likely at a much lower speed, because of communication and bus transfer issues.
In the case of the caching system, you would run into problems as well: Global illumination algorithms (i.e path tracing and photon mapping) have the big issue of having a very incoherent memory access pattern, essentially, every time you reflect a ray off a surface it can hit virtually any other part of the scene. That means that the cache would be constantly invalidated by requests of bits of geometry/textures that were not present in the cache before. As a result, the GPU would be constantly waiting for data to be transferred in the cache through the bus.
It would be interesting to do some test with a scene that needs, let’s say, 2-3 times the GPU memory and see how the performance degrades.

Considering all those issues, and wanting to have the most general purpose and feature-rich renderer possible, we decided for a CPU-only solution in FluidRay RT. For intersection, we use Intel Embree raytracing kernels, which is CPU only and doesn’t suffer from the memory limitation problem, while still providing an excellent real-time performance.
As far as we know, a fair comparison between raw intersection performance between GPU and CPU haven’t been done yet. Many of the benchmarks out there are just comparing oranges with apples. They should be done, for example, between a single high-end CPU and a single high-end GPU. Also, considering that the results are highly scene dependent, they should be done on a variety of different scenes.
For more in-depth info on the topic, check the SIGGRAPH 2014 paper: Embree – A Kernel Framework for Efficient CPU Ray Tracing

Edit:
Intel Embree has been evolved a lot since this post was writted. Here is some highlights:

  • Subdivision Surfaces
  • Displacement Mapping
  • Hair and Fur Rendering
  • Much improved performance and support for ray packets

References:

Intel Embree Website

Embree – A Kernel Framework for Efficient CPU Ray Tracing

Exploiting Local Orientation Similarity for Efficient Ray Traversal of Hair and Fur

Watertight Ray/Triangle Intersection

FluidRay RT 0.9.2 Released | Sharper Filering | Better interior renderings

Hi Everybody,

We just released FluidRay RT 0.9.2. This new version includes:

  • Much improved bidirectional integrator, now it’s the default when
    creating a new integrator renderer. Thanks to the bidirectional
    integrator, interior renderings converge much faster.
  • Improved filtering (added the sharpness parameter to the Mitchell filter)
  • General improvements in interactivity
  • Snap when making new connection
  • New interior sample scene

As usual, you can find it in the download page

FluidRay RT 0.9.2 Released | Sharper Filering | Better interior renderings

Hi Everybody,

We just released FluidRay RT 0.9.2. This new version includes:

  • Much improved bidirectional integrator, now it’s the default when
    creating a new integrator renderer. Thanks to the bidirectional
    integrator, interior renderings converge much faster.
  • Improved filtering (added the sharpness parameter to the Mitchell filter)
  • General improvements in interactivity
  • Snap when making new connection
  • New interior sample scene

As usual, you can find it in the download page

FluidRay RT 0.9.1 Released – Less Noise – Better Bidirectional Path Tracing

We are glad to announce the release of FluidRay RT 0.9.1! This release brings a lot of improvements in noise reduction and real-time performance:
– The Bidirectional Path Tracer is now very usable and provides much faster convergence, especially in interior renderings.
– The Path Tracer now produces much less noise
– Fixed a bug in Area lights, causing a lot of noise as well
– Fixed fireflies when using the Sun-Sky environment
You can download this version here.

New Architectural Rendering

Hi Everybody,
Alberto just finished a new architectural rendering (model by Mauro Bonan), check it out:
Architectural Rendering in real-time

FluidRay RT 0.9.0 Beta Released | Better Navigation | Rhino Import

Hi Everybody,
We just released FluidRay RT 0.9.0 featuring:
-An Outliner window for better scene navigation (double clicking on the items will go into the corresponding graph in the GraphView)
-Rhino .3dm (OpenNurbs) file import, to facilitate people using Rhinoceros for Interior Design, Architecture and Industrial Design.
As usual, you can get FluidRay RT for free in the download page.

FluidRay RT 0.9.0 | Outliner | Rhino

We are almost ready to release FluidRay RT 0.9.0, with two new major features:
– An outliner for better scene navigation
– Rhino .3dm file import
Stay tuned!

FluidRay RT 0.8.4 | Bidirectional Path Tracing

Hi Everybody, we just released FluidRay RT 0.8.4! New features include:
– Faster convergence and much less fireflies
– New Mitchell filter for sharper images
– New Box filter for faster performance
– Improved Metropolis integrator
– Experimental real-time Birectional Path Tracing
You can get it from the download page

fluidray-0.8.4