OctaneRender™ 2021.1.6 Tweet

[p3taotoy]

Probably just screwed up… sorry for troubling you with it.
Little frazzled rebuilding my computer.

Have a good weekend and thanks

[J.C]

It is not possible to use vertex or weight map as an input for "Scatter on Surface" node.

[PolderAnimation]

Question about the new 4000 series. Every time a new generation gpu is release it takes a while before you can render in Octane with it.
I assume you already have an 4090 sample card at Otoy? Do the devs have any ETA when we can expect the card to be working in octane?
Would be handy to know when buying cards at the moment.

[abstrax]

It is not possible to use vertex or weight map as an input for "Scatter on Surface" node.

At the moment that is not possible unfortunately as it needs convert the weight texture into an image, which has the same limitations as the image baking texture. We hope to remove that limitation in the future, but it's non trivial.

[haze]

Question about the new 4000 series. Every time a new generation gpu is release it takes a while before you can render in Octane with it.
I assume you already have an 4090 sample card at Otoy? Do the devs have any ETA when we can expect the card to be working in octane?
Would be handy to know when buying cards at the moment.

They are backwards compatible so they will already work with 2021.1.6.

[J.C]

It is not possible to use vertex or weight map as an input for "Scatter on Surface" node.

At the moment that is not possible unfortunately as it needs convert the weight texture into an image, which has the same limitations as the image baking texture. We hope to remove that limitation in the future, but it's non trivial.

That would be a great addition if it was added. I hope you can make it

[PolderAnimation]

It would be extremely helpful if a scatter node would support a velocity vector.
(so when writing out a scatter matrix that you can give a vector for each instance (maybe even with a rotation vector)).

Could this please be implemented?

(I also posted this in the 2022 XB4, but it would be even more handy if it would be implemented in this 2021 release, because that is the current stable version).

[PolderAnimation]

There is a bug in the BC compression.
When setting the compression to BC6 my texture turns red.

It is a 16bit EXR textureI loaded it in as a grayscale texture and the colorspace is set to data.
When I turn the compression to BC6's my grayscale texture turns red.
When I load my 16bit EXR as a color texture and try this, it works fine. Is this something that can be resolved quickly? For the current project it is quite crucial. Let me know. 
I added an ORBX.

[karl]

There is a bug in the BC compression.
When setting the compression to BC6 my texture turns red.

It is a 16bit EXR textureI loaded it in as a grayscale texture and the colorspace is set to data.
When I turn the compression to BC6's my grayscale texture turns red.
When I load my 16bit EXR as a color texture and try this, it works fine. Is this something that can be resolved quickly? For the current project it is quite crucial. Let me know. 
I added an ORBX.

Thanks for the report. There are two issues here.

Minor issue: In the scene, the color space is set to an OCIO role that happens to be called "data", not actually the Non-color data option. I think you're using an ACES OCIO config - in those configs the "data" role is equivalent to the ACES2065-1 color space. You get the same result if you set the color space to the native ACES2065-1 option. That's why you don't see the pattern in the texture - the gamut is too wide for it to come through properly as a valid diffuse map. When you set the color space to Non-color data, you can then see the pattern, but it's still red.

Major issue: There is a bug in the compression library we use (or a misunderstanding in the way we use it) where grayscale input images are interpreted as "redscale", not grayscale. It is surprising nobody has noticed this before. It's easy to fix. I can't guarantee there will be a 2021.1.7 release with this fix though.

For now, the only workarounds are the ones used in your scene - either use an RGB texture, or don't use BC compression.

Edit: There's another workaround - use a channel picker texture to extract only the red channel.

[PolderAnimation]

Hi Karu,

Thanks for the elaboration.
Concerning the minor issue you mention, I looked at the OCIO config and all seem fine, can you confirm that this is not something that is misinterpreted on your side?

The config.ocio file defines the data role / colorspace as follows: (I removed al non-related lines)

Code: Select all

ocio_profile_version: 1

search_path: luts
strictparsing: true
luma: [0.2126, 0.7152, 0.0722]

description: An ACES config generated from python
roles:
  data: Utility - Raw

displays:
  ACES:
    - !<View> {name: Raw, colorspace: Utility - Raw}

colorspaces:
  - !<ColorSpace>
    name: Utility - Raw
    family: Utility
    equalitygroup: Raw
    bitdepth: 32f
    description: |
      The Raw color space
    isdata: true
    allocation: uniform
    allocationvars: [0, 1]