Surface mapping is the default mapping if the referenced texture mapping channel does not exist. And it is possible that the ON_Mesh::m_T has been set to surface mapping before Octane starts rendering. All surface render meshes have surface mapping applied by default when they’re created.
Here’s sample code for you how to access the correct mappings using the RhinoCommon 7. If you’re not planning to support sub-object materials you can skip them. That sample does not deal with WCS projected textures - the Rhino 8 sample does.
We are currently investigating the possibility of making Rhino 8 update the ON_Mesh::m_T array. That is because there are so many users having these issues and we’ve been too slow providing 3rd party developers with support how to fix this.
I ask that everyone tests this release to ensure UV coordinates are rendering as expected in Rhino8. In particular, UV coordinates for sub meshes, meshes with sub-object materials, and meshes with different UV mapping on different textures for the same material.
Thanks for the update, however I’ve just tested this release and although the textures are now positioned in the correct position when I hit render, there are a few things I’ve noticed that don’t work anymore, for example, on a opacity map if i hit invert it doesn’t change the material in the octane window instantly or when I refresh the octane window.
It also seems like reflections are not working as they did before either.
Let me know if you need test files, I can’t upload our current work files due to copy right, so I’ll have to create test files to illustrate the problems.
I’ll keep testing to see if there’s anymore issues
Thanks,
Adrian
It’s not clear if you are using Octane materials, or Rhino materials, so it’s hard for me to test. Can you please provide a simple test scene which illustrates these issues?
Hi Paul,
here’s test scene and Octane textures and maps I used, with renders from old and the new test version of Octane.
Let me know if you need anything else…
Thanks,
Adrian
