This site uses cookies. By continuing to browse the site, you are agreeing to our use of cookies.
Learn moreOKWe may request cookies to be set on your device. We use cookies to let us know when you visit our websites, how you interact with us, to enrich your user experience, and to customize your relationship with our website.
Click on the different category headings to find out more. You can also change some of your preferences. Note that blocking some types of cookies may impact your experience on our websites and the services we are able to offer.
These cookies are strictly necessary to provide you with services available through our website and to use some of its features.
Because these cookies are strictly necessary to deliver the website, refusing them will have impact how our site functions. You always can block or delete cookies by changing your browser settings and force blocking all cookies on this website. But this will always prompt you to accept/refuse cookies when revisiting our site.
We fully respect if you want to refuse cookies but to avoid asking you again and again kindly allow us to store a cookie for that. You are free to opt out any time or opt in for other cookies to get a better experience. If you refuse cookies we will remove all set cookies in our domain.
We provide you with a list of stored cookies on your computer in our domain so you can check what we stored. Due to security reasons we are not able to show or modify cookies from other domains. You can check these in your browser security settings.
We also use different external services like Google Webfonts, Google Maps, and external Video providers. Since these providers may collect personal data like your IP address we allow you to block them here. Please be aware that this might heavily reduce the functionality and appearance of our site. Changes will take effect once you reload the page.
Google Webfont Settings:
Google Map Settings:
Google reCaptcha Settings:
Vimeo and Youtube video embeds:
New Interior renderings by Roberto Pittaluga
/in 3D Rendering, Architecture, Interior DesignTwo brand new interior renderings by Roberto Pittaluga:
FluidRay RT 0.9.5 Released
/in 3D Rendering, News, Software ReleasesJust released FluidRay RT 0.9.5. This new version includes:
As usual, you can download it for free here
New interior rendering by Roberto Pittaluga
/in 3D Rendering, Interior DesignRoberto Pittaluga just finished a new interior rendering in FluidRay RT:
FluidRay RT 0.9.4 adds Light Path Expressions
/in 3D Rendering, Software ReleasesWe just released FluidRay RT 0.9.4! You can get it here.
This version adds a ton of new features:
IMPORTANT: to get the new functionalities in the old scenes, please re-create the IntegratorRenderer and PathTraceIntegrator.
FluidRay RT 0.9.3 Released | Real-time material preview | Better UI
/in 3D Rendering, News, Software ReleasesFluidRay RT 0.9.3 is available for download.
This new version brings a lot of improvements in user interface interactivity and ease of use:
Light Path Expressions
/in 3D RenderingWhen 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?
/in 3D RenderingWe’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:
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
/in 3D Rendering, News, Software ReleasesHi Everybody,
We just released FluidRay RT 0.9.2. This new version includes:
creating a new integrator renderer. Thanks to the bidirectional
integrator, interior renderings converge much faster.
As usual, you can find it in the download page
FluidRay RT 0.9.2 Released | Sharper Filering | Better interior renderings
/in 3D Rendering, News, Software ReleasesHi Everybody,
We just released FluidRay RT 0.9.2. This new version includes:
creating a new integrator renderer. Thanks to the bidirectional
integrator, interior renderings converge much faster.
As usual, you can find it in the download page
FluidRay RT 0.9.1 Released – Less Noise – Better Bidirectional Path Tracing
/in 3D Rendering, News, Software ReleasesWe 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.