SubD-Project: reasons for editing the Limit Surface?

Rhino SubD
21

KevJin,
that’s not all that far away actually! :o)

Runnie,
thank you for your kind words, I’m glad that you found this interesting! I too am also all for new forms of synthesis between Nurbs and Mesh, I only doubt the advantage of the limit surface approach.

Willem,
I hope you don’t mind if I don’t post a lengthy answer your post. Some of what I would say could probably get assembled from my other posts in this thread. Other areas really touch the borders of forum discussions. Sitting in front of the computer together and looking at attractive parts of SubD-modelling but also the limitations probably made more sense than a few more pages of text…

Marc,
I think I did not only post opinion (which one may share or not) but also tried to describe properties and limitations of the Subdivision Surfaces principle which anyone who tackles the subject will encounter. But you are right that I have used enough room to put forward my concerns, I’ll move on now.

Gustavo,
nothing at all in this world can be done without “experts” complaining. So he’s certainly right (that someone has already compained about the subject he’s looking at).

1 Like
22

1/3 of my project test in WIP SUB-D modeling…

Conclusion:

  • A LOT faster than T-splines. (shouldn’t compare, there is no comparison in terms of speed.)
  • After adding looping tools and all other tools, let’s say what T-splines have currently, Rhinoceros will outperform any Sub-D Plug-ins available now.

Demo.

1 Like
23

…

2015-06-05_13h15_10.png562×833 170 KB

24

Command: TestMaxspeed
Time to regen viewport 100 times = 20.58 seconds.
1 SubD added to selection.

2015-06-05_4-27-37.png1457×869 248 KB

In this case, slow…

Don’t use meshoutline in this case…

1 Like
25

In T-splines, red dots/edge lines are bad sign…I have to rebuild faces in my case…
But after I imported the mesh object to V6… Magic comes…

2015-06-06_2-07-10.png1676×759 72.4 KB

V6 ignores all errors, super smooth result without any effort.
I can’t wait to see V6…I guess I will do my project in V6… It’s much much faster, unlike T-Splines, I don’t need to go different RES level to see the result…

Now, I don’t need any other software… Pure Rhinoceros can achieve ANYTHING… OMG… I’m so excited…

2015-06-06_2-10-45.png1676×858 470 KB

26

catmull–clark subdivision method seems the right direction…

http://www.sciencedirect.com/science/article/pii/S0167839614000624

27

yes I fully agree, as for now Catmull is more than enough for rhino venturing into the realm of polygonal modelling. however for future implementation maybe Mcneel can also take a look at Pixar’s OpenSubDiv. just to make life easier :stuck_out_tongue:
here is some general benefits of implementing openSubD = http://graphics.pixar.com/opensubdiv/docs/intro.html

and @DavidRutten seems to have a very good understanding about openSubD he is the master here in this kind of matter so maybe He can give a better explanation on how everything works in SubD World.

28

Nope, I’m not involved in the sub-d project and I’m not particularly up on the theory either. @dalelear and @piac are the brains here.

29

One last addendum on the accuracy topic.
Here’s a sample which should illustrate how incredibly cumbersome editing may get using Subdivision Surfaces, as soon as one wants to do precision work. The reason in short is that in Subdivision Modelling one generally can not cut away or add geometry wherever one likes. Never.

Either one was smart enough to lay out the cage appropriately in the first place, or one needs to rebuild the topology to accomodate the change. This little demo clip (from a series of generally very recommendable series of introductory videos to mesh editing and its topology demands) demonstrates the basic concept of combining several input shapes to one. Here’s the entire playlist.

2015-06-07_13h53_11.png894×637 198 KB

Say this egg shape was some plastic part we were designing and one needed to add some dome structure for mounting several parts together. The goal is to to maintain a valid SubD-Topology with unaltered curvature, boolean operations, triangles and Ngons which destroy loop based topology were not allowed.
If you want to give this a try – go ahead: Use Modo or Catia, Tsplines, interpolated SubD or mesh approximated subdivision. Redo everything from scratch if that makes sense – I’ll buy anyone a :beer: who comes up with a good looking solution and needs less than hours to do this. Here’s a Rhino 5 file with the cages. sample_modelSubD.zip

I personally would never even try doing such by hand – here’s at least a quick cheat which roughly demonstrates how a proper mesh reconstruction had to look.

topo-altered.jpg987×835 229 KB

Even if one was such an accomplished SubD modeller – what had one actually done? The input shapes were super simple, low poly and perfectly editable, ideal for freely playing around and finding shapes. The outcome is greatly more complex and determined to stay that way, quite the way a dense Nurbs surface doesn’t leave much room for further experimentation.

How much nicer would things be for the Designer if one could feed those individual volumes into Grasshopper (possibly even Nurbs geometry and meshes combined) and GH spit out the end result as a mesh which was usable for rapid prototyping, the creamtopping obviously was intersection manipulation á la MeshFusion – nudge nudge @DavidRutten As soon as one figures that one is getting somewhere there was still time to build an accurate model. Using Nurbs.

30

hi hifred, you got the point there that clearly explain the biggest weakness of SubD modelling, long time ago, when we are still using traditional SubD that doesnt really support ‘Hard Surface Modelling’ (we call it by that name, a type of geometry with lots of “trimming” and shard edges with combination of smooth curvature) .
the traditional way of doing hard surface is model your “base level” (Level 0) geometry, once you are satistfied, boolean limit surface until you please. with history chain on, you can interactively change your “cutter” object and see the boolean result updated. however, those are not efficient as we will have performance issue due to history stack.

things have changed since 2000, when modern tool for poly has been implemented in polymodeller software such as Maya,3ds, etc. on my previous post I was afraid that RHino subD modelling will not have this “modern” tool instead still relying on traditional way which then leads to one of the biggest problem as you have mentioned on your example.

I tried to do that in Maya (but u can get the same result using 3dsmax or any other poly modeller software).
I have downloaded your file around this time (my local time) about 9PM at night, and I finish everything around 11:30 and took me 30minute to compile some printscreen and adding shader + antialiasing for you to have a better look.


and I have to rebuild the whole model from scratch because I am using OpenSubDiv to minimize edge loops. and topology wise it is different from your provided mesh, so the total time to build the model from scratch until finish is about 2.5 hours, if you have wacom you can do it faster though. (my wacom is at the office, I am using my old 4GB ram Laptop for browsing kitten video on Youtube)

what I am trying to say is that with modern poly tool this hard surface modelling will be easier to tackle.

I will explain it in a while, but first, for anyone who read this post, please dont be offended if I dont use Rhino for the sake of this discussion, this is for study purposes and we are trying to get the best out of other resourches for RHino to improve., also pardon my Broken english…

so this is the result that I got, as you can see I am using OpenSubDiv with Controlled Crease (crease set node that is plugged into the Mesh), Setting limit surface to level 4 (iteration 4) so I need to use crease value no higher than [3.5].
the advantage of using Opensubdiv is that I dont even have to subdivide my geometry for rendering purpose, Rendering engine that support OpenSubDiv will tesselate that to become smaller than 1 pixel so interms of computer graphic, there is no such thing as jagged face no matter how far I zoom in to the viewport.

Egg01.PNG1538×589 230 KB

and here is the control Cage, of course it is denser than your original control cage, but this is the consequences of SubD, and there is a massive set of tool to manipulate these control cage with ease, we call that deformer (maya) or Space warp/local modifier (Max). and our translate gizmo (Gumball in rhino) is equipped with additional feature to make sure continuity is maintained.

Egg02.PNG1541×592 375 KB

I use QuadDraw. to make sure my mesh stays as close as possible to your original design. and some Deformer to conform my control cage to your original mesh, that means I can control curvature smoothness without having to move my vertex in 3dspace, I just need to worry about topology.
and I didnt use any Sculpting tool in Maya as I dont have my Wacom here at my tiny apartment :stuck_out_tongue:

here is some set of deformer that is handy to modify control cage, it can make a dense mesh behave like low-res mesh.u might recognize some I believe as you are very familiar with SubD.

Egg03.PNG480×822 102 KB

and lastly checking whether the model has Ngon or Triangular face=

Egg04.PNG1406×554 125 KB

total face for level 0 is 614, which is considerably low if you want to further edit this shape. (to whatever shape you like)

now, since you are a product designer (correct me if I am wrong) you will still need rhino to rebuild the model in NURBS if you want your model has micron-size precision (perhaps having those clip-lock detail (I dunno what to call that in english) that relies on precision to get it to work. SubDs are mainly used for form finding and design stage. however it is extremely easy to convert this model to NURBS as the model consist of QUads. and there isnt any “weird” topology.

I do apologize if my english confuses you, and again, please dont get offended if I post a printscreen of other software beside rhino. because I use rhino purely for its grashopper and robust NURBS tool that I dont find in any other software.

Rhino Rocks!!! :stuck_out_tongue:

peace and Xie Xie for reading

edit= I am only active during the weekend so I can only read this forum on my phone for the next week as I will be having business trip (more like paid vacation, yeyyyy), so if you post some image, I might not be able to open it in my jurrasic Phone. so again, pardon if somebody ask smthing and I cant reply…

peace guys

31

Hi Runnie,
thank you very much – I did not seriously expect that anyone spends so much time with this challenge! Your reconstruction looks very good indeed and you also managed to rebuild the cage to a common structure of still pretty moderate resolution. I think it should have gotten visible for everyone, what amount of effort and skill, but also what feature rich software implementations are required to get this task done, using SubD methods. Hardly any vertex could remain untouched – you even chose to rebuild the entire control cage from scratch to get access to features only available in Pixars openSubdiv.

People who are merely familiar with mesh modelling just bite that bullit – it really helps when one has no idea that the same task is trivial in Nurbs. Often, in order to save time users would simply let those parts intersect, without even trying to create a solid mesh – case closed. On the other hand I have seen students but also advanced users spend a lot of time wrestling with Rhino and other Nurbs programs – with blending between shapes and fillets and hollowing stuff out. With problems where the simpler subdivision principle so badly takes the win. That’s painful, especially in early stages of projects: Stuff which likely doesn’t survive the first review doesn’t have to be G2 continous just yet…

This is actually the whole point of this thead runnie: What McNeel plans currently is neither what you call traditional SubD, nor will it use – or be properly compatible with openSubdiv. It’s Subdivision but it doesn’t use polygons at all.

32

I’m not sure if anyone is interested in my 2 cents, but basing the display mesh on the limit surface rather than just doing a certain number of subdivisions seems like a better choice for Rhino, for a few reasons.

  • The big advantage of doing subd modeling in Rhino as opposed to modo or maya or whatever is that doing booleans using just subdivision surfaces is difficult. You get a noticeable surface change, or massive topology increase, or both.

    Nurbs are great for booleans, so you want a subdivision surface that converts well to Nurbs.

  • If you’re producing Nurbs at the end of the day, then it’s helpful to show the limit surface while modeling, because it is closer to the Nurbs. Fewer surprises is good.

  • If you want to snap some other geometry to a subd edge or corner, you want it to stay snapped even if you use different display mesh density. Using the naive subdivision, every time you subdivide the surface every point moves slightly. This is as opposed to Nurbs or subd limit-surface meshing, where the underlying surface is always the same, just sampled differently.

  • OpenSubdiv does support limit-surface meshing. In the global subdivision you can specify using the limit masks as the last step, or in the adaptive mode it actually produces Bezier patches and just samples those.

  • Subdivision surfaces have a reputation for low accuracy, but that’s mostly because of the tooling & naive implementation. From a surface point of view, they are almost exactly the same as uniform, degree-3 NURBS surfaces (star points being the exception).

On the other hand, using the simpler method of subdivision does make the UI for hierarchical edits easier. I just don’t think hierarchical edits are that valuable compared to what you get from using the limit surface.

5 Likes
33

Hi Tom,
thank you very much for your comment! This all sounds very logical in theory and of course we all like precision. From my purly empirical user perspective however there’s some dealbreaker bottlenecks in this argumentation.

The very first boolean operation performed on either mesh aproximated or limit surface based SubD geometry will mark the end of any SubD editing session. The limit surface based Boolean Operation may spit out an accurate result, but the new cage will no longer have an editable topology. All one can do from that moment on is a) convert to Nurbs or b) manually (and painstakingly) reconstruct the topology, so that it allows for editing again.

(Automated) Nurbs conversion is only meaningful if the whole Subdivision Surfaces workflow / the software implementation indeed allows for a sort of fine grained interactive control I have not even remotely seen anywhere. The subdivision geometry in this case should mark the end result, as results of automated Nurbs conversions are no suitable input for further surfacing operations.

I am afraid that one in first releases inside Rhino will get about the amount of control as in this recent limit surface based implementation by another Nurbs software maker. This in my option fails just miserably in any aspect one may look at. Implementations like such deliver the best possible argument for not further developing a SubD workspace “Yeah we have it, but quite frankly, our users don’t find it all that useful”.
On the other hand I have seen mesh aproximation based SubD programs written by a single developer which offer vastly more fine grained editing options than all SubD implementations inside CAD applications I have seen. If McNeel chose the mesh aproximated route there was a close connection given to dozens of popular software applications right away. This route delivered superb value from minute one and great arguments to continue the SubD project.

One will also run into limits for usage of existing mesh geometry, I mentioned some of them in this thread but also here. Transfer to Limit surface in addition likely morphs existing 3rd party geometry to undesired shapes. My Models look exactly the way I want them in the source app and appear all inflated and bobbly wobbly in their limit surface representation. One at least had to think about ways to load existing models and to maintain the shape they had in the source app. But before that I’d actually like to see the first example of fabricable precision limit surface modelling.

34

@hifred,

I’m confused. Why are you using Rhino at all, when you clearly need and want a classic SubD modeler?

Thanks,

  • Bob
1 Like
35

Bob,
we are obviously discussing something which can’t be covered in a meaningful way via a web forum. That’s the same as with business Emails and talking on the phone or even meeting each other. I did my very best to get my point across, used a lot of graphics and sample files. Re-reading what I wrote, apart from the spelling mistakes I always make I only see a perfectly valid argumentation chain. But I guess it can only get appreciated by someone who (at least remotely) shares my point of view.
It’s never easy to talk with people who have a very different background and in particular those who have already taken a decision and spent a a considerable amount of work on its development. All reactions I got from McNeel staff are irritated at best, I’m afraid you merely perceive me as loud mouthed ignorant.That’s certainly not the way I intend to appear in public and even less something I care spending valuable time on.

Fellow user Run (Runnie) seems to have a comparable multi-application and juggling between geometry types background. Here I saw a similar fundament of experiences grown over the years and matching conclusions, also on the accuracy topic: Where it makes great sense and where it’s simply not (yet) justified.

I honestly don’t know how else I could answer this question better in written form than I already did. We should either talk in person, else I should leave the Serengeti and see what you come up with in upcoming releases.

Holger

36

My question was very serious.

I don’t understand what part of Rhino you actually need and use, since you
seem to clearly need a different tool.

If you don’t want our SubD object to be compatible with other traditional
CAD/CAM tools (Brep, NURBS), why are you using Rhino at all?

Of course, we can make a Rhino SubD object that is compatible with classic
SubD modelers… that would be easy. The hard work is making it a
compatible Brep object.

Giving you a traditional SubD mesh at any level is trivial… and perhaps
something we will spend a few minutes on at some point. But for now, we are
focused on getting the low level core working that provides a classic NURBS
brep at the limit from a SubD control net… very fast.

We are also focus on making sure that our work is a foundation for other
plug-ins like TSplines and Clayoo.

Sorry that I don’t have time to write long warm fuzz emails.

6 Likes
37

Hi Bob,
I was serious too but we obviously look at things from very different perspectives.
Indeed – as absurd it may sound for you – I would have greatly preferred if one had limited initial technological effort for getting the feet wet with SubD and had concentrated one giving users a fun to use and feature complete implementation of tools for developing parts from a volume and which offered very robust exchange with 3rd party SubD applications.

As I create portions of my geometry in mesh applications but render inside Rhino I would also appreciate getting ways to load this geometry into Rhino with all its inherent and broadly supported features.This is not currenly possible.

If Life was a request programe I would of course ask for universal compatibility. Geometry lofted from curves merged with shapes created by sculpting a cube, blended with scanmeshes and Voxels to precision parts. However, after having hands on experience with pretty much all of the products which promise to do at least parts of all this (say building precision parts using SubD methods or automatic Nurbs conversion) I have to constate that none of this actually works sufficiently well, actually not good at all. You could easily try this out yourself, with the sample geometry I posted a couple of days ago.

With all these experiences as a background I personally felt greatly better served with top notch partial problem solving. Such as with a feature complete mesh aproximated SubD workspace inside the Rhino environment, which lets me quickly shape volumes and which spits out human editable Nurbs surfaces for any fraction of my part if I decide to move on using traditional Surfacing techniques. A very powerful partial problem solving would imo also consist in few additions to Grasshopper which gave nondestructive options to boolean various volumes together (works today) and play with the blends between individual shapes.
Here’s how this works in another application…

To answer your question: As a Rhino user/teacher for about 13 years I have used practically all major areas of the program. I do not think that I am using the wrong software for what I have to do.

38

Holger,

It may be a language barrier from my side or on yours, but the way you present your arguments comes out pretty harsh.
Anyway, these arguments don’t convince me at all. I don’t see the point of developing tools to create geometry that couldn’t be touched by most of Rhino commands. Imagine having to explain this to a student; if you use this tool to create the foundation of your object, 90% of the icons you see won’t work anymore…
What I want is powerful modelling tools with which I’ll be able to continue detailing my project like adding lips, bosses, fillets, etc. simply and efficiently.
And I don’t need, don’t want and don’t wish to work with meshes. Except as an output format.

39

I don’t see how your video example applies to this discussion about editing the limit surface.

I still don’t understand why you care what we are doing in the core. We can showing you the shape either a mesh surface calculated from level x subd, or a meshed limit surface of x density (the limit surface is a sub division level infinity). It both cases, the shape should look about the same and you will be able directly edit either the shape or the control net. The edit tools will be the same no matter if the shape on the screen is a level x subd mesh or a limit surface mesh.

In most case, Rhino will provide a control net (at any traditional subd level), brep, or mesh at the limit surface as needed without the user doing anything special.

Of course, the user will be able to sub divide the control net but that doesn’t change the shape of the limit surface. Users will also be able to edit the sub divided control net. The sub divided control net would be the new level zero control net, since we are not planning to save an edit hierarchy. As a side note, we might support an edit hierarchy at some point, but not at first.

40

Yes that is exclusively caused by English not being my first language and maybe in parts by being German and not familar enough with international politeness levels. This is actually nasty: As soon as one has reached a certain command of a foreign language people start thinking that one has developed a feeling for all subtle nuances of the language. That’s all wrong.
Everything I said was strictly intended to be on topic, I have no intensions to bash McNeel or any single person from staff, actually I thought one should know me a bit by now.

While sure tempted I will not engage in any of your other comments, but I certainly like meshes.

cheers everyone!

@bobmcneel
the video was an example for giving users powerful mesh based tools. I could see having something comparable inside Rhino as even greatly more powerful than in Modo. I have taken considerable time to describe consequences on the per user level of using the limit surface aproach, a vital part of this for me is serious Import/Export fidelity. But you sure don’t me to start all over with this again, do you? :o)

I would not be silly enough to vote stricly against using the limit surface (although this now might surprise you), what I actually would like to see is an implementation which aside from playing wonderfully together with SubD apps offers comparable snappiness and interactive work experience, including SubD-Levels. All previous non mesh based aproaches in this area remain in the exact – but terribly limited realm and I concluded that if this is the case in all plugins and all standalone programs that it has to do with the fact that one uses more complex math and several layers of geometry at any point in time. They also, without exception don’t play well together with mesh programs.