We are happy to release the first version of the 2.1x development cycle. We think OctaneRender became a bit more powerful and useful
A lot of things have changed under the hood and therefor we expect there to be still some bugs and issues. Also render passes are not complete yet. On the other hand, we wanted to get the new features out and your feedback as soon as possible. So please consider this more a test or development release which may not be stable enough for a production environment. Of course, our plan is to finish and stabilize OctaneRender 2.1x in the upcoming releases as quickly as possible.
Here is an overview of the major changes since version 2.06:
Render Passes
Render passes are exposed via a new pin in the render target node which you can connect with a render passes node. In the render passes node you can then enable render passes you want to render. In the render view you can then select the pass you want to view, save them all out as separate images or as layered OpenEXR file.
We distinguish between "beauty" and "info" passes. Beauty passes are rendered together with the main beauty pass (the normal rendering). I.e. each one of these requires its own film buffer that needs to be stored additionally to the main film buffer on the device. The info passes are rendered one by one using only one additional film buffer either at the end or when needed. We do this to save GPU memory and because they are fast to calculate.
Please be aware that the render passes are not finished yet. Feel free to let us know which passes you are missing and why you need them, i.e. how you use them in your compositing workflow. Most of the work was integrating render passes into our interactive render framework, which is done now and adding new passes should be more or less straight forward.
Undo System
The OctaneRender Standalone application comes now with an undo system (yay!). To undo the last change press CTRL-Z and to re-do the last "undone" change press CTRL-Y. Again, sounds simple but required quite some effort to make it work. Let us know if you find any issues.
Updated UI Toolkit
Although not a feature per se, it was a lot of work nonetheless: Our UI toolkit and application framework was from 2009 and an update was long overdue. It's now of the year 2014 and we will keep it up- to-date as we go. This also allows use to use more modern UI features like support for high resolution displays.
Pretty much everything in the application needed to be touched so it's quite likely that a few new bugs got introduced. Please let us know if you can find any.
Lua Node Graph
In short: A Lua node graph is a new node graph type that stores a script that gets executed at various points and which defines some inputs and outputs. Every time one of the inputs changes, the scripts gets re-evaluated can then do interesting things, like calculate new values or set up a totally new node graph inside the graph. You can find more information about it in the Lua API browser under the module
octane.scriptgraph
, but we will provide some examples of what you can do with it.Other Render Improvements
We improved the sampling in the direct lighting and path tracing kernels. In most scenes this should reduce the time to get to a similar level than before. And the sampling is now more optimized in a multi-GPU environment and in network rendering.
We also implemented a new path termination strategy, which is a bit tricky to explain: In the past the there was this ominous pin "RR probability" which in most cases only worked good when set to 0. With the new algorithm we try to provide a system where you can tweak render speed vs. convergence (how fast noise vanishes). Increasing the value, will cause he kernels to keep paths shorter and spend less time on dark areas (which means they stay noisy longer) but may increase samples/second a lot. Reducing the value will cause kernels trace longer paths in average and spend more time on dark areas. The current default of 0.3 works good in most scenes, but play with it. For example, in two interior test scenes it actually payed off to set the value to 0.5 - 0.6 which increases the samples/second a lot and then just to render more samples.
The direct lighting and path tracing kernels also have a new option "Coherent mode", which increases the render speed, but causes some "flickering" during the first samples/pixel and should be mainly used for the final rendering and if only if you plan to render 500 samples/pixel or more.
The three changes above together should help you to speed up rendering quite a bit. How much depends on the scene of course.
The turbulence node got a new option "Use turbulence" which is on by default and when disabled, makes the noise variation more "symmetric" around medium brightness. Hard to explain, just try it out with a low octave number and you will see.
Network Rendering
There is a new option in the network settings dialog (enabled by default) which turns on automatic port configuration on the master. If enabled, multiple masters can be used on the same computer which wasn't possible before because only one master could use the specified socket.
Download
Windows
- 32-bit archive
- 64-bit archive
Mac OS X
- 64-bit installer image
Linux
- 64-bit archive
Happy rendering,
Your OTOY NZ Team