I have been testing the new reworked OffsetMesh command in WIP. There are 2 issues that I hope can be still addressed:
Old one: regardless of the command settings, the output of offsetting “boxy” shapes is still really bad. We have been reporting this and asking for a while now: Mesh handling improvements needed
I was hoping with the major mesh handling rework in V7 this will be improved as well, but unfortunately the crappy output still remains:
Can we have an option for normals, whatever would be the proper name of the algorithm, to maintain the shape and face normals/corner normals, so we don’t have to deal with these weird results of rectangular shapes and their mangled corners? OffsetSrf handles that beautifully, why not meshes?
A new issue is the real-time preview with cursor. Very cool in some cases, but when dealing with heavy meshes or a large number of objects to be processed (1000s of mullions) this real-time preview chokes Rhino - it is impossible to evaluate the preview while rotating the model - the old version with the preview only changing on setting update did not get in the way like this. How about adding a STICKY setting to the command line to enable/diasble real-time cursor-following preview. Otherwise this will be really hard to work with.
Any interest in this? Not sure who is in charge of rewriting this Mesh-related command ( @piac ? ).
As is, the real-time preview is very hard to work with here, and results of mesh offsets are not very 2020…
@tim Also, looks like in the process of working on mesh tools this issue has been fixed (Deleting mesh faces - I noticed the command changed from DeleteMeshFaces to DeleteFaces… but this issue can be marked as resolved in current WIP : https://mcneel.myjetbrains.com/youtrack/issue/RH-39895
But this one is still there - any chance while revamping mesh tools ExtractMeshFaces can be tweaked for the resulting selection to inlcude meshes with all of their faces selected for extraction? We are running into it every week and its a big PITA to lose the selection of the meshes that were fully selected in the process… https://mcneel.myjetbrains.com/youtrack/issue/RH-39915
I can add an option in OffsetMesh to disable realtime preview.
The reason OffsetMesh uses the topological vertex average as an offset direction is because it’s hard to do otherwise. At least for a simpleton like myself. If you offset individual vertexes in the direction of their individual vertex normals (or corresponding face normal) you end up with offsets that have faces in the right place but they don’t extend to meet each other. See my example model. offsetcube.3dm (28.7 KB) Polysurface offset must do something like that.
Thanks for the ExtractMeshFaces fix - this will be great once we can switch the production to Rhino 7 but for now glad to see it’s there, along with other improvements.
For the OffsetMesh preview, an option to disable cursor realtime preview as a sticky command-line option would work well if achievable - if disabled, the preview would only update on command line settings change…
The intuitive desired offset result, at least for non-organic shapes is that we are offsetting the faces, and vertices are derived from that, not the other way around - I know math for Solids must be completely different than for meshes, but the solid result is working… I can’t tell you what’s the math behind it - I would probably start with finding the intersection of the planes of all faces adjacent to given vertex after offset, and try to derive the vertex location from there? Or I would walk over to whoever wrote the Solids code and see how they did it For architectural modeling this mode of offset is the desired outcome 99% of the time and we have been struggling with this for a long time. There must be a way to do it as it is pretty common in mesh-modeling software - and now that Rhino focused more on Meshes my hope was the Offset algorytm to be refined, or that mode added as an option (I don’t know - maybe the current one is good for something else, but I can’t think of anything).
Here is another sample - I am sure intuitively we both can tell which result is better…
hi @tim, I just tried the new OffsetMesh command. Thank you for adding the Preview On/Off toggle.
It is not perfect yet. Not having any preview is as problematic as having the constant cursor-based interactive preview that keeps updating even when we go to click any of the option… Could this Preview On/Off be only for the interactive preview? Meaning, if Off, we would still see the preview but not following the mouse, just update when any of the parameters change? Try making 1000 mesh boxes and you will see what I mean. Even when I type a number for distance so the mouse movement don’t change it, the side of offset keeps flipping, and gets very slow with many meshes or heavy meshes.
I also just realized Flip is weird in this new implementation. First of all, FlipAll button was very good and it would be handy to have FlipAll option still available (for initially preselected meshes). Now the Flip asks users to pick meshes, but is not even limited to the initial preselection we are working with, which is weird and not intuitive. Sometimes the selection process is long and having to redo it just to flip what we already selected is not good.
Is this happening because the offset command is offseting each vertex on the averaged normal direction? instead of offsetting each face, and resolving the vertices location based on the intersection of those offset faces?
@tim@Jarek, look what happens when I run the offset as a ToNurbs version of that input mesh…
Hi Gustavo, you are correct, that’s exactly what the problem with offsetmesh result is.
Offsetting the same shape that is nurbs or same mesh converted to nurbs works correctly.
I was hoping somehow the nurbs algorythm could be used for mesh, otherwise for non-organic shapes (and that’s mostly what we work with) the MeshOffset result is not useful…
That YouTrack issue only addressed the static preview updates when Preview is set to No and added a FlipAll option. The way OffsetMesh makes the offset has not changed. That’s a much bigger thing to fix.
thank you for the fix with Preview / FlipAll - works quite well now.
For the offset, I understand this is more complicated issue and may require different approach, but that’s why we are bringing this up. I wonder in what scenario the current result is actually useful? Seems like the offset distance now determines the vertex normal vector size, and not the original-offset mesh face distance, which for boxy shapes is much more desirable. Maybe the current one makes sense in some scenarios I can’t think of, but perhaps it would be worth investigating and adding an option of how the distance is measured so if using face-to-face, it would result in more regular and predictable shapes. Any chance you can check with whoever figured out the OffsetSrf working so well and maybe that approach could work for meshes as well?
This file shows a sample of what Offset by 10 does with surfaces and meshes. My expectation is 10 should be face-to-face, which Surfaces actually do… offset_10_test.3dm (161.0 KB)
For architectural modeling this mode of offset is the desired outcome 99% of the time and we have been struggling with this for a long time. There must be a way to do it as it is pretty common in mesh-modeling software - and now that Rhino focused more on Meshes my hope was the Offset algorytm to be refined, or that mode added as an option (I don’t know - maybe the current one is good for something else, but I can’t think of anything).
