OctaneRender™ 2020.2 XB2 Tweet

[mojave]

Dear all,

We are happy to share our second experimental build of Octane 2020.2 As with all experimental software please do not use this for production purposes.

This release includes a number of bug fixes and improvements including many of those that have been reported by you in 2020.2 XB1. There are still some outstanding issues that could not make it to this release but we are making good progress and they should be coming in the next one. Thank you all for your support.

Should you find any issues with this release please report using this thread so we can make sure we provide you with the best feedback.

Make sure to use a NVIDIA Studio driver with version at least 451 on Windows or 450 on Linux to use this version. No driver updates are required for macOS 10.13 (CUDA).

This version supports the new NVIDIA Ampere architecture on Windows and Linux. Kepler cards with compute model 3.0 are just supported on macOS.

OctaneRender 2020.2 XB3 has superseded this build.

Changes since OctaneRender 2020.2 XB1:

Bugfixes:

• Fixed medium entry/exit for nested dielectrics.
• Fixed null material conversion where if specular material is connected to multiple destination pins.
• Fixed some cases where hair BSDF was not evaluated correctly.
• Fixed a bug vertex displacement mixer was not working if a connected input has multiple destination
• Fixed gizmos using wrong camera FOV when using universal camera.
• Fixed gizmos which would not work with geometric primitives.
• Fixed some cases where transitions between mediums were not evaluated correctly.
• Fixed invalid memory access when using the code grant for authentication.
• Fixed toon rendering black in some random spots on toon material.
• Fixed a crash when expanding some scripted graph nodes.
• Fixed refraction and transmission filter info passes using albedo instead of transmission.
• Fixed absorption calculation for hair BSDF taking into account nested dielectrics.
• Fixed info kernel when evaluating multilayered material where different layers of share the same normal map.
• Fixed volume ramp evaluation.
• Fixed camera motion blur not always working for the first rendered frame.
• Fixed crash upon startup on macOS.

LUA API:

• Added octane.render.hardwareRayTracingEnabled function which checks whether hardware ray tracing is currently enabled for all devices with support for it.
• Updated octane.render.setDevicesActivity with new optional argument enableHardwareRayTracing which specifies whether hardware ray tracing must be enabled for all devices with support for it.
• Added LUA GUI components for OCIO drop-down controls with the following ids:
  
  • octane.gui.PROPS_GUI_OCIO_COLOR_SPACE_COMBO_BOX
  • octane.gui.PROPS_GUI_OCIO_LOOK_COMBO_BOX
  • octane.gui.PROPS_GUI_OCIO_VIEW_COMBO_BOX

Other changes:

• RTX is now enabled by default.
• Always apply saturation settings regardless of the output color space.
• Added toggle to all kernel nodes except for info to simulate the old behaviour by disabling nested dielectrics.
• Improved command line usage information output
• Performance optimizations for Volta (CM. 7.0) hardware which result in ~30% extra OB score.

Downloads

Downloads for Enterprise subscription users:

OctaneRender Enterprise 2020.2 XB2 Standalone for Windows (installer)
OctaneRender Enterprise 2020.2 XB2 Standalone for Windows (ZIP archive)
OctaneRender Enterprise 2020.2 XB2 Standalone for Linux
OctaneRender Enterprise 2020.2 XB2 Standalone for macOS (CUDA)

OctaneRender Enterprise 2020.2 XB2 Node Windows (installer)
OctaneRender Enterprise 2020.2 XB2 Node for Windows (ZIP archive)
OctaneRender Enterprise 2020.2 XB2 Node for Linux
OctaneRender Enterprise 2020.2 XB2 Node for macOS (CUDA)

Downloads for Studio subscription users:

OctaneRender Studio 2020.2 XB2 Standalone for Windows (installer)
OctaneRender Studio 2020.2 XB2 Standalone for Windows (ZIP archive)
OctaneRender Studio 2020.2 XB2 Standalone for Linux
OctaneRender Studio 2020.2 XB2 Standalone for macOS (CUDA)


Happy rendering
Your OTOY NZ team

[funk]

Thanks team.

I submitted a bug in the previous thread:
viewtopic.php?p=389103#p389103

The scene renders now, but seems to be missing (or has very little) motion blur when compared to 2020.1.5

You can make this more obvious by changing animation settings > shutter time = 100%

[funk]

I also submitted an issue with 2020.1.5, where the cryptomatte pass was rendering a lot brighter than 2019.1.5, when an environment medium is used.

I just tested this in 2020.2 XB2 and it has the same issue. The files are attached to this post:
viewtopic.php?p=389797#p389797

[Daniel_Ward]

Hi Guys,

for me, if I open XB2 and try to add a "Geometric Primitive", it immediately crashes to desktop every time.

Cheers, Dan.

[Kalua]

Hi Guys,

for me, if I open XB2 and try to add a "Geometric Primitive", it immediately crashes to desktop every time.

Cheers, Dan.

Same here.
I am looking forward to see all other features. Do you have ETA for XB3?

[jimho]

Probably let you guys see what I see, may helps...
A quick testing scene is like this

I did it in XB1 either, when export what I get is like this:

Now I was expecting things could be better in XB2,

Anything has changed?
It is fraustrated.the gamma issue is ignored which makes huge different

when opening in photoshop, all the image is using octane's by default "builtin RGB profile" to import(see below snapshot),
if an image is attached a color profile, means it is color managed, if this color management is in the right way,
all the image should be looking the same...

non of the exports is prcisely reflecting the viewport's color

BTW the exr in aces are also not in a right way.

I can fix this mannually, the question is can Otoy do it correct directly.

[jimho]

Correct color management make a image looking the same in different apps...

Or Like this

the original is like this:

[jimho]

As a result of color management, manually attaching proper color profiles, and manually apply the gamma value, then all different exports can finally meet the original viewport looking,

My question is Why we can not get these directly?

[funk]

I posted a bug in the 2020.1.5 thread and it's also reproducible in 2020.2 XB2, so Im posting here.

There seems to be a regression with adaptive sampling in 2020.x, preventing DOF from emissive materials from being cleanup up. It works as expected in 2019.1.5.

See this post for the ORBX: viewtopic.php?p=390004#p390004

[karl]

Probably let you guys see what I see, may helps...
A quick testing scene is like this

2020.2.XB2_2.JPG

I did it in XB1 either, when export what I get is like this:

2020.2.XB1_titled.jpg

Now I was expecting things could be better in XB2,

2020.2.XB2_titled.jpg

Anything has changed?
It is fraustrated.the gamma issue is ignored which makes huge different

when opening in photoshop, all the image is using octane's by default "builtin RGB profile" to import(see below snapshot),
if an image is attached a color profile, means it is color managed, if this color management is in the right way,
all the image should be looking the same...

ps_profile.JPG

non of the exports is prcisely reflecting the viewport's color

BTW the exr in aces are also not in a right way.

I can fix this mannually, the question is can Otoy do it correct directly.

The change to add the ability to export a scene-linear EXR file including the tone mapping settings (and a few related changes) just didn't make it into XB2, but it will be in XB3. The option is called "Force tone mapping"; in this case you would use it in conjunction with the default color space for EXR export (linear sRGB).

To explain the differences in those screenshots:

• There appears to be a difference in saturation between the XB1 and XB2 screenshots. I guess this is a change in the scene? Nothing should have changed so let me know if it's the exact same scene.
• The EXR ToneMap image is too bright due to Photoshop interpreting sRGB as linear sRGB (or equally, Octane passing sRGB off as linear sRGB on export), as we discussed before. XB3 fixes this by never saving a non-linear color space to an EXR file.
• The EXR Linear image is darker than the Octane Viewport due to using Photoshop's tone mapping instead of Octane's tone mapping. Neither one is objectively "right"; there are just many different methods of preparing a scene-linear image for display (this is something that OCIO can address, if used consistently across all applications).
• The difference between the PNG Tonemap image and the Octane Viewport image is interesting, and not something I can reproduce myself. I would guess that it's due to different display color management between Octane and Photoshop. Are you using the same display color profile in both applications?