This is the first stable release of 2021.1. It took quite some time to get to this point, but on the other hand a lot of new features and improvements have been added.
This version supports Nvidia Ampere GPUs and as a consequence we had to drop support for old Kepler cards with a compute model < 3.5. And please make sure to use a NVIDIA Studio driver with version at least 456.38 on Windows or 455.23 on Linux.
What's new in 2021.1
Geometry
- Improved support for RTX hardware ray tracing including accelerated instance motion blur on Ampere GPUs
- UV surface tangents are now interpolated if the material has anisotropy set to a value != 0, to avoid visible facets in stretched highlights
- A node to create a surface SDF from a mesh node which can then be combined with other SDFs using the Vectron operators
- Improved Scatter on surface to provide more control for placing scattered objects
Volumes
- Improved rendering of overlapping volumes and increased the number of volumes allowed to overlap in one location to 16
- Added support for light-linking of volumes
- Improved rendering of transparent surfaces inside volumes
- Added support for random color, instance color and instance range textures on volume, SDF and Vectron instances
- Added support for volumes in Cryptomatte AOVs
Materials/rendering
- Clipping material
- Added a new energy preserving GGX BRDF model
- Added STD BRDF
- Added Smooth shadow terminator option to all materials to mitigate "terminator akne"
- Improved Hair material
- Improved AI Light rendering
Textures
- New texture nodes
- New projection nodes
Color processing
- Added the ability to specify a color space for textures
- Added wide-gamut support for textures
- Added the ability to specify the white point for spectral colors
- More accurate color processing across the board
- Switched to OCIO v2
Render AOVs
- Refactored render AOVs
- Added custom AOVs
- Added ability to write object layer masks and material masks to custom AOVs
- Added capture texture to write textures into custom AOVs
- Added global texture AOVs
Output AOVs
- A node to mix light passes
- New output AOV nodes providing additional operations
Other
- Import/export improvements
- OSL improvements
- Lua improvements
- Standalone improvments
Improved RTX support
RTX Hardware Motion Blur (1.5x faster on Ampere)
NVIDIA's Ampere architecture introduces a new generation of RT cores with support for hardware acceleration of animated mesh instances as well as triangle deformations to produce motion blur effects. This version of Octane introduces support for leveraging the new hardware with animated triangle mesh instances.
Before this version, any mesh with at least one animated instance would be handled via software. Instead, now Octane can deal with both static and animated instances in one go and using RTX hardware when running on an Ampere device, this comes especially useful if the scene would also contain static instances of other meshes, which before would require some extra work on the GPU. Removing this overhead produces performance improvements of ~1.5x in production scenes.
We also plan to add support for leveraging RTX hardware with triangle deformations in a future build.
Comprehensive RTX shader support
We are now able to evaluate all shading that requires some form of ray tracing using RTX. This includes the dirt and the new curvature textures as well as accurate rounded edges, which can now fully leverage RT cores in both Turing and Ampere devices, which can yield significant performance boosts in a number of scenes.
(Rungholt scene downloaded from Morgan McGuire's Computer Graphics Archive, Creative Commons CC BY 3.0)
Infinite plane primitives
With this version we start our ongoing work to introduce support for ray tracing of non-triangle primitives from within the RTX pipeline itself.
We noticed that a typical scenario was finding a single infinite plane which would coexist with exclusively triangle primitives in a scene. This used to require some extra overhead on the GPU due to dealing with infinite planes outside the RTX pipeline which is now gone.
We plan to add RTX support for all remaining primitive types in upcoming versions.
Other optimizations
As part of our ongoing collaboration with NVIDIA, ray tracing performance with RTX has also been improved in most production scenes, with overall render results 1-5% faster.
Interpolated surface tangents
Octane now interpolates surface tangent vectors between vertices when a mesh uses anisotropic materials. This allows it to render smoother anisotropic highlights, as demonstrated in the following images with horizontal anisotropy.
SDF from mesh
The Mesh volume SDF node will load a mesh and convert it to a signed distance field. This way you can combine meshes with other Vectron primitives like union or smooth union.
The mesh must enclose a volume without holes. If a surface has a hole, both sides of it may be considered outside and it will not show up in the converted volume.
Improved Scatter on surface
The "Scatter on surface" node has received a number of improvements, including an increase in the maximum number of instances to ~16 million.
New distribution methods have been added to scatter on edges. Furthermore, scattering is now also supported for hair and particle primitives.
A new option, "Poisson disk sampling", ensures that instances scattered on surfaces by area or relative density are not placed too close together.
Volume rendering
Light-linking for volumes
The light pass mask works on volumes, so you can choose which lights will scatter in a volume.
Better overlapping volumes
You can increase the maximal amount of overlapping volumes to be ray marched to 16. And we improved rendering of small dense volumes inside large volumes which usually have very different step lengths.
More accurate handling of volume boundaries
We have fixed a few sources of bias on boundaries between volumes, or where transparent objects intersect volumes. The most common artefacts are too much brightness where light from a strong light source is scattered, or a volume appearing somewhat thicker than it is. This effect got stronger with higher step length, leading to shifts in brightness when tuning step lengths.
Some volumes will change appearance, mainly those where the step length is large compared to the volume.
User instance IDs and random texture for volume, SDF and Vectron instances
The textures random color, instance color and instance range can now be used on volume, Vectron and mesh/volume SDF instances:
Volumes in Cryptomatte AOVs
The way volumes are handled by cryptomatte passes has changed. Octane 2020.2 will add all occlusion due to volume scattering to a single matte called “Volume occlusion”. In 2021 volumes will be separated into mattes similarly to surfaces. For passes relying on the material node name, the name of the medium node will be used.
Legacy mode
Legacy mode option emulate old volume behavior has been removed as the other improvements for overlapping volumes were not compatible with the legacy volume behaviour. You can find some more information about the differences between old and new volume rendering here: viewtopic.php?f=33&t=77817
Clipping material
A clipping material allows trimming geometry within a volume in the space. This opens a number of new possibilities since it allows effectively modifying the original geometry interactively.
The clipping material makes use of the geometry it is attached to and uses this shape to cut out from another geometry that intersects with it. The clipping material by default has a priority of 100 and would clip every geometry with material of priority less than it.
There are a couple of requirements in using the clipping material:
- Clipping material must be the only material attached to the geometry that clips other materials.
- 100% co-planar geometries of clipping material geometry can cause artifacts due to how ray tracing works.
- You can use multiple clipping materials on multiple clipping objects in one scene, but they cannot overlap.
- Geometries that are intended to be clipped must be an enclosed manifolds / water tight. Note that if a single geometry node is broken down into multiple materials, then these materials are considered as a mesh on its own and each of them has to be water tight.
Energy preserving GGX BRDF
The energy preserving GGX addresses the energy loss of the general microfacet model, specifically the GGX BRDF model which was introduced in Octane 3.7. Traditionally, microfacet models can lose a significant amount of energy with increasing roughness, which can introduce unexpected darkening to the material surface as roughness increases. The new energy preserving GGX is aimed at overcoming this deficit and is available across different material nodes and material layer nodes in Octane involving the specular lobe, including:
Material nodes:
- Glossy material
- Metallic material
- Specular material
- Universal material
Material layer nodes:
- Metallic layer
- Specular layer
Below we show images comparing the specular materials of the old GGX model (top row) versus the energy preserving GGX model (bottom row) with increasing roughness from left to right:
Below we show images comparing the metallic materials of the old GGX model (top row) versus the energy preserving GGX model (bottom row) with increasing roughness from left to right:
STD BRDF
The STD BRDF provides an additional parameter Spread that gives you some control over the shape and slope of the falloff of the distribution/spread of reflected rays. The BRDF is available in glossy, specular, metallic and universal materials. Below you can see the material ball with the STD BRDF with roughness 0.2 and 4 different spread values and one version with a GGX BRDF for comparison:
Smooth shadow terminator
All materials have now the option Smooth shadow terminator, which modifies the ray offset locally to avoid terminator artefacts due to too coarse geometry. When enabled it has a tiny performance penalty but most importantly the projected shadow can slightly shift in certain circumstances. Here is an extreme example showing the problem this option tries to fix:
Improved hair material
In Octane 2021.1, we have extended our Hair BSDF model to include some new parameters to enable artists to model an even wider range of appearance for hair/fur:
- Added Zinke’s diffuse lobe to hair material
- Added random roughness to hair material
The above image shows an increasing diffuse contribution of a dark grey diffuse colored lobe. As the diffuse contribution increases, the original specular contribution that was in the previous versions of the hair material would decrease accordingly, until diffuse contribution reaches 100% and specular contribution reaches 0%. Note that hair is generally modelled with a purely specular model, thus it is recommended to not use the Zinke’s diffuse model when rendering hair in general.
The random roughness parameter introduces some randomness to the fixed longitudinal/azimuthal roughness of the hair fiber. As the image above shows, with an increase of random roughness from left to right, the originally rough hair would have an increased variation in roughness. Since the variation ranges from -1 to 1, it is possible for hair with 1.0 roughness to get randomly reduced, thus resulting in less spread in the specular lobe.
Improved AI light
When AI light was first introduced it provided an improvement when sampling light in complex scenes containing both large numbers of emitters or when emitters are partially occluded.
In Octane 2021.1 we introduced improvements to our algorithm which aim to reduce shading variance even more with mesh emitters, allowing to reduce noise at low sample count compared to both non-AI light sampling and previous versions of AI-light.
Below are equal-sample comparisons of renders using the old an new methods:
(Amazon Lumberyard Bistro, Open Research Content Archive (ORCA), Creative Commons CC-BY 4.0)
New texture nodes
Overview
- "Binary math operation" applies math operations on two texture inputs (see below)
- "Capture to custom AOV", which allows you to capture the texture into a custom AOV (see "Custom AOVs" below)
- "Cell noise" which creates a cellular noise like the OSL noise type
cell
. - "Chainmail" from the LiveDB OTOY - Pattern category
- "Color squares" from the LiveDB OTOY - Pattern category
- "Curvature" which determines the local curvature of surfaces and uses that to generate a texture value.
- "Flakes" from the LiveDB OTOY - Pattern category
- "Float to greyscale" to allow feeding a float input into a texture input
- "Float3 to color" interprets a 3 dimensional value input as an RGB texture
- "Floats to color" interprets 3 float values as an RGB texture
- "Fractal" from the LiveDB OTOY - Pattern category
- "Glowing circle" from the LiveDB OTOY - Pattern category
- "Gradient generator", which generates linear, radial, angular, polygonal and spiral gradients
- "Hagelslag" from the LiveDB OTOY - Pattern category
- "Iridescent" from the LiveDB OTOY - Pattern category
- "Moire mosaic" a collection moire patterns from the LiveDB OTOY - Pattern category
- "Normal", which converts the normal into an RGB texture
- "Position", which converts the shading position into an RGB texture
- "Procedural effects" a collection of procedural textures from the LiveDB OTOY - Pattern category
- "Random map", which feeds an input texture into a noise function and outputs the result as a greyscale texture
- "Range", which maps an input range to an output range using different interpolation functions
- "Ray direction", which converts the direction of the incoming ray into an RGB texture
- "Relative distance", which converts the distance to the origin in a specified reference transformation into a greyscale texture
- "Sample position", which takes the sample position and converts it into an RGB color with R and G in the range [-1, +1]
- "Smooth Voronoi contours"
- "Stripes" from the LiveDB OTOY - Pattern category
- "Surface tangent dPdu", which converts the surface tangent along the U axis (in world space) into an RGB texture
- "Surface tangent dPdv", which converts the surface tangent along the V axis (in world space) into an RGB texture
- "Tile patterns" a collection of pattern textures from the LiveDB OTOY - Pattern category
- "Unary math operation" applies math operations on one texture input (see below)
- "UV coordinate", which converts the UV coordinate to an RGB texture
- "Volume to texture", which allows you to convert a grid of a VDB to a greyscale texture (see below)
- "Z depth", which converts the Z depth in camera space to a greyscale texture
Curvature texture
Added "Curvature texture" which maps the local curvature of a geometry to the range of [0 .. 1], where no curvature results in 0 (black) and high curvature in 1 (white). In comparison to the dirt texture, you can limit the curvature detection to convex or concave curves or include both of them. The calculated curvature is also more consistent at small sample counts. You can then use a gradient map node to convert the curvature texure value to into something more exciting, as in the example below:
Math operation textures
The list of math operations supported by the unary and binary math operation nodes is shown below:
Gradient generator
This example project renders the gradients below, which were all generated with the new "Gradient generator" texture: gradient-generator.orbx
Volume to texture
The "Volume to texture" takes a volume node as input and allows reading its data for use by another texture. The mapping can be controlled using a projection similar to other volumetric textures:
LiveDB textures
To make life easier we integrated various LiveDB textures which were provided in the "OTOY - Pattern" category:
The front row of the image below are the different types of the Tile patterns texture and the back row are the different types of the Moire mosaic:
The different types of the Procedural effects texture - all of which can be animated via the time parameter:
[/list]
Other texture changes
- The W coordinate texture has been improved to support translation, scaling, inversion and several different border modes.
- Added blend mode Reoriented normal to the composite texture. The idea of that blend mode is described here. This example scene shows the difference between just adding the normal textures (which internally adds the deviations from the undestorted normal) and using that blend mode in the compositing texture. As you can see, the difference is not overly dramatic, but noticable:
- Added power input to the Noise texture nodes and a new noise type Voronoi.
New projection nodes
We have also added several new projection nodes:
- "Color to UVW", which takes the color of an input texture and interprets it as the UVW coordinate of another texture
- "Distorted mesh UV", which does mesh UV mapping with additional distortions from texture inputs
- "MatCap", which allows you to map MatCap textures onto surfaces
- "Sample pos. to UV", which converts the screen space position of the current sample to the UVW coordinate - this is not the same as a screen space projection, which maps any position in world space into screen space
Note that the full range of texture operations can now also be used to transform UVW coordinates, by first converting a projection node to a texture using "UV coordinate", and after the desired transformations have been applied converting it back using the "Color to UVW" projection node.
Improved color processing
Image textures can now have color spaces assigned - you can choose any of Octane's built-in color spaces or any OCIO color space. If you have ACES textures, you can use ACES2065-1 or ACEScg textures natively or apply any ACES IDT through OCIO. This means Octane can now be used in an end-to-end ACES workflow.
Octane now supports a much wider gamut for RGB colors, and generates smoother (more realistic) spectra without shifts in hue/saturation. Together with wider color spaces being available for textures this allows Octane to support textures containing practically any physically possible color. The smoother spectra may behave differently in the scene, so this new color pipeline can be disabled in kernel settings.
Spectral colors produced by daylight models, blackbody emitters and spectral OSL textures are now interpreted relative to a standard D65 daylight white point. This corrects a blue cast to spectral colors in previous versions of Octane, and can be disabled by selecting the legacy white light spectrum in kernel settings. This image shows the sky as generated by the Hosek-Wilkie daylight model.
Octane 2021.1 includes many other color processing accuracy improvements across the board, including improvements to desaturation and white point adaptation. It also incorporates OCIO v2, which gives more accuracy and means v2 OCIO config files are now supported.
Refactored render AOVs
The render passes node was becoming way too big and since it is static, it is hard to add more AOVs or even per-AOV options without making it explode in size. So we replaced it with a render AOV group node, to which you can add or connect nodes for those render AOVs you are actually interested in. Below is an example showing that some of the render AOV nodes have their own additional parameters and that you can create nested render AOV groups that can be enabled/disabled as a whole:
To avoid the list of render AOV nodes becoming too big, we combined several classes of render AOVs into one node each. For those you choose the actual render AOV via an enum pin. We do this for the following render AOVs:
- Cryptomatte AOVs
- Custom AOVs
- Global texture AOVs
- Light AOVs
- Light direct AOVs
- Light indirect AOVs
The old render passes node is still loaded from older scenes, but you can't create it via the Octane GUI anymore and the new AOVs will not be available either. Also, the underlying code is still using "render pass IDs" to identify/reference render AOVs, and therefor the following limitations still exist:
- If you add the same render AOV multiple times, only the first enabled render AOV node for this AOV will be taken into account.
- There is a maximum number of custom and global texture AOVs. At the moment the number is 20.
- The global render AOV settings at the top of a render AOV group are only taken into account if it's directly connected with the render target node and ignored for any nested render AOV group nodes.
We added an option to toggle shading and backface highlighting to the wireframe AOV node.
The scale factor derived from the maximum value of various info AOVs (like Z-depth, motion blur and UV coordinates) is now applied regardless whether the render result is exported as HDR or LDR image. This made the normalized render AOVs in the render AOV output node obsolete, which got removed.
To allow the export of the Z-depth AOV with unscaled depth values, you need to be able to set the maximum depth to 1. But this breaks the depth of the environment which was applying the maximum depth value. To solve this problem we added a new environment depth input to the Z-depth AOV node.
Custom AOVs
Custom AOVs are just an RGB container that can be used to capture certain aspects of your scene via different methods. You can write specific object layer or material masks into custom AOVs and choose whether the mask should be written into all channels or only into the red, green or blue channel:
We also added the possibility to capture textures via capture to custom AOV texture nodes. The idea behind those is to write the input texture to the specified custom AOV and pass the input texture value through to the destination of the capture texture node. You can also specify an "override" texture, which will be written to the customn AOV instead. The input texture is still what is passed through to the destination. This is useful if you either want to do some additional processing of the input texture before it's written to the custom AOV or to just record some other texture, whenever the input texture gets evaluated.
The custom AOVs themselves have an option to control whether it only records hits of camera/primary rays or if it should also record hits after specular reflections and/or refractions. This scene demonstrates various parts of the custom AOVs: custom-aovs.orbx
You can see the main AOV and custom AOVs 1, 2 and 4 below, rendered with different visibility options. The object layers for the plane and the two objects are recorded separately in the red, green and blue channels of custom AOV 1. A mask for the glass material is recorded in the RGB channels of custom AOV 2. And custom AOV 4 shows the captured opacity texture of the diffuse layer of the inner cylinder.
Global texture AOVs
Global texture AOVs allow you to apply a texture to the whole scene including or excluding the environment. They are rendered as info AOVs, which means that the info AOV settings are applied to them as well. You can overwrite the alpha channel with your own texture, or use the default behavior which is equal to the alpha channel of the other info AOVs.
This project contains all examples below: global-tex-aovs.orbx
Below you can see a quick example of a "debug" texture to quickly asses your UV maps, normals and back faces (indicated by a red tint) and where you can see the effect of the option "Include environment":
Here we use the global texture AOV to calculate some simple fog/haze that is then comped on top of the main AOV:
And this example uses a global texture to generate a gradient (using the new gradient generator) over the whole frame which is then used to blend between some wireframe "look" and the main AOV. The key here is to use the new "Sample pos. to UVW" projection in the gradient texture, which maps the sample position from screen space to UV space:
New output AOVs
- The "Light mixing" node is a utility node to conveniently edit the contributions of light AOVs. Please make sure that all the required light AOVs are enabled in the render AOV group for light mixer node to work as expected.
- The "Color correction" node can adjust the color of an output AOV - similar to the color correction texture.
- The "Clamp" node clamps an input value between a minimum and a maximum.
- The "Map range" node linearly maps an input range to an output range.
Below you can see the light mixer applied to the good old ATV scene:
Other
Import/export improvements
- We added an initial first implementation of a USD importer. There is still plenty of work to be done and we are planning to add USD export as well, and it comes with these limitations:
- Motion blur is not supported.
- Only
USDPreviewSurface
materials are imported.
- Added support for particle UV coordinates to the Alembic importer as long as they are either named "uv", "uvs", "uvw" or "uvws" and have the correct data type.
- In Alembic exports, the mesh preferences for the maximum smoothing angle and for welding vertices are now stored for subdivided meshes, too.
- Switched to OpenVDB 7.0.
OSL improvements
-
raytype("camera")
andraytype("shadow")
work now in emission textures. -
getattribute("hit:t", var)
will return the hit distance of the ray the triggered the texture evaluation. This works for path and shadow rays. - Added meta data
string variant
to point inputs which, if set to"image"
, indicates that the input is to be treated similarly to a projection of image texture. I.e. rotations are around (0.5, 0.5) and not around (0, 0). - Added meta data
string type
to matrix inputs which, if set to"uvw
, indicates that the input is an UVW transformation. I.e. all UVW transform nodes encountered up to the OSL texture node will be premultiplied to the input matrix (similar to the UVW transformations of other texture nodes). - Object layer color can now be accessed in OSL via the attribute
hit:obj-color
.
Lua improvements
- Added
useImageProjection
toPROPS_PROJECTION_PIN_INFO
to indicate if a pin will treat projections similar to projections of image texture nodes, where rotations are around (0.5, 0.5) and not around (0, 0). - Added
isUvwTransform
toPROPS_TRANSFORM_PIN_INFO
to indicate if a transform pin is for UVW transformations, i.e. UVW transform nodes up to this texture node will be be applied to the UVW transformation of this input. - Added
movableInputCountAttribute
andmovableInputPinCount
toPROPS_NODE_INFO
. Those two fields describe whether dynamic pins of a node can be moved and how many of these pins are grouped together. - Updated
PROPS_RENDER_PASS_INFO
to provide thedescription
,nodeType
andsubType
for a specific render pass ID. The latter two are necessary for the overhauled render AOV system. - Added support for defining ID + label pairs for enum inputs of Lua scripted graphs (see
octane.scriptgraph.PROPS_ENUM_PIN_INFO
).
Standalone improvements
- Added the concept of "movable inputs" to nodes like the composite texture node or the render AOV group node. Those inputs have an additional button that functions either as handle for drag&drop or opens a popup menu to move the input up/down or delete it.
- The "find node" item command is now listed in the Edit menu and the keyboard shortcut preferences.
- Added icons to all application and edit commands that didn't have any yet.
Changes since OctaneRender 2021.1 RC 3:
For those people who have followed along the development releases, here the changes since the last development build:
- Added power input to the Noise texture nodes.
- Added noise type Voronoi to the noise texture node.
- Added new Cell noise texture node.
- In Alembic exports, the mesh preferences for the maximum smoothing angle and for welding vertices are now stored for subdivided meshes, too.
- Fixed render failure when using null material and render layers.
- Fixed issue that a clipping material with emission needed the double sided option ticked to see the emission on the clipped surface.
- Fixed different artifacts using clipping material, caused by large ray epsilon for sharp convex mesh with an acute angle. For that, a custom ray epsilon option was added to the clipping material.
- Fixed dielectric IOR map set to 1.0 not matching the fixed float IOR of 1.0.
- Fixed incorrect vertex displacement auto-bump for procedural textures.
- The sRGB/linear sRGB colorspace of image textures referenced by OBJ material files is now set depending on their storage type (see viewtopic.php?p=405155#p405155).
- Fixed crash on Linux when accessing the LiveDB.
- Fixed a memory leak in the USD scene loader.
- Fixed platform dependent object placement by scatter nodes. This will unfortunately result in a different placement, compared to previous versions.
- Fixed a render failure during tone mapping of an output AOV, which happens when a scene uses a baking camera.
- Fixed sorting order of render AOVs in the render AOV output node.
- Lua: Added support for defining ID + label pairs for enum inputs of Lua scripted graphs (see
octane.scriptgraph.PROPS_ENUM_PIN_INFO
). - Standalone: Fixed undo not reverting the input value change of an OSL texture node after it gets recompiled.
Downloads
Downloads for Enterprise subscription users:
OctaneRender Enterprise 2021.1 Standalone for Windows (installer)
OctaneRender Enterprise 2021.1 Standalone for Windows (ZIP archive)
OctaneRender Enterprise 2021.1 Standalone for Linux
OctaneRender Enterprise 2021.1 Node Windows (installer)
OctaneRender Enterprise 2021.1 Node for Windows (ZIP archive)
OctaneRender Enterprise 2021.1 Node for Linux
Downloads for Studio subscription users:
OctaneRender Studio 2021.1 Standalone for Windows (installer)
OctaneRender Studio 2021.1 Standalone for Windows (ZIP archive)
OctaneRender Studio 2021.1 Standalone for Linux
Demo downloads:
OctaneRender Demo 2021.1 Standalone for Windows (installer)
OctaneRender Demo 2021.1 Standalone for Windows (ZIP archive)
OctaneRender Demo 2021.1 Standalone for Linux
Happy rendering
Your OTOY team