Pretty clear explanation. Thanks.
thanks holger.
i was wondering if people were wanting Modo like subD in rhino which i personally thought might be a little weird (or not something i’d personally make much use of)… your explanation of mesh-based vs limit-surface clears this up for me.
Well, a handful of users would indeed prefer mesh based SubD (these users typically have a mesh modelling background) but probably most people here would choose the limit surface based approach. I personally do belong to the first group, although the latter seems so evident.
That said – I personally am not a great advocate for at all bringing SubD style modeling to Rhino as I find its ubiquous question>answer game (Select face to extrude: click, click) not a foundation for a SubD-editing workflow I personally would like. I described what I mean in a longer conversation with myself.
I would already be happy with better display, render + possibly Nurbs conversion support for 3rd party meshes.
cheers All, Holger
Spot on!
1 Like
Here is the simplest way to look at it:
Does one’s creation need to ‘look right’, or ‘look right and be right’…
Video games, animations, etc., primarily need to ‘look right’ on a screen.
Manufactured products need to ‘be right’.
Now look at the two categories described by hifred and consider the prime markets they cater to.
The hair in the soup – (that’s what I wrote a few posts further above) is that there’s no limit surface based
SubD modeling approach yet, which actually provides production grade geometry. Until now I see no added
value over utilizing any SubD-package and converting a carefully shaped mesh cage to Nurbs.
What – just as a game of thought – if one used the less stony path first?
With a mesh-based solution, one should have something pretty cool running after a year or so and likely also greatly better support for 3rd party created SubD meshes. One could convert all this stuff (native and imported) to Nurbs and would end up with the geometry quality one may achieve with popular SubD plugins for Rhino. Autodesk just announced EOL for Tsplines in Rhino…
McNeel could use more personnel resources for providing a truly convincing workflow, e.g. with a more feature rich Gumball, editing in symmetry, possibly the introduction of local coordinate-systems – all stuff which is crucial for SubD editing in general.
Users could slowly get their feet wet with a new modeling paradigm, had fun and got usable output.
The big brains at McNeel – as time allows and silently in the background – would crack some real tough problems having to do with Topology and Trimming and such. When done with all that one could swap the whole system to Limit Surface based. Any user who previously tried the mesh-based solution was well prepared – workflow and strategies remain the same.
Here’s some random web-collected geometry, which got modeled using Mesh-based SubD.
3 Likes
oh, right, i know the difference between meshes and nurbs surfaces… it’s the exact reason i quit using sketchup and started using the early mac rhino beta (and have been using ever since)…
i could make some sweet renders with sketchup and a subdivide plugin but when it came time to build, the model was all but useless unless i needed to measure a point which was also a vertex on the mesh… i had some very convoluted workarounds in sketchup in order to get my vertices in the positions i needed to get measurements from and if something in the design needed changed, start over from the beginning.
my confusion regarding this thread was because people were saying ‘subdivide’ but not necessarily speaking of meshes… between david’s post and hifred’s, my confusion has been moreOrless cleared up since the distinction between mesh-based and limit surface based subD has been made.
Right…, Value add is SubD creation as efficient and accurate as possible: accurate meaning the design accuracy of the SubD, i.e., a specific section of the surface has a 10" radius in the Y direction and a 30" radius in X, whereas other regions of SubD may be more freeform (less need design accuracy)
Relative shape accuracy of a conversion is a given need…
Gotcha. Used your question to illustrate a point. It was @DavidRutten accuracy statement I was keying on. Hoping McNeel SubD focuses on innovative means for defining design creation accuracy, when needed, in a manner similar to what is possible with NURBS, which has been a mainstay. This is where a value add will come from.
Thanks for allowing me to do so. Not questioning your understanding. I did not make that clear. Read long thread quickly.
1 Like
@jeff_hammond Have you tried machining on a dense mesh? It apparently isn’t possible or I haven’t figured out how. Which, if true, makes it out of the question for doing any production of terrain models…
–Mitch
nope, i’ve never tried machining mesh geometry yet. (with any application for that matter).
i know fusion just gained a bunch of mesh tools (they may still need specifically enabled per user?) but i don’t know if this means anything for CAM.
so, in short, i don’t have any helpful info regarding this 
Yeah, apparently they need to convert the thing to surfaces before machining… Which means stuff like the following (1m polygon mesh) is currently out of the question.
It is a bit surprising to me as ADesk own Delcam and ArtCam, both of which can machine on meshes…
–Mitch
Mitch,
the model should look ok with a some hundredthousand faces. Is that already too much for the CNC program you are using? Does toolpath creation take forever?
In case you badly need a surface model from this one, I might be able to help.
[quote=“jeff_hammond, post:72, topic:37603”]
I know fusion just gained a bunch of mesh tools (they may still need specifically enabled per user?) but i don’t know if this means anything for CAM.[/quote]
Fusion’s CAM workspace indeed can only handle surface data. One can load quad meshes but needs their
internal Tsplines (Sculpt) workspace to convert polygons to Nurbs.
i’m not too in the know about this kind of software but i believe fusion’s CAM is, or is based off, HSMworks.
Nope. No time at all, as you can’t even select the model. 
Nope, just testing today, and my first test here pretty much ruled it out for our use.
–Mitch
So how heavy is the mesh?
Just an note of interest…
Almost all, if not all, CAM products convert NURBS to meshes internally before doing the tool path calculation.
5 Likes
1m (1,000,000) polygons. --Mitch
1 Like
I have a Trial of Deskproto installed on one of my machines. These are ten million faces, the model loaded
within seconds and as they degrade the model heavily on camera-manipulatation things feel pretty snappy actually. Didn’t try toolpath generation on this particular model but I know it works on models with some hundred thousand faces. Maybe worth a try…
