vrayMtlFromRhino loses bitmap texture mapping

[graphicmill]

Rhino 8 SR3 2024-1-9
V-Ray 6.20.02

I run a custom Python script that creates a basic material with a chosen bitmap texture, then uses the vrayMtlFromRhino command to convert the basic material to a vray material.

Since upgrading to Rhino 8, the converted material textures do not show in the viewport and on further inspection, the bitmap texture mapping is lost during the vrayMtlFromRhino command:



The Offset values become NAN, and the Rotation is also blank.

This is what the mapping should look like:



Any ideas how to fix this would be really appreciated!

[nikolay.bakalov]

which was the last V-Ray version it did work? The code for Rhino 7 and Rhino 8 is 99% the same, so I doubt it was caused by migrating to V8. It was probably due to migrating to 6.20.x !?

[graphicmill]

It was working fine with the latest V-ray version in Rhino 7.

When installing Rhino 8, I re-installed V-Ray for Rhino 8. That's when the issue started.

Looking at the documentation, it does look like 2-d bitmap texture rotation is new for Rhino 8, hence why I assume it could be the problem: https://docs.mcneel.com/rhino/8/help...s/textures.htm

[nikolay.bakalov]

Hi,

After some investigation it turned out that Rhino 8 is to blame. Apparently McNeel has introduced some "optimizations" to the textures that break the math
The thing is that in V8 the texture transformation's 3rd vector is a zero vector, which makes the transformation matrix a singular matrix:



This is not the case in Rhino 7, so it works there:


You can't see this "bug" in V-Ray UI since the matrix is decomposed and only certain numbers are shown. Rendering also works, since that particular value is not used
However when the V-Ray material is converted back into a Rhino display material in order to show it in the viewport, populating the fields is done by inversing the V-Ray matrix
And as you know, having a 0 on the main diagonal, when doing a matrix inversion, is a recipe for a disaster.

So as a workaround, I suggest you check the matrix determinant, and if it is 0, you check the diagonal values, setting 1 where it is 0, like this (C#)

var uvw = bitmapTexture.UvwTransform;
if(uvw.Determinant == 0)
{
    if(uvw.M00 == 0)
        uvw.M00 = 1;
    if(uvw.M11 == 0)
        uvw.M11 = 1;  
    if(uvw.M22 == 0)
        uvw.M22 = 1;
    if(uvw.M33 == 0)
        uvw.M33 = 1;      
}​

You can do this in V7, it will work there as well
I will do the same on the V-Ray side.

Furthermore, I don't understand why you need to use vrayMtlFromRhino. If you only need to convert a material types you don't need this command, because it requires to select object(s).
If you have per-face material assignment that might pose a problem.

I suggest you use this:

Rhino.Render.Utilities.ChangeContentType()

btw vrayMtlFromRhino uses the very same utility.

[graphicmill]

Thanks Nikolay. How odd that they've changed the maths behind the transformation matrix.

I'm quite amateur at Python scripting so I'm sure my code isn't the most efficient way of doing this, but I did find a fix:

​tex = vrayMat.FindChild("bitmap-texture")
vec = rs.CreateVector(0.0, 0.0, 0.0)
tex.SetOffset(vec, Rhino.Render.RenderContent.ChangeContexts.Program)
tex.SetRotation(vec, Rhino.Render.RenderContent.ChangeContexts.Program)​

When the material is reapplied to the object, the textures appear in the viewport.

Thanks for the tip about Rhino.Render.Utilities.ChangeContentType()