ExtractRenderMesh breaks mapping

Hi there


I often end up using ExtractRenderMesh to get Enscape to play nicely with VisualARQ objects, but it seems that running ExtractRenderMesh breaks the mapping that I had set on VisualARQ objects. Is this a bug that can be fixed? The mesh results is very close to how enscape actually reads the mapping as well. And also when meshes are generated when saving VisualARQ shows the right one for the the duration. See:
0b6DkKnhOU

Hi Roi,

I could not reproduce this issue. Do you have that file to test this with? what Rhino/VA versions do you have?

Sure, Take this wall, run ExtractRenderMesh and see how the mapping is different. I’m running: (7.2.21021.7001, 01/21/2021) and VisualARQ 2.9.1.14486 - (2020/11/04)

Mapping Test.3dm (328.7 KB)

Thanks Roi. I get it now, and get the same issue. I thought you meant the VA object changes the texture mapping scale after the ExtractRenderMesh command, but it happens on the resulting mesh. I’ll report that to the development team.

Oh right, sorry, should’ve clarified. This is our current workaround to get correct mapping within Enscape, here’s to hoping the Enscape developers will start using the proper RDK soon :crossed_fingers:

2 Likes

yes this is very unfortunate I also hope for a solution here because IMHO even extractrendermesh is a pretty bad workaround. It should just work with regular VARQ objects!
Is there any hope this issue will be solved in the foreseeable future ?

Is this actually Enscapes or VARQs fault?

best
Andreas

1 Like

Hi @walther,

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:

  1. 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)

  2. 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
  3. 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.

Regards,

Enric

3 Likes

Hi @walther and @rheinason,

I’ve now tried to debug the issue with Enscape and our objects, and I came to the conclusion that this is an Enscape issue. Enscape is using the old SDK (for both Rhino 6 and Rhino 7), which doesn’t allow them to get our custom meshes or per-mesh material.

I’m close to fix the issues between VisualARQ and Rhino Raytrace displaymode, which uses the new RDK. But unfortunatelly, Enscape is nou using this SDK.

I’ll try to contact an Enscape developer to see if I can help them in order to fix this issue, or if we can make anything so VisualARQ and Enscape can work fine together. Last time they told me there was a bug in the RDK ChangeQueue, but I cannot see any problem. If you can, please, contact them also an ask them to fix this issue.

Thanks,

Enric

4 Likes

Thank you Enric for the detailed explanations and your effort to resolve the issue with the enscape guys so pro active, it is really appreciated since IMHO VARQ and Enscape are a potentially really good match!

2 Likes

Thanks, Enric

A fix to this issue would be very welcome indeed.

1 Like

Seeing as the Enscape developers don’t seem to want to prioritize this issue, would it be a major pain to create a custom VaExtractRenderMeshes/RenderBreps command? This might also prove practical in some instances, especially if it would be RenderBreps, or extract breps. I often need to explode VisualARQ geometry without loosing the original object, if using it as reference or for a Boolean operation or similar.

3 Likes