I don’t see how this is different from any of the other SDS-concept modeling approaches.
Cheers, Norbert
Oh, right, didn’t realise the other approaches gave nurbs surfaces as their output. Thought they had to go through a conversion which gave nasty surfaces as the out come??
The whole process seems to be associative, which means the original SDS surface can at any time be manipulated causing all subsequent (nurbs-based) feature operations to update accordingly, which is a very neat workflow, but not unique to catia (I think more or less all the “big” mcad programs can do this now in one way or the other).
To perform those trims and fillets Catia has to convert the SDS surface to Nurbs (and the patches will be heavy on control points and star shaped patch layouts, depending on geometry. Those are your “nasty” surfaces) there is no way around it.
NX for example does more or less the exact same thing:
Cheers, Norbert
And I thought Dassault were ahead of the game on this one…thanks for pointing that out.
It does look like great tool to have, especially for soft furnishings. Would be interesting to see the iso curves of the resultant surfaces to see if they’re as bad as tsplines conversions.
There’s two ways to approach subdivision surfaces. The common easy way (each subdivision level gets you closer to the correct result, but all the while requiring more memory), or the limit-surface way. We’ve been working on the limit surface approach for Rhino, though as mentioned it probably won’t be part of Rhino 6.0
We do not care much for the standard mesh-based subdivision-with-levels way because most of our customers (both existing and prospective) need accuracy. We want to be able to have high quality subd geometry in Rhino, which means something which is always as accurate as possible and can be converted into Nurbs surfaces if need be. I imagine the implementation by Dassault is very similar to this.
4 Likes
Thanks Mitch & David, that sounds promising ! I guess uv matrix transformations and a lot of the power of Grasshopper requires grids without holes, bifurcations, and the challenge is to have a ‘logic’ that stitches separate uv patches together.
I always thought it was strange trying to force ‘form’ into xyz coordinates to get a handle on it, and wondered what other ‘space governing’ systems there might be - Boundary definitions, hierarchies, I haven’t got a clue, but I am glad you are doing the maths and not me …
But there’s no implementation of the limit surface approach either, which allows for serious production grade precision. As soon as one edits one area of the model it will transform in areas one actually wanted to remain exactly as they were. The Catia model presented in that clip has no greatly bigger geometric value than any model created in a SubD app and which got converted to Nurbs afterwards. Just sayin…
2 Likes
that is what I was trying to say.
Yeah, you’re a SubD modeller too – unlike many who post in this forum.
I tried explaining this fact to RMA in a lengthy thread with examples and all.
It was a perfect waste of time.
[quote=“hifred, post:48, topic:37603”]But there’s no implementation of the limit surface approach either, which allows for serious production grade precision. As soon as one edits one area of the model it will transform in areas one actually wanted to remain exactly as they were.
[/quote]
Sure, sub-d surfacing is only suitable for a certain kind of geometry. If you want a different kind then some other way to define the surfaces makes more sense. The same is true for Nurbs surfaces; if you drag one of the control-points it will affect a potentially large area around that control-point as well, and you don’t get to pick what that area looks like.
We don’t think of subd surfaces as a successor to Nurbs, just as another approach to surface modelling. Hopefully an approach which makes some things easier that were hard before. We are however first and foremost a Nurbs platform so we want to make absolutely sure that we can in fact represent any subd object using only nurbs patches without changing the exact shape, and without having to add a gazillion control-points.
Incidentally when I said ‘precision’ I didn’t mean that you get to exactly specify every aspect of your shape at will. I mean that the shape is analytic (like Nurbs surfaces) rather than discrete (like meshes). If we want to compute contours, draft-angles, intersections, bounding-boxes, closest-point-projections etc, we can rely on the limit-surface equations, rather than having to subdivide the shape to level 12 in order to reach the desired accuracy.
6 Likes
I’m sorry you feel that way. We really do appreciate feedback a lot even if we don’t end up doing anything with it.* In this particular case it’s simply too soon to say anything about it. A lot of the core algorithms are up and running, but we haven’t got any good UI for it yet and everybody is busy now trying to get Rhino6 out the door instead.
As soon as that happens we can start focusing on SubDs again, trying out different ways to create and edit them. One obvious problem is that your typical subd workflow differs quite significantly from the standard Rhino workflow, in that you need to have various modes (vertices, edges, faces) with a host of modifiers close at hand. Perhaps we will go down this route, perhaps we’ll try something else first. Either way it is during this process that feedback is truly important and I hope you’ll still share your ideas and frustrations then.
*A lot of user requests get put aside, either because they require too large an investment for too little benefit, or because we feel it would be counter to what Rhino is supposed to be, or because it is simply too difficult, or sometimes because there are patent issues.
4 Likes
Well, at least the disguise of Bob’s appreciation was pretty darn amazing…
[quote=“DavidRutten, post:51, topic:37603”]
so we want to make absolutely sure that we can in fact represent any subd object using only nurbs patches without changing the exact shape[/quote]
Moving the big toe when you tickle the nose is just one aspect.
Ruining the SubD topology with the introduction of the first trim is another.
I’m curious what you come up with.
Just posted this in the “raytraced-gtx-10xx-testing-requested” thread.
It was just a simple SubD exersize done with WIP’s mesh to SubD conversion and with my own SubD tools, or actually mesh editing tools:
2 Likes
Nice, did you do the prongs & the box? Rendered with ?
«Randy
See this post for more information:
It was modeled with the SubD engine and rendered with the Cycles for Windows engine in the Windows WIP. SubD tools will be developed after RH6 is released but Cycles will be integrated as a display mode in RH6.
Thanks @wim I haven’t played with either in a while. Time to get some V6 playing time in.
how does tsplines differ from subD?
not so much in the underlying theories… more from a user pov… speed/ease of use, capability, accuracy, etc
If this discussion carries on someone should change the title …
who would want to do CAD without Grasshopper ? The future is bright.
T-Splines are like subdivision surfaces […], with the difference that you can insert geometry without changing the surface.
– Quoted from : http://www.tsplines.com/products/what-are-t-splines.html
1 Like
I think it was clearer to use somewhat other terms:
Mesh-based SubD modeling as used in Maya, Modo, Cinema4D, Blender… works with quad-meshes which can be represented in a very lose and boxy form or with millions of polygons, so that they may become very smooth (but still consist of facetted geometry).
Limit surface based SubD as used by Tsplines Clayoo, Catia, Siemens NX and other implementations inside CAD programs use the end-result of arbitrary many subdivisions and therefore have a perfect smooth geometry representation.
Mesh based Subdivision surfaces modelling takes place inside modelling applications which usually don’t offer any other way to create models. Mainstream mesh based SubD toolsets have gotten very refined over decades, the whole software architecture and workflow got optimized towards getting things done with SubD-methods. The simple geometry type is resources friendly – performance is great. Also subsequent processes which deal with the finished models were highly opimized towards quad mesh geometry as input:
Texture mapping, rigging and deformation based animation (character animation) rendering, physics simulation etc. Every Game Engine works with meshes.
Such programs are mature products, but one also has to state that users typically have output goals very different from CAD users: Physically producing stuff very rarely is of interest, hence precision never played a major role. What looks good on screen is very often good enough.
On the other hand there’s Nurbs based CAD programs which have been optimized over decades to deal with curves and surfaces – a workflow that has very little in common with editing geometry in Modo or Blender. Using Subdivision in CAD apps is a relatively young idea, far from mainstream, clearly at this point not suitable to replace Nurbs. This tech now gets implanted to programs which were optimized towards entirely other workflows, likely by programmers who only worked with Nurbs so far. The latter also applies to users of CAD packages – after years of Nurbification dealing with SubD is something entirely new to a lot of them as well.
SubD implementations in CAD have the problem that one needs to design a workflow which somehow fits established conventions. None of them thus far offers the fine-grained control one has at disposal in a dedicated SubD modeling application.
14 Likes