Gustavo,
I didn’t expect to step on anyones feet by saying that…
As a matter of fact this border ngonulation is display ony – the renderer only sees the triangles.
Also the patch borders with these Ngon meshes remain exacly the same, meaning that selecting
a ring or loop should have identical performance > meaning the selection will stop at every Y branch.
Contiguous edge-selection may for whatever reason work better with Ngons in Modo, as these Ngon border edges are tagged as seams somehow. This sure is not the consequence of using Ngons. Seam selection could in principle work just as well with triangulated borders. I have had no no issues with Rhino’s seams and patch selection / material assignment etc. inside Blender, Zbrush and others.
Anyway, I am not against MoI style meshes, they just don’t make me exited. This should be in order, no?
As long as developers completely ignore you in any feature decision regarding this, yes. My concern is that your limited and biased opinion could be interpreted as unrefutable expert fact.
Ngons are extremely useful for people other than you. Stop the noise against them. It’s not helping anyone. More importantly is not helping me. You keep talking BS. I’ll keep calling you on it. Nothing personal, you are a great guy and appreciate your POV, but not when you are risking making my software less productive.
With an equal count of points on the border edge one should always be able to create a much better behaved all quads cap instead. In case one has an unequal count of border points one should come along with just one triangle. Quad caps generally shade better, are easy to subdivide and work very well with displacement. Here’s how this could work (a 3DSMax-Plugin in this case).
Teach in mode for the Mesher
The patch layout of Nurbs models usually has nothing at all in common with the effectibe distribution of components on manufactured parts. That layout is purely a necessity of using the Nurbs modeling paradigm – but it also determines the appearance of the render mesh. For Mesh 2 it seems that one wants to stick to that principle and leave it up to a possible later implementation of Quad Mesh (as a mesh post-processor) to remesh without looking at surface seams.
I wonder if if wasn’t possible both for the realtime mesher and post-processor to let users help the mesher interpret the topology and what is supposed to belong together. With one or a few Rhino commands one could help Rhino by tagging faces which belong together. I’m convinced that Rhino already with the realtime mesh could ignore the busy Nurbs layout and form simplified groups of mesh island which obviously also unroll together in the UV-Mapping workspace. One can think of this as the Seam defintion found the UV-Unroll command – the user defines islands of faces which belong together and get meshed together.
With Quad Caps and a way to tell Rhino what effectively belongs together ist should be relatively easy to make that lense portion all quads. As the inherent edge information is still there one could still use Edge Softening – obviously with much better results, as it would equal a proper bevel on quads.
result of face-tagging in order to create mesh groups - please imagine this to be All Quads
Better local refinement
It should always be possible refine areas with higher curvature with concentric rings of quad faces. Catmull Clark style). This would look very much cleaner in the viewport and would have better shading properties as well. Please let me know if you’d like an image for illustration.
Hm, how is that related to Ngons? A triangulated mesh is imported to Zbrush and quadrangulated there. Output is an ugly autosurfaced Nurbs model. Zbrush can not deal at all with Ngons and does not profit from MoI style meshes.
Ngons, bygones, shmygons…whatever. My only desire for the new mesher is that the ‘pipeline’ simply works! I don’t necessarily care how.
Pipeline elements defined as: Mesh (grasshopper) - subD - nurbs (or any subset thereof)
First and foremost desire - the ‘pipeline’ works in Rhino 7.
Second order desire - a mesh can flow out of Rhino in a form that works elsewhere.
Third order desire - mesh is (can be) structured for efficient manual mesh editing in Rhino.
With subD in the equation, isn’t this all linked somewhere?
Others have posted some pipeline workflows that ‘work’, as have I in past. In that past case, we wanted to leverage the power of generative design to generate and explore a multitude of forms, where we were to analyze and evaluate each form based on its physical and material properties, in pursuit of a desired performance envelope. It would be insane, as well as practically impossible, to manually evaluate more than several.
Success required a working pipeline before formal investigation. While Grasshopper represented the key genesis, V5 was a total fail for us in terms of a pipeline, so our focus was on the most suitable mesh we were able to conjure out of GH, and find a workflow elsewhere.
I can’t disclose what we were after. But here is a simplistic early test structures used to find an enabling workflow. We want Rhino to have the capability to do this all by its lonesome, and if such involves Ngons, wonderful, and if it involves voodoo dolls…whatever works, man.
Do you think the meshing of this simple form is convincing?
Even applying a “Smooth” command to the mesh does not convince much.
The SubD obtained instead? Mesh_ SubD.3dm (4.7 MB)
Checking in with the Rhino Mesher…
I’m thinking of purchasing MOI for to use a mesh exporter. Is it still the easiest way to get workable quad meshes from Nurbs?
I’ve tried rhino 7’s Mesh2 but I didn’t have much luck tweaking the values.
