Render in Grasshopper removes texture mapping

[obucklin]

Hello,

I have geometry in Rhino with custom mapped textures to look like wood beams. I want to render an animation using V-Ray components in Grasshopper. If I do no manipulation in Grasshopper, the custom texture map gets rendered, but as soon as I move the geometry, the custom mapping reverts to a generic map. I know this was working earlier in the year, and I suspect an update has made it stop working. Unfortunately I cannot upload a .3dm or .gh file to demonstrate the problem. Any help would be appreciated.

Vray 5.10.06
Rhino 7 SR9
(7.9.21222.15001, 2021-08-10)

[slavcho.brusev]

Hello,

I am not sure I understand enough about this matter to explain why this is happening. However, there is a workaround.
Map the object you wish to animate and export it as a V-Ray Proxy. Then import the Proxy in Grasshopper and animate it using the Base Plane node.

[nikolay.bakalov]

Hi,

Since a lot of people get confused about this matter, I’ll take some time to explain what really happens behind the scenes in details

Although the above is a valid solution, there is a simple alternative to that.
But let me first explain why this happens

First
In Rhino the mapping is actually a separate object. It is rather a generator, that is associated with specific Rhino geometric objects. Rhino keeps a table where for every object zero or more custom mappings are associated. For newly created objects - there is no association.

Second
Most Rhino objects does not have UV mapping, because they don’t have fixed vertices and faces - like breps or nurbs, or renderable curves. By “vertices” I mean triangulated mesh points.
During rendering export, all such objects are converted to meshes (triangles) that have fixed vertices, and can also hold UV coordinates. After the conversion the associated mapping object generates actual UV values for the mesh vertices.

And Third
In Rhino there is no local coordinate system. That means once you move (for example) an object, that object is copied at the new location, and then the old one is deleted. In most of the cases people work with trimmed surfaces or breps, not actual meshes,
so that strategy is super fast - much faster than copying & transforming huge number of vertices/normals/faces, etc.. breps are really tiny structures.

Combining all that into one is what happens in GH. Consider the following graph:

When you reference a Rhino object, your component holds not an actual geometry, but a reference to a Rhino geometry. Including possible associated mappings.
When you move the object, the result is just “Brep” - not a referenced any more. It is a modified copy of the original, but since it has a different ID, there is no associated mapping to that instance - hence nowhere to take the UVs from.
Mind that we’re talking Breps here, and they intrinsically do not hold any faces/vertices nor UVs. Once you render them, V-Ray will ask Rhino to mesh the object, considering any associated mappings, and the result will have the expected UVs.
For the second object - no associated mapping => no UVs. Well almost - Rhino will apply default “surface” mapping and generate “some” UVs based on some fixed logic.

Now lets consider that “Brep” thing. As it is clear already only meshes retain UVs, hence if you mesh your object in Rhino, reference it in GH (with the UVs already generated), and then move it, that will work. You will get the UVs in your copied object, just because you copy a mesh, not a brep.

Note that it still says “Referenced Mesh” and “Mesh”. When that second mesh is exported for rendering, there is no associated mapping with it, but that’s fine - there are generated UVs copied from the source object, which V-Ray will take. And that renders fine (custom spherical mapping applied):

Mind that transforming mesh in GH, also transforms its already present UVs - so rotation and scaling are also OK

Final thoughts.
If you need mapping over transformed breps in GH. It is much better to have the mapping specified in GH instead. It is not available by default, but there are plugins like Human | Food4Rhino, that creates that mapping association in Grasshopper.
V-Ray will take advantage of that as well

[obucklin]

hello Slavcho and Nikolay,

Thank you very much for the responses and explaination. My textures are mapped using a custom C# plugin that I developed, and I would need to use the same mapping on objects rendered in Rhino and through Grasshopper. I tried to extract mapping throught the TryGetMapping Methods, but unfortunately they don’t return the same parameters as the input. This means that mapping in grasshopper is not really an option. The solution where the geometry is exported as a V-Ray Proxy would not be an option because I am animating dozens of objects at a time. Is it possible to extract the meshes from the Rhino objects that contain the mapping info and is usable in Grasshopper?

For the time being I will have to convert geometry to meshes in Rhino and reference them in Grasshopper. That makes the files get very large very quickly, but I guess that’s an OK compromise.

Can you tell me if this is an issue that will be resolved in future updates, or is it really just how the base types work?

Thanks!

[obucklin]

Hello Nikolay,

Thanks again for the explaination. Based on your writeup I wrote a short script that I execute in a C# component in Grasshopper. The script extracts the render mesh from the RhinoObject which is referenced using its guid. I havent tested it much, but is has worked so far.

 private void RunScript(List<Guid> g, ref object meshes)
{

List<Mesh> meshesOut = new List<Mesh>();
foreach (Guid guid in g)
{
Rhino.DocObjects.RhinoObject obj = Rhino.RhinoDoc.ActiveDoc.Objects.Find(guid);
Mesh joinedMesh = new Mesh();
joinedMesh.Append(obj.GetMeshes(MeshType.Render));
meshesOut.Add(joinedMesh);
}
meshes = meshesOut;

}

Thanks again
cheers!

[nikolay.bakalov]

Hi obucklin, I’m glad you made it.
This is interesting approach, and I think we shall take advantage of this nice discussion
Currently we force Rhino to generate a new mesh for the GH object (unless it is a mesh object already), but in fact a mesh may already exist on the source object, and we shall consider it.

Thank you