OctaneRender™ 2021.1.5

[abstrax]

Hi all,

This is another maintenance release of 2021.1, which fixes more bugs and issues.

You can find an overview of all new features and improvements of version 2021.1 here.

This version supports all current NVIDIA GPUs with compute model 3.5 or higher. Please make sure to use a NVIDIA Studio driver with version at least 456.38 on Windows or 455.23 on Linux.


Changes since OctaneRender 2021.1.4:

• Added new option to toggle bump/normal mapping for the ambient occlusion AOV.
• Added option to the volume Z depth AOVs that allows you define which depth is considered white (1).
• Added new pin Input axes to the vertex displacement node which provides the ability to choose between different ways how the XYZ coordinates of a vector map should be interpreted in object space. This may be particularly important if your source application works in a left handed coordinate system.
• Fixed an issue where SSS + fake shadow enabled was rendering too dark when it sits inside another specular material that has fake shadow enabled.
• Fixed Vectron geometry becoming invisible if the bounds pin is unconnected. We now use the default bounds in that case which are 10m x 10m x 10x.
• The Bounds input of Vectron nodes doesn't allow negative values anymore and will be clamped at 0. Old scenes with negative values are converted to use very large bounds.
• Fixed another case of SSS being a bit too bright with nested dielectric.
• Fixed incorrect material rendering if RTX is disabled, nested dielectrics are enabled and you move the camera.
• Fixed incorrect rendering of Vectron geometry.
• Fixed texture projections on SDF objects (Vectron and Volume SDFs).
• Fixed a bug where auto bump map doesn't work as expected when box projection is used.
• Fixed object layer masks of volumes which were messing up custom AOVs.
• Fixed a crash during loading an USD scene that contains curves.
• Fixed random net render hang when no local GPUs are used for rendering.
• Fixed render error when using the baking camera with a baking group ID with empty UV data.
• Fixed issue requiring you to re-login when switching versions of Octane on some Linux distros.
• Fixed issue on Windows causing an ORBX file corruption when updating files on remote drives that have been temporarily disconnected (for example by having the computer go to sleep) - see viewtopic.php?f=9&t=79720 for a discussion of the issue.
• Standalone: Fixed potential crash while loading a new project.
• Standalone: Fixed a crash which happens when triggering an export in the geometry exporter with an invalid path (like an ORBX package) or relative paths. Relative paths are now anchored relative to the project directory if a project exist, otherwise relative to the current working directory.
• Standalone: When we relink the inputs of a scripted graph we take now the order and the type of linker nodes into account to resolve duplicate names.

Downloads

Downloads for Enterprise subscription users:

OctaneRender Enterprise Standalone for Windows (installer)
OctaneRender Enterprise Standalone for Windows (ZIP archive)
OctaneRender Enterprise Standalone for Linux

OctaneRender Enterprise Node for Windows (installer)
OctaneRender Enterprise Node for Windows (ZIP archive)
OctaneRender Enterprise Node for Linux

Downloads for Studio subscription users:

OctaneRender Studio Standalone for Windows (installer)
OctaneRender Studio Standalone for Windows (ZIP archive)
OctaneRender Studio Standalone for Linux

Demo downloads:

OctaneRender Demo Standalone for Windows (installer)
OctaneRender Demo Standalone for Windows (ZIP archive)
OctaneRender Demo Standalone for Linux


Happy rendering,
Your OTOY team

[PolderAnimation]

Motion blur on deformed meshes is extremely heavy.
I have and setup with one cube (1.5 million polys) with animation on it. I have export it 2 times.

- first export (out of Houdini) is with packed geo
- second export (out of Houdini) is an normal abc export without packed geo.

Rendertime difference 5 sec vs 9 hours. Render result is the same. But that is a staggering 6480 time slower with deformed geo.
I understand that an deformed mesh is slower to calculate but the difference is incredible, is this correct?

Download link: https://we.tl/t-vSjxgU2TwX

[abstrax]

Motion blur on deformed meshes is extremely heavy.
I have and setup with one cube (1.5 million polys) with animation on it. I have export it 2 times.

- first export (out of Houdini) is with packed geo
- second export (out of Houdini) is an normal abc export without packed geo.

Rendertime difference 5 sec vs 9 hours. Render result is the same. But that is a staggering 6480 time slower with deformed geo.
I understand that an deformed mesh is slower to calculate but the difference is incredible, is this correct?

Download link: https://we.tl/t-vSjxgU2TwX

Yes this behavior is expected and unfortunately a limitation at the moment.

[Zay]

I've seen it twice now where you save to .orbx the opacity greyscale image changes to alpha image instead.
I have auto alpha image turned off in preferences, so why it does that I don't know.

[john_otoy]

I've seen it twice now where you save to .orbx the opacity greyscale image changes to alpha image instead.
I have auto alpha image turned off in preferences, so why it does that I don't know.

Can you PM me a scene where this happens?

[SSmolak]

RaySwitch node can cause huge slowdown if other than Camera and Shadow inputs are used.

[john_otoy]

RaySwitch node can cause huge slowdown if other than Camera and Shadow inputs are used.

Can you provide a simplified scene to demonstrate this? I have PMed you

[abstrax]

RaySwitch node can cause huge slowdown if other than Camera and Shadow inputs are used.

I had a look at your scene and what happens is that if you connect the ray-switch input, the whole geometry (effectively a plane with displacement in some areas) becomes visible and hides the geometry underneath. The geometry underneath uses texture displacement extensively, which is slow to ray-trace. The geometry above also uses texture displacement albeit most parts of the displacement texture is black, i.e. those areas are handled as regular triangles (since the displacement height is 0). And regular triangles can be traced fast. And that's why it renders slowly as soon as you enable the ray-switch texture as now the geometry that is slow to ray-trace becomes visible.

[SSmolak]

RaySwitch node can cause huge slowdown if other than Camera and Shadow inputs are used.

I had a look at your scene...

Thank you all for explanation. This most noticeable during LiveViewer session. Render time has less impact.

[SSmolak]

Chaos Node generate wrong normal map if it is overpowered ( normal map power above 1 )