Let me try to explain why the texture mapping is not working on Enscape or in ExtractRenderMesh command:
VisualARQ objects are Rhino block instances with some added features, like custom representation, etc. So, for each wall, there is a block definition that contains the wall geometry (usually extrusions and/or poly-surfaces). In order to improve performance and reduce memory footprint, similar VisualARQ objects will share the same block definition. That means that we cannot store the texture mapping in the render meshes that lie inside the geometry, as it could be different between instances, so we store this information in the wall itself.
Rhino has different ways to provide meshes to render plugins:
the standard Rhino SDK that can only access the same render meshes that are shown on viewport by native Rhino objects (not custom objects like VisualARQ)
a new SDK introduced in Rhino 5: the Render Development Kit or RDK. Using this SDK, plugin like VisualARQ can provide render plugin with different meshes for rendering, with some features not possible without it:
- More detailed meshes than in viewport
- Custom texture mapping
- Per mesh material
And finally it seems that McNeel introduced improved RDK in Rhino 6 for real-time renders like Enscape. And it seems Enscape is using this new SDK. I was in contact with Enscape developers some time ago, and they told me that they were waiting for McNeel to fix a bug in
ChangeQueue, and they expect to have this bug fixed in Rhino 7.
The ExtractRenderMeshes command is an old Rhino command that is just using the first SDK, so it’s normal that the texture mapping is lost. Also, if you use this command on a VisualARQ door with different materials for the frame and the leaf, my bet is that the extracted meshes will have the same material.
I expected that Enscape worked fine on Rhino 7 with VisualARQ, but it seems it doesn’t work fine yet, so I’ll try to contact them again, and see if we can do something on our end, or we should help McNeel fix something on Rhino.