Adaptive sampling
We added support for adaptive sampling to the direct lighting and the path tracing kernels. Adaptive sampling disables sampling for pixels that have reached a specified noise level. This allows you to bump up the maximum samples quite high and then rely on the adaptive sampling to figure out which pixels actually need that many samples and which don't.
This feature is mostly useful in scenes that have areas that are a lot more noisy than other areas. It will not help if your whole image is just one noisy mess.
The new settings in the direct lighting and path tracing kernel nodes are:
- Adaptive sampling: Enables adaptive sampling.
- Noise threshold: Specifies the smallest relative noise level. When the noise estimate of a pixel becomes less than this value, sampling will be switched off for this pixel. Good values are in the range of 0.01 - 0.03. The default is 0.02, which is pretty clean.
- Min. adaptive samples: Specifies the minimum samples that must have been calculated before adaptive sampling kicks in. The reason for this option is the fact that the noise estimate of a pixel is just an estimate with a fairly large initial error. The higher you set the noise threshold, the higher you should also set min. samples, to avoid artifacts.
- Pixel grouping: Specifies the number of pixels that are handled together. Only if all pixels of a group have reached the noise level, sampling will stop for all of these pixels.
- Expected exposure: The expected exposure should be approximately the same value as the exposure in the imager or 0 to ignore this setting. The default is 0. It's used by adaptive sampling to determine which pixels are bright and which are dark, which obviously depends on the exposure setting in the imaging settings.
If set to something not 0, adaptive sampling tweaks/reduces the noise estimate of very dark areas of the image. It also increases the min. adaptive samples limit for very dark areas which tend to find paths to light sources only very irregularly and thus have a too optimistic noise estimate.
To visualize the progress you can enable the noise pass in the render passes node. The pass is only calculated when adaptive sampling is enabled. The green pixels in that pass mark those pixels that have reached the specified noise limit. This mask is re-calculated every time a new result is blended into the film buffer.
To allow tweaking the adaptive sampling parameters, these parameters will not restart rendering:
- Noise threshold
- Min. adaptive samples
- Expected exposure
- Noise pass
New DOF options and DOF support for the panoramic camera
To allow different bokeh shapes than just circles, we added these new options to the depth of field settings of the thin lens camera node:
- Bokeh side count: Defines the number of sides of the bokeh shape, which is usually the number of blades of the diaphragm in a camera.
- Bokeh rotation: Defines the orientation of the bokeh shape.
- Bokeh roundedness: Defines how round the bokeh shape sides should be rendered.
While we were at it, we also added depth of field to the panoramic camera, which was requested a few times. We are not sure how useful DOF in panoramic renderings is, but it doesn't do any harm.
New texture nodes
We added a triplanar mapping texture which blends between 6 different textures depending on the surface normal, similar to box mapping but with smooth transitions between the 6 faces of the "blend cube". The transition can be controlled via the blend angle. The orientation of the "blend cube" is controlled via the coordinate space and blend cube transform parameters.
Each of the 6 blended textures can be set up independently and has its own projection providing maximum flexibility, but to allow the quick setup of the most common use case, we added a new triplanar projection node, which only works for textures that are inputs of a triplanar texture node. What internally happens is that the triplanar map texture calculates the UVW coordinates, which are then passed to the input textures and used by the triplanar projection. Of course, you can still use any other projection if you want.
We also added an add and a subtract texture. The new comparison texture picks one of two input textures based on the comparison result of two other input textures.
The ridged multi-fractal texture node is now working correctly. It has been broken since beginning.
Full texture evaluation of normal maps
Until now only image textures were allowed for normal maps, but sometimes it would be nice to mix or add those or apply some other operations on them, which wasn't possible. To allow all types of textures to be used in the normal map channel, we merged the various types of texture evaluations into one function and keep track of a texture fetch mode (greyscale / spectrum / normal), which depends on the use of the evaluated texture.
Of course, many textures still don't make sense as normal maps, like all the greyscale textures and the gaussian spectrum texture doesn't work correctly either.
Displacement map filters
To reduce visible steps in displacement maps of LDR images, you can enable a filter to blur them over a specified radius. We provide two filter types: A box filter and a gaussian blur filter. With larger filter radii, the gaussian blur usually takes a bit longer to calculate during compilation time than the box filter.
As an example this is a rendering of an LDR displacement map without any filtering:
This is with a filter of radius 4 applied:
And this with a filter of radius 8:
Support for infinite planes
You can now add up to 4 infinite planes to a scene using the new plane geometry node. The UV mapping is aligned with the X/-Z coordinate axis, but you can also apply a transformation to the object using the placement/scatter nodes. Displacement mapping does not work on infinite planes.
Shadow pass
Added a general shadow pass, which shows all direct light shadows that calculated on the first bounce. This includes sun light, but excludes sky light or texture environment if importance sampling is disabled or the texture environment doesn't consist of an image. The reason for this limitation is that those light source are not included in the direct light calculation and Octane doesn't shoot an explicit shadow ray and with that can't calculate a shadow.
The shadows are weighted by the contribution of the light source casting the shadow. For example, this is how the material ball scene with a daylight environment looks like:
New net render options
We added the possibility to scan multiple subnets for daemons, which might be useful if a master is connected with multiple subnets which have net render daemons. You can also "steal" a slave from a different master. This will stop the slave for the other master and will restart it for the current master:
Complete switch to CUDA 8 and added support for GP100
We completely switched the kernel compilation to CUDA 8. We had to make quite some changes to work around kernel crashes caused by CUDA 8 and to avoid slowdowns caused by the new toolkit. After all these changes were made rendering became a bit faster in most scenes. The difference is not tremendous (2-4%), but there are some cases where is made a larger difference (5-10%).
Please let us know if there are more or less issues with kernel crashes and if you experience any major slowdowns with specific scenes.
We also added support for GP100 GPUs, which are based on the new Pascal architecture and have stacked HBM2 memory.
Overhauled the shortcut manager
The shortcut manager of Octane Standalone was completely overhauled. You can now configure all commands that are registered in Octane and not only those that already have a shortcut. Enable "Show all commands" to make those visible in the manager:
To modify an existing shortcut, select it and then press the key combination and then RETURN to set the new shortcut.
To add a new shortcut, click the "+" button.
To delete a shortcut, select it, press DEL or BACKSPACE to delete the current content and then press RETURN to confirm.
Switch from LuaJIT 5.1 to Lua 5.3
Since LuaJIT isn't developed anymore and still only uses 32bit memory management, we had to switch to "normal" Lua. The missing FFI functionality has been added via a separate FFI module that is available in Octane out-of-the-box. This will finally allow Lua script graphs to be used in Octane plugins on all platforms.
