Yes, very interesting. I wonder if it’s the ‘normal’ implementation of sub’d/nurbs where by they interact with each other up until you do something like trim a hole in the middle of a sub’d - then it freezes the sub’d so it can’t be tweaked further?
If it keeps both nurbs and sub’d fully modifiable no matter what you do with them then this is indeed a massive leap forward.
However, they don’t actually show the sub’d cage being modified after a trim in the video.
from what i have grasped is that the nurbs-sub workflow is highly combined. in the last third part till the end of the video he speaks explicitly about keeping the history of both subD and Nurbs in tact, while modifying along. the keyword in that case is history, something the McNeel guys might be able to enhance either? any thoughts @dalelear?
I see that combined history (SubD + Nurbs) necessary, but also a UX nightmare. Just imagine what the UX of that looks like when you do anything more complex than one SubD body [Boolean] minus one Nurbs body.
I want the SubD (plus ToSubD, ToNurbs, new Quadmesher… ) tools as Grasshopper components so I can manage them more schematically, visually and see when/where they fail.l, replace its operando, etc.
As typical Alias fashion: beautiful demo videos that don’t scale well in real-world cases.
if all that could work with a few enhanced history settings aside, that would be far more preferable and user friendly. grasshopper can do that but who really wants to in a fast and spontaneous demanding environment, it is not practical if you have many different shapes to set them all up in grasshopper, its not a real world scenario, at least not in mine.
Of course. That would be 100X better. But not very actionable IMO.
Having worked with complex booleans for detailing on SubD using Mesh Fusion in Modo, and then doing some tests in Grasshopper I can tell you that the ‘few enhanced history settings’ it’s not something simple.
And given the track record of UI development and execution of McNeel my expectations is that they will not pull this off, at least in a decade. If ever.
In the meantime I want Grasshopper modules for everything. And I rather see their development effort in making much stronger intersection/boolean solvers for Nurbs/SubD/Mesh. And making them a lot faster (multi-threading what’s mathematically possible) and more reliable (the fail a lot these days).
I want solid/fast/robust foundation in geometry and solvers first. And a way to get at them with GH components. Not with just scriptiing, not with C-sharp. But actual UI GH components.
Then we can entertain discussions of how bad/ok/good their UI/tools for boolean history are. If they ever get to it (we’ll see). And if we even have the time to ‘design it for them’ like we usually end up doing in most tools (we’ll see).
I really really really hope to be wrong in all this. In the meantime, I want GH components please.
If one had a native implementation of a Zbrush grade Quad-Remesher one – in principle – should be able to perform both the trim and the filleting operation shown in the Alias clip and the mesh control cage would adjust to the cutout on the fly. With perfectly valid SubD topology.
One would have the shape available in 2 geometry-representations and could chose whatever modeling paradigm was the most straightforward choice for the next design step.
Programmers who could solve all previous problems sure also could keep revant bits of the untrimmed cage stored in history, to perform global shape changes (which were more challenging too, with the now more detailed post-trim+fillet SubD cage).
Next one could re-run trim + fillet on the altered source state on parts of the control cage. Or decide to move on in another direction, as the cutout didn’t look good anyway.
As someone who has tested a ‘Zbrush Grade’ mesher I can tell you such thing is great. But it has two limitations:
- not realtime
- not able to capture and maintain sharp details
At least not yet, and I’m not sure if it will be able to achieve these two important goals anytime soon.
Without them we cannot design interactively with ‘live booleans’ among various shapes.
Therefore such mesher should also ship with GH components, so we can enable/disable, change setting, add/remove/swap inputs, etc.
Regardless of the existence and goodness of this mesher, we still need a sane way to ‘manage the chunks’. So my request to at a minimum and as at least a short term solution this should be done by shipping Grasshopper components.
That’s even besides the point that by now I think it doesn’t make sense anymore to have Rhino commands that do not have a GH components when they could have one.
Grasshopper is not a proof of concept/beta/experiment anymore. It’s time to make it a first-class interface/access point of Rhino tools. Same thing for plugins.
Well, having this sort of remeshing working at interactive speed sure was a massive challenge – then again many local operations would not require rebuilding the whole topology of any given model. While doing the trim and fillet, the largest part of the control cage may stay untouched.
I assume the greatest obstacle here rather is, that the 3rd party WiP plugin you are referring to isn’t at all created with the suggested application in mind… :o)
While I agree that current SubD in CAD implementations suffer from resolution + detail limits and goldbear candy aestethics there should be a solution to this. Sticking to the example from the linked YT clip one should be able to represent the Nurbs fillets around the cutout with SubD which in its
control cage limit surface state takes exactly the shape of the Nurbs surfaces.
Already in Zbrush one may create SubD meshes which do hold the same amount of detail as traditional Rhino render-meshes do. You can easily try this out yourself: Import a super dense mesh (several million faces), created from any Nurbs surface model and then carefully reproject the zremeshed cage at increasing resolution to the source model.
This is the greatest obstacle of all tools and workflows in Rhino.
Nothing has been designed and built for iteration. Not the modeling tools, not the rendering workflows, not even naves views, nor even snapshots (which break the minute you add/chance geometry).
This is why I said: “it’ll take a decade, if ever”. This is why I want GH components now. We have design iteration work to do today. Lots of it.