Bug in render mesh creating naked edges?

[travisrogers (Travis)]

Hi, I’m noticing what seems like a bug in the render mesh that is creating naked edges which don’t appear if I create a mesh from the same valid polysurface with the same mesh settings. I’m currently using a custom render mesh, but discovered this issue initially with the default ‘Jagged and Faster’ render mesh settings. I’ve tried reproducing this using several other files and one I created specifically from scratch to try and replicate the issue (shown below).

On the right is the polysurface, in the middle is the extracted render mesh (with naked edges) and on the left is a mesh created from the polysurface with the same mesh settings that the render mesh is set to:

Here is the detailed info of the poly mesh:

Here is the detailed info of the extracted render mesh:

Here is the detailed info of the mesh created from the polysurface with the _Mesh command using the same mesh settings:

Here’s the geometry I created specifically to test this. The valid polysurface is on the left, the extracted render mesh is in the middle and the meshed polysurface is on the right. Only the extracted render mesh has naked edges (28).

It seems it may have something to do with _FilletEdges as I’m not able to reproduce the issue if I just create a simple box, however the mesh construction seems to be different in general between the render mesh and the general _Mesh and shows in the _What dialog. The _Mesh command creates a ‘Closed double precision polygon mesh’ while the _ExtractRenderMesh just states that it’s an ‘Open polygon mesh’. Maybe if it was closed it would say other wise, but thought I would point this out either way.

This all probably wouldn’t be an issue, but if you create UVs and export the polysurface as an OBJ you get something like this when you look at the UVs in another app (Houdini):

I am able to run _Mesh on the polysurface (which creates a valid closed mesh) and create valid UVs from there, however it would make my pipeline so much more efficient if the render mesh was behaving the same as _Mesh.

To recreate the issue, create a box, run _FilletEdge and select all of the box edges to round them all off. Then run _ExtractRenderMesh and _ShowEdges. I’m happy to upload a file as well if need be.

I’m currently running Rhino version 6.18.19266.14201 on Windows 10.

Thanks!

[travisrogers (Travis)]

Just a quick update on this. It seems if I create a simple box and run _FilletEdge on one edge the render mesh doesn’t have a problem, but if I select several connected edges to fillet in one go, the resulting render mesh will contain naked edges. I’m assuming that the _Mesh command runs at a higher floating point precision than the render mesh and is able to account for the new geometry in a way that the render mesh can’t?

[AlanMattano (Soaring Stars lab)]

@travisrogers

_Mesh on the polysurface (which creates a valid closed mesh)
it would make my pipeline so much more efficient if the render mesh was behaving the same as _Mesh

Why you are not using _Mesh? You are unwrapping the surface and you want to preserve the UV mapping?

I suspect that your Rendered view mapping is the same as Houdini or OBJ RH-54787. So in Rhino UVEditor UV mapping: Compare the Rendered view vs UVEditor. Are the same?

[travisrogers (Travis)]

Hi Alan,

Yea I realize that was a lot to explain in a single go. I’ll try to break it down a little further here.

This is primarily about getting usable UVs out of Rhino with the least amount of time, effort and headache possible.

Rhino uses the render mesh system to create the mesh for the unwrapped UVs. So if you, for example, look at the UVs created using the UV editor, their mesh will match your render mesh settings. If you change your render mesh settings, delete those UVs and run the UV editor again, your UV mesh will reflect the updated render mesh. Rhino will also update the resolution in the UV mesh to that of the exported OBJ upon export which makes creating and editing the UVs very easy (processor efficient) since you can create and manipulate the UVs using a low poly render mesh and then export the OBJ at a higher poly resolution. As far as I can tell however, the mesh system used for the render mesh is different (I’m suspecting that it’s not using floating point precision where the _Mesh command does?) than _Mesh. So for example if I were to create and organize a UV map for my model with Rhino set to use the default low poly render mesh and then I was to export that model as an OBJ at a higher resolution, Rhino will match the resolution of UVs to the resolution of my exported geometry, however since the meshing system for the UVs is using the render mesh algorithm and the OBJ export is using the regular _Mesh there is a discrepancy between the UVs and the OBJ geometry resulting in a UV map that looks like the one I loaded into Houdini above. If I extract the render mesh (_ExtractRenderMesh) from my model and I run _ShowEdges it shows that I have 24 naked edges (this is the mesh that the UV system is using). If I create a mesh from the model using _Mesh with the same settings, the mesh is closed and perfect. I’m assuming that this is where the problem lies.

I am able to create UVs and export the polysurface as an OBJ, but I have to use the same mesh settings that my render mesh is using otherwise it creates the defective mesh. It will match the resolution in the UVs to the exported mesh if I export at a higher resolution, but the vertices won’t match up on some of the UV meshes. I’m assuming that they break at the points where I’m seeing naked edges when I perform an _ExtractRenderMesh.

I can also run the UV editor on my polysurface to create UVs, then mesh it using the _Mesh command so long as I use the same mesh settings that the render mesh is set at. If I then export this mesh (basically bypassing the mesh step on OBJ export) the UVs also seem to stay intact. So I do have options, but it requires me to create my UVs at a render resolution as opposed to being able to leverage what I’m assuming is the intended behavior for them to be somewhat resolution independent and defined at export.

Again, the benefit here is speed and efficiency in workflow. If I change my render mesh setting to a higher res, one suitable for final export and rendering, then cleaning up the UV map (rotating / re-positioning mesh surfaces) is slow and tedious given Rhino’s difficulty in dealing with multiple open meshes. A UV clean up process that would take me 5 min with a low poly mesh will take me 30 with a medium to high one.

I have found that using the UV editor to create the UVs unwraps the model and straightens all of the surfaces which is a huge benefit for me as I want the surfaces straightened (mainly to be able to apply brushed textures to my jewelry renders). If I was to use UV unwrap I would have to go in using the _Flow technique to straighten everything by hand.

@AlanMattano

Why you are not using _Mesh? You are unwrapping the surface and you want to preserve the UV mapping?

Regarding why I don’t just use _Mesh, it’s just much easier to create UVs via the polysurface. The results using the UV editor on a mesh surface are not usable. In theory I’m sure I could unwrap the mesh, but again, I would have to hand straighten all of the curved surfaces to get the texture to flow properly.

Ultimately I’m trying to build a repeatable process where by I create a render model for each of the pieces I create. That render model would then be saved out as a mapped OBJ that I could use in Houdini.

I hope that came across clear, it’s a tough one to explain. Let me know if I can further clarify anything for you.

[pascal (Pascal Golay)]

Hi Travis - I see that the render mesh leaves nakeds at Smooth and Slower on a filleted box… thanks.
For now, MatchMeshEdge (defaults) may be enough to clean up extracted meshes.
https://mcneel.myjetbrains.com/youtrack/issue/RH-55161

-Pascal

[travisrogers (Travis)]

I may need to break this into a separate bug report, but I believe this may be what is causing the issue with the UVs.

I’m finding that when using _FilletEdge, I can easily create a scenario where the render mesh has multiple naked edges and a mesh created using _Mesh with the same parameters is closed and valid.

For example:

Here’s the render mesh settings in options:

And here are the _Mesh settings creating the mesh on the far right:

Also, here is the Rhino file in case anyone wants to take a look:
mesh-test.3dm (2.3 MB)

This normally wouldn’t be an issue as I never have a need to extract a render mesh when I can just create a mesh to my specifications using _Mesh, but if the UV system is reliant on the render mesh then I’m at the mercy of that algorithm.

[travisrogers (Travis)]

Hi Pascal,

Thanks for your feedback. I posed my last reply before I caught this, but it seems it has more info to help the report. It doesn’t seem to be related to just smooth and slower as I’m able to recreate the issue with just about any custom mesh setting of my own or, as in the example I just sent, using the simple controls cranked to the max.

It’s good to know about MatchMeshEdge, but I don’t know that would help with the UVs as I’m only using the extracted render mesh to check why there is a problem with the UV on export.

For now I’ve come up with a decent mesh setting that gives me a high enough resolution for rendering while not taxing my processor too much when organizing the UVs. I’m just setting the object’s custom render mesh to those settings before applying the UVs with the UV editor. When I export to OBJ with the same mesh settings everything seems to work ok.

[AlanMattano (Soaring Stars lab)]

@travisrogers

I am able to create UVs and export the polysurface as an OBJ, but I have to use the same mesh settings that my render mesh is using otherwise it creates the defective mesh. It will match the resolution in the UVs to the exported mesh if I export at a higher resolution, but the vertices won’t match up on some of the UV meshes. I’m assuming that they break at the points where I’m seeing naked edges when I perform an _ExtractRenderMesh.

That is because _Mesh does not much render settings.

Making surface UV mapping, converting to mesh using a mesh resolution you want and exporting is not only do not work the way users expects but often is almost impossible inside Rhino 4 5 6 at the state of the art.

As you figure out this old Rhino4 or 5 features are not working well individually and not working at all altogether. Rhino UVEditor is not intuitive as it looks like. I’m soaring for a workaround as you but I need bug voting (hands up for fix pushing). After decades, only recently I started isolating the issues and pointing to the problem making individual detailed bug reports for each problem, to point out how frustrating is the process. At the end, you realize that almost all the time there will be a broken mesh or broken UV mapping mesh. So looks like developers are making new features because some parts of Rhino by design won’t fix(Export setup). The good news is that the bug reports are there, I’m pushing for fixing and developers in some cases are working on them! Target 7 (hoping that they work well… I’m always purchasing a new version hoping for bug fixing and remembers me a little like Fiat filosofy{ first sell you the feature and they make money by selling replacement parts that are more expensive than average}) Anyway Rhino and devs are awesome!

Probably is related to this bug RH-54126 (“UVEditor does not show the render mesh. It shows the custom mapping mesh stored in the texture mapping”)
Fast Video bug description

Full Description Video

• Part1: https://youtu.be/eFBlg_hBbNI
• Part2: https://youtu.be/S2JmCHcwwS4

@travisrogers

I can also run the UV editor on my polysurface to create UVs, then mesh it using the _Mesh command so long as I use the same mesh settings that the render mesh is set at

Is not possible to use same mesh settings that the render mesh. I do not remember exactly why but if you try there is mismatching between the two (exporting) also if you put the same exact parameters (look video Part 2 at 1:40). So I discard that option.

@travisrogers

Regarding why I don’t just use _Mesh, it’s just much easier to create UVs via the polysurface. The results using the UV editor on a mesh surface are not usable. In theory, I’m sure I could unwrap the mesh, but again, I would have to hand straighten all of the curved surfaces to get the texture to flow properly.

Yes, In theory, is possible but in practice in the production environment is not possible to unwrap mesh because since Rhino 1 is almost impossible to select the mesh edges properly. When you select the triangle edge, you often select what is on the backside of the mesh and there is no way to occlude the backside mesh selection. I really don’t understand why they never improve this ( RH-54653 wish ). Usually, we unwrap multiple times before we get the correct projection. So selecting surface edges is the only efficient option.

Also, you need to unwrap individual polysurface but later you need to join them. And Join does not conserve individual surface UV mapping RH-53858 wish request.

If all this is fixed are done, Rhino 7 will be not only beautiful but also fantastic awesome tool for presentations and game dev.

@travisrogers

For now I’ve come up with a decent mesh setting that gives me a high enough resolution for rendering … I’m just setting the object’s custom render mesh to those settings before applying the UVs …When I export to OBJ with the same mesh settings everything seems to work ok.

Can you make a video about this workflow?