OTOY Forums

Hello!
Sorry for may be dumb questions...
What a chance to get Motion Blur of OctaneScatter objects simple way? (no MoBlur with different settings)
Aaaand which way get a right MoBlur with MoCloner and RenderInstance? (instances chaotically change their position in PV and look weird in a LV)

Tested on this and older 2020.1.5 plugin versions.

Please see attached image. Thank you

Does ACES in Octane change how the image is tone mapped compared to using the standard camera imager and adding some highlight compression? Or does it not do any tonemapping?

james_conkle wrote:Does ACES in Octane change how the image is tone mapped compared to using the standard camera imager and adding some highlight compression? Or does it not do any tonemapping?

Yes, ACES OCIO does its own tone mapping.

Quick test:

• ACES OCIO Rec.709:
  
• LDR + maximum "Highlight Compression"
  

Thanks lanklaf! Really looking forward to trying 2020.2 out for that reason and that it'll transfer into DaVinci Resolve for grading.

Thanks lanklaf! Really looking forward to trying 2020.2 out for that reason and that it'll transfer into DaVinci Resolve for grading.

james_conkle wrote:Thanks lanklaf! Really looking forward to trying 2020.2 out for that reason and that it'll transfer into DaVinci Resolve for grading.

About grading, here's how to use LUTs with ACES OCIO:

viewtopic.php?f=51&t=76668
Camera Imager's "Custom LUT" option is not available in OCIO mode.

It's very handy if you are exporting a LUT from DaVinci.

I'm going to jump in here with a few corrections about OCIO support in Octane (I'm the dev who implemented it and I just came across this thread).

lanklaf wrote: The intermediate color space must be ACES if you want the correct ACES file.

This isn't correct - as long as the two halves of the intermediate color space ("Octane" and "OCIO") are set to the same value, the result will be identical and correct. You can set them both to linear sRGB, or you can set them both to ACES2065-1 - it makes no difference as long as the two values match each other.

lanklaf wrote: Aces workflow setup:

- in Octane all (sRGB, Linear sRGB and ACES2065-1 textures) are automatically converted to ACES2065-1 or sRGB.
No IDT for textures required.

This isn't correct - all textures are interpreted as sRGB or linear sRGB (or sRGB with an alternative gamma) depending on the gamma of the image texture node. There is not yet support for textures in ACES or OCIO color spaces (although it's planned for 2021). The ACES and OCIO support in Octane is currently output only (that's why there's no ability to select the color space for a texture).

lanklaf wrote: - Working space setup:
"CS = color space"
ACES2065-1

Linear sRGB

Per my first comment in this post, these two setups will produce identical results. Nothing here is related to IDTs.

lanklaf wrote: - Octane cannot render in ACES CG, instead it renders in ACES2065-1 and converts it to ACES CG.
In Settings > Color Space, you choose the EXPORT color space, not the Working color space.
---

Octane is a spectral renderer and doesn't render internally in any RGB color space (i.e. there is no working space). It can be considered to output directly in the color space chosen, be that ACEScg, ACES2065-1 or any other space available.

karu wrote:I'm going to jump in here with a few corrections about OCIO support in Octane (I'm the dev who implemented it and I just came across this thread).

Thanks @karu!!
Uh, we really need a manual
So, what's the point of this new "Color management" tab, if it makes no difference

lanklaf wrote:

karu wrote:I'm going to jump in here with a few corrections about OCIO support in Octane (I'm the dev who implemented it and I just came across this thread).

Thanks @karu!!
Uh, we really need a manual
So, what's the point of this new "Color management" tab, if it makes no difference

It's very important that the two settings be set to the same color space - that's why the settings are there. But what that same color space actually is doesn't matter.

Octane can't automatically set them to the same color space, because it doesn't have any information at all about the color spaces in an OCIO config except their names. I am working on adding the ability for it to do some guessing, based on color space names, that should enable Octane to make the right guess in 99% of cases, so in future versions you shouldn't need to set the intermediate color space manually. But for now, those color management settings are important.

karu wrote:

lanklaf wrote:

karu wrote:I'm going to jump in here with a few corrections about OCIO support in Octane (I'm the dev who implemented it and I just came across this thread).

Thanks @karu!!
Uh, we really need a manual
So, what's the point of this new "Color management" tab, if it makes no difference

It's very important that the two settings be set to the same color space - that's why the settings are there. But what that same color space actually is doesn't matter.

Octane can't automatically set them to the same color space, because it doesn't have any information at all about the color spaces in an OCIO config except their names. I am working on adding the ability for it to do some guessing, based on color space names, that should enable Octane to make the right guess in 99% of cases, so in future versions you shouldn't need to set the intermediate color space manually. But for now, those color management settings are important.

Okay, thank you again!