FluidRay RT 0.9.7 Released

We just released FluidRay RT 0.9.7. Here’s the feature list:

  • The selected material is now highlighted in the RenderView
  • Multiple light channels using Light Path Expressions and labels
  • Normal Mapping
  • New shading modes (Wireframe and Wireframe On Shaded)
  • Filter toggles in the Outliner
  • Possibility to duplicate nodes in the GraphView
  • Possibility to select the number of threads in the RenderView
  • Status bar in the RenderView
  • Improved UI with icons in the Outliner and GraphView
  • Alpha channel is now generated in the other shading modes

You can get it in the FluidRay RT download page

 

FluidRay RT 0.9.5 Released

Just released FluidRay RT 0.9.5. This new version includes:

  • Much improved PathTraceIntegrator, providing a much better sampling of thin glass materials
  • Improved sampling for environment illumination in interior renderings
  • General speed improvements
  • Solved compatibility problems with Windows Vista
  • Bug fixes

As usual, you can download it for free here

New interior rendering by Roberto Pittaluga

Roberto Pittaluga just finished a new interior rendering in FluidRay RT:


FluidRay RT real-time interior rendering by Roberto Pittaluga

FluidRay RT 0.9.4 adds Light Path Expressions

We just released FluidRay RT 0.9.4! You can get it here.

This version adds a ton of new features:

  • Light Path Expressions – you can now customize render outputs, to generate alpha, diffuse, glossy, etc. here is a more in depth description: Light Path Expressions explained
  • Much cleaner user interface
  • Multiple RenderView tabs
  • Possibility to save the camera
  • Greately increased interactivity and speed
  • Removed a lot of noise from the PathTraceIntegrator

IMPORTANT: to get the new functionalities in the old scenes, please re-create the IntegratorRenderer and PathTraceIntegrator.

fluidray

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