I’m using Rhino 8 SR6 8.6.24101 and I’m using Octane Render 2023.1.0.137. Previously, I was using Rhino 7 and this issue wasn’t present. The problem is that when I insert a texture into the Rhino preview, it looks fine, but when I launch Octane, the result is as you can see in the attached video. I’m also attaching the file for verification purposes.
I have already contacted Otoy and according to them, it is a UV issue in Rhino 8
How can this be resolved?
Best regards
Buongiorno
uso rhino 8 sr6 8.6.24101 e utilizzo octane render 2023.1.0.137
prima usavo rhino 7 e questo problema non c’era.
Il problema è che quando inserisco una texture nella preview di rhino si vede bene mentre quando lancio octane il risultato è come quello che vedete nel video allegato.
Vi allego anche il file per una verifica sul file stesso.
Ho già contattato Otoy e secondo loro è un problema delle UV in Rhino 8
Well, I don’t have access to the full Octane Render but testing with the demo version suggests that Octane simply uses the texture coordinates that are on the render mesh. It works in most cases for Rhino 7 depending on the object - but it’s not reliable.
This is the first I have heard of this (and reading this caused me to spill my coffee!!!). Why wouldn’t mesh.TextureCoordinates return the correct UV coordinates?
@pkinnane Hi, I’d like to help you applying correct texture mapping to the meshes. Is it possible you could use the Rhino 8 version of RhinoCommon?
From a support point of view, I would really prefer to keep the same codebase for the Rhino7 and Rhino8 versions of the plugin. Can you give me some details on the changes that would be needed if the Rhino 8 SDK was used please?
Sorry about that, I hope you didn’t soak your laptop.
I suppose back in the old days each object had only a single set of per vertex texture coordinates and they were always the correct ones for all purposes. But today we have materials with many texture channels each specifying what texture mapping channel or projection to use, so there’s no obvious choice for how the texture coordinates should be computed.
If Octane renders with a single set of texture coordinates then I would suggest picking the texture mapping channel based on the base color texture or if that doesn’t exist then on the transparency or bump texture. Or something like that.
We’ve added new methods to our API’s for Rhino 8 to assist setting up texture coordinates based on materials and textures. They will also work with most WCS projected bitmap textures.
But if you want to stay on Rhino 7 API we’ll try to help.
HI there,
yeah would be great to get a solution as soon as poss please
I have a team here itching to move onto Rh8 but can’t due to this issue as all mapping doesn’t appear as it did in Rh7.
Interestingly I did notice when trying to trouble shot the issue, when selecting the custom unwrap map tool, the map jumped into the correct position in the render port but jumps back when closed, very strange.
Many thanks,
Adrian
Sorry I you had to wait. I will write you some sort of explanation for why we have issues with texture coordinates. And also sample code how to set up texture coordinates using the Rhino 7 APIs.
Here’s Rhino 8 sample code for setting up correct texture coordinates
We tried to offer a workaround until the issues get fixed. There’s a test command in Rhino 8 called TestFillInLegacyTextureCoordinates. Try running that command right before you render.
This reminds me of something I’ve been meaning to mention - there’s so many Test commands, and they do not autocomplete in the CLI. It’d be very helpful if they did, since you have to either type in the entire Test command successfully, or keep a list of the ones you use and copy and paste from that.
ETA - If you don’t want the average user seeing all the Test commands I get that, so maybe you could create a Test command that enables the autocompletion of Test commands in the CLI. Something like TestEnableTestCommandCLIAutocompletion
Sorry @Jussi_Aaltonen - I am very confused by your message above.
I will write you some sort of explanation for why we have issues with texture coordinates. And also sample code how to set up texture coordinates using the Rhino 7 APIs.
Is that in the 2 Rhino 8 sample code links you provided - or is it something you are working on separately and will provide me? I tried to use the mesh.setCachedTextureCoordinatesFromMaterial() function from the RhinoCommon link above, but it is not present.
We tried to offer a workaround until the issues get fixed.
Does this mean there /are/ issues in Rhino8 to be fixed in regard to this UV problem?
Yes, those samples are for the Rhino 8 version. I can’t remember why I posted them there. Sorry for confusing you. My plane is to write you some sample code how to do it with the Rhino 7 API.
The texturing area in Rhino has evolved over the years in a slightly uncontrollable manner. One of the biggest issues we are dealing with is the reckless usage of the ON_Mesh::m_T array. For Rhino 8 we decided to take a step towards deprecating it. We expected things to break and thought we could fix them or help 3rd parties fix them.
And in the case of Octane the fix would be setting up cached texture coordinates and using them. And that fix would have to be on Octane side.
It still seems odd to me that Mesh.TextureCoordinates is returning UV map 2 instead of 1 - seems like a Rhino8 bug to me. Anyway, I will wait for your proposed coding solution.
