OTOY Forums

Hi everyone,

I have stumbled across two slightly weird, quite specific bugs with the new version (2020.2.4) and C4D S24.037. I can provide example files, but they're set up in a couple of clicks, so maybe it's not needed?

1) Placing an Octane Object tag on both a mesh and its parent SubDiv object, then saving the file and finally importing the saved c4d file as an xRef seems to cause a crash on import. Meaning before anything is rendered. It can be avoided by disabling the subdiv object or removing one of the Octane Object tags.

2) Vertex Map Tags, when used inside an Octane Material via C4D's "own" Vertex Node, are only interpreted correctly if the Vertex Map tag is named (exactly) "Vertex Map". Once anything is either added to or removed from that string, the node seems to output a flat grey (?) for all areas of the model. This goes both for Live Viewer and Picture Viewer, on all Render Kernels.

Mabye someone can quickly check if these are not just related to my own local setup? : ) Drivers are nVidia Studio, most recent version (462.59).

Tim0042 wrote:Hi everyone,

I have stumbled across two slightly weird, quite specific bugs with the new version (2020.2.4) and C4D S24.037. I can provide example files, but they're set up in a couple of clicks, so maybe it's not needed?

1) Placing an Octane Object tag on both a mesh and its parent SubDiv object, then saving the file and finally importing the saved c4d file as an xRef seems to cause a crash on import. Meaning before anything is rendered. It can be avoided by disabling the subdiv object or removing one of the Octane Object tags.

2) Vertex Map Tags, when used inside an Octane Material via C4D's "own" Vertex Node, are only interpreted correctly if the Vertex Map tag is named (exactly) "Vertex Map". Once anything is either added to or removed from that string, the node seems to output a flat grey (?) for all areas of the model. This goes both for Live Viewer and Picture Viewer, on all Render Kernels.

Mabye someone can quickly check if these are not just related to my own local setup? : ) Drivers are nVidia Studio, most recent version (462.59).

Please send example scenes for issues.

@aoktar: No problem, here you go: https://drive.google.com/drive/folders/ ... sp=sharing

So for the Object Tag Issue, I had to disable the SubDiv, otherwise it crashes (and I can't save). Enabling the Subdiv with both Object Tags present and the xRef Link active causes the crash for me.

Sidenote, I also tested these via my older C4D R23.110 installation and its older version of Octane 2020.2.3-R3 and didn't encounter any issues there. So this seems to be a recent thing.

Tim0042 wrote:@aoktar: No problem, here you go: https://drive.google.com/drive/folders/ ... sp=sharing

So for the Object Tag Issue, I had to disable the SubDiv, otherwise it crashes (and I can't save). Enabling the Subdiv with both Object Tags present and the xRef Link active causes the crash for me.

Sidenote, I also tested these via my older C4D R23.110 installation and its older version of Octane 2020.2.3-R3 and didn't encounter any issues there. So this seems to be a recent thing.

Thanks, VM issue is like a syntax error for osl script. See video how to fix. That's strange because It should be removing whitespaces to avoid that. Will check it deeply.

Tim0042 wrote:@aoktar: No problem, here you go: https://drive.google.com/drive/folders/ ... sp=sharing

So for the Object Tag Issue, I had to disable the SubDiv, otherwise it crashes (and I can't save). Enabling the Subdiv with both Object Tags present and the xRef Link active causes the crash for me.

Sidenote, I also tested these via my older C4D R23.110 installation and its older version of Octane 2020.2.3-R3 and didn't encounter any issues there. So this seems to be a recent thing.

About crash, it's an NULL exception with the case. Giving detailed feedback is important to make it better as you can see. Thank you! Hope other users do same rather than talking in social media. Then I/We can fix the problems and make it perfect.

@aoktar: Thanks for the video! The quick fix for the Vertex Map Tags (removing the empty spaces in the name) works perfectly.

As for the xRef+ObjectTag scene, I noticed today that even with the object tag deleted on the child mesh and the tag only present on the subdiv parent (both still imported as an xRef), c4d does seem to crash once rendering to the picture viewer. While the scene renders to the Live Viewer without issue.

So yup, any workarounds or possible slight adjustments to the plugin would be a big help! : ) Though I do realize that using xRefs is not part of everyone’s workflow, so most people probably won't encounter this issue.

Tim0042 wrote:@aoktar: Thanks for the video! The quick fix for the Vertex Map Tags (removing the empty spaces in the name) works perfectly.

As for the xRef+ObjectTag scene, I noticed today that even with the object tag deleted on the child mesh and the tag only present on the subdiv parent (both still imported as an xRef), c4d does seem to crash once rendering to the picture viewer. While the scene renders to the Live Viewer without issue.

So yup, any workarounds or possible slight adjustments to the plugin would be a big help! : ) Though I do realize that using xRefs is not part of everyone’s workflow, so most people probably won't encounter this issue.

Probably! And I've fixed two issues and will be a part of 2020.2.4-R2. Thanks for your help

Image Tiles node is still dumb.
In case the file name is for example char_DefaultMaterial_BaseColor_v03.1001.tif image tiles node replaces the version number with tile number and ends up with a file name like this char_DefaultMaterial_BaseColor_v01.0001.tif.
Please note the version number gets changed to a tile number, even though it is explicitly separated from the tile number by a dot.
The only workaround right now it to strip texture names from all numbers except the tile number.
As there are frequently many versions to different textures, this adds a very error prone and unnecessary step to the rendering pipeline.
Please fix it.

Cheers!

bartolos wrote:Image Tiles node is still dumb.
In case the file name is for example char_DefaultMaterial_BaseColor_v03.1001.tif image tiles node replaces the version number with tile number and ends up with a file name like this char_DefaultMaterial_BaseColor_v01.0001.tif.
Please note the version number gets changed to a tile number, even though it is explicitly separated from the tile number by a dot.
The only workaround right now it to strip texture names from all numbers except the tile number.
As there are frequently many versions to different textures, this adds a very error prone and unnecessary step to the rendering pipeline.
Please fix it.

Cheers!

Well, haven't tested the code for this kind of naming scheme. Anyway thanks for reporting it after a long time. I'll test it!

bartolos wrote:In case the file name is for example char_DefaultMaterial_BaseColor_v03.1001.tif image tiles node replaces the version number with tile number and ends up with a file name like this char_DefaultMaterial_BaseColor_v01.0001.tif.

Multiple dots in a file name isn't a good naming convention imo.
What happens when you rename it to "...v03_0001.tif"?