Problem with render texture Rhino 8 and Octane plugin (6.5 MB)
R8.3dm (4.0 MB)
R7.3dm (2.3 MB)

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


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

come si può risolvere?


@Jussi_Aaltonen is this related to what you have been working on wrt Keyshot?

@ltonucci2 when I render this with Raytraced / RhinoCycles (after converting to pbr) it looks just fine.

Hi, do you also use Octane along with other rendering programs?

I don’t use third-party rendering solutions, I just develop Raytraced / Rhino Render.

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.

@nathanletwory So, yes, that seems to be the case.

@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?

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.

Thanks @Jussi_Aaltonen

If I load the R7.3dm file at the top of this thread into Rhino7, and render out the UV Coords, I get

…which is correct.

If I load the same file into Rhino8, I get the following - where you can see the bottom mesh object has incorrect UV’s.

I don’t understand why Rhino 7 and 8 are treating this file differently.

As a test, I added that image map to a Rhino material and assigned it to the mesh. All looked good with the mapping channel set to 1.

However, mapping channel 2 actually matches the Octane plugin UV’s.

So it looks like mesh.TextureCoordinates is returning UV map 2, instead of UV map 1?



Good morning, sorry for my ignorance, but now that the problem has been identified, what solution should be adopted?

Seeking a response from @Jussi_Aaltonen on the above in order to progress a solution.

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,

Yes - would be great to get a response please. @Jussi_Aaltonen @nathanletwory

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

This makes no sense to implement. The average user can already experience all of the Test commands anyway.