OctaneRender® 2022.1 (updated 11/28)

[SSmolak]

Roughness for Albedo, Diffuse channel completely stopped to work in other materials than Diffuse and Standard.

[PolderAnimation]

@abstrax If you change the framerate of the attached orbx file to 250 and scrub the timeline, you can see that the point cache cubes do actually posses al the substep information.

On this related note I have another issue: when setting the fps in a file via lua script:

Code: Select all

octane.project.getProjectSettings():setAttribute(octane.A_FRAMES_PER_SECOND, 250)

The attribute is actually changed in the projectSettings node, but the fps box and the timeline are not updated.
The max motionblur streak "length" is adjusted though as this probably uses the information from the projectSettings node.
However, if you save the file and reopen it, the timeline and pfs box are set correctly.

[SSmolak]

Bumps are still broken using UV. Please see how they moved compared to Albedo input :

bumps_again_and_again.jpg

Why this can't be repaired from years ?!

[frankmci]

Bumps are still broken using UV. Please see how they moved compared to Albedo input :
Why this can't be repaired from years ?!

In what context? Albedo and Bump seem to line up in UV space just fine for me. (Pardon the jpg). Can you share an example scene?

Octane 2022.1 R5
C4D 2023.1.3

[abstrax]

abstrax wrote:
Again, the problem is not the interpolation itself but determining the number of intermediate steps. At the moment Octane pretty much relies on the plugins or the input data for those since the plugin usually know best. I don't know exactly why we make an exception for animated rotation inputs, but I think it was done because it's a fairly low-hanging fruit.

I have a follow up question about the current motionblur implementation. You mention that octane currently relies on the plugin or input data to get the substeps needed for motionblur. We do not use a plugin, but octaneRender standalone, so we adjust the input data. We use alembic caches for rendering, some have animated transforms, which work as expected as octane does provides the rotation interpolation. But others use point caches inside the alembic (for deforming objects), with no substeps octane fails to calculate correct motionblur, but this is to be expected, however, I tried exporting alembics with 5, 25 and 100 substeps, but they all have the same wrong motionblur calculation.
The setup is as follows, I moved a cube a few unit of the origin, then rotated around the origin by 90 degrees per frame.
I created the following versions:
red cube: alembic with animated rotation
pink cube: static cube with attribute animator created in octane, the transformValue node of the placement node has animated matrices with 10 substeps
yellow cube: alembic with point cache with 100 substeps
green cube: alembic with point cache with 25 substeps
light blue cube: alembic with point cache with 5 substeps
dark blue cube: alembic with point cache with no substeps
In octane I shifted every cube down, so they do not overlap.
With no motionBlur frames 0, 1 and 2 look as follows:

no_motionBlur.png

With motionblur set to 100% and symmetric shutter alignment frame 1 looks like this:

motionBlur.png

As you can see, the animated rotation alembic and the transformValue attribute animated cubes give the desired result, however none of the point cache cubes seem to use any of the substep information available.
I attached an orbx file that I used to generate these images and includes all alembics.
Am I doing something wrong here or is this an issue in the current motionblur implementation?

Jean-Paul Tossings

Vertex motion blur currently doesn't support sub-steps, i.e. you can't represent curves using vertex motion blur. I think this is the limitation you are seeing here.

[john_otoy]

Roughness for Albedo, Diffuse channel completely stopped to work in other materials than Diffuse and Standard.

As far as I know, this has always been the case. In previous versions, only the diffuse material supported diffuse roughness. In 2022.1, we also added standard surface which includes diffuse roughness on the diffuse layer.

I have attached a scene which you can test in 2021.1.7. It includes a diffuse, glossy and universal material, where the specular layer is set to 0. Changing roughness only affects the diffuse material.

Can you provide a simplified scene where you are seeing a difference between 2021.1.7 and 2022.1?

[john_otoy]

Bumps are still broken using UV. Please see how they moved compared to Albedo input :

bumps_again_and_again.jpg

Why this can't be repaired from years ?!

Please provide a scene so we can look into it.

[SSmolak]

Bumps are still broken using UV. Please see how they moved compared to Albedo input :

Please provide a scene so we can look into it.

In simple scene and material it works fine. It must be caused by other material parameters, nodes. Unfortunately I have new material now so I can't recreate this at the moment but I have this issue very often. When I catch it I will send scene but as I remember some time ago I sent scene with bug ticket to you.

Generally this is very similar to this : viewtopic.php?f=30&t=77459&start=10&hilit=bump
and I reported it here too : viewtopic.php?f=24&t=80814&hilit=bump&start=10#p419382

It seems that bump must be moved sometimes by T.Y 0.0001 to match with other channels like Albedo.

[SSmolak]

Changing roughness only affects the diffuse material.

Yes that I know. I reported it last year why you have diffuse roughness only in diffuse material and in other it is only connected to specularity, glosinness etc level. In Standard it works fine. But in previous versions it was connected to diffuse in Universal too - now it totally ignore Albedo channel.

[john_otoy]

But in previous versions it was connected to diffuse in Universal too - now it totally ignore Albedo channel.

Which previous version are you talking about exactly? I just checked all the way back to OctaneRender 4.05 and the Universal material does not support diffuse roughness there either.