Rhino 7 Subdivision Surface Project

Thanks Dmitriy. The gaps you are seeing happen a dart vertices (where an internal crease turns into smooth surfaces). This is on the list of things to fix soon and I’ve created a bug report, RH-31322, with your model attached so it will be included in testing the fix. There are some other gap bugs as well including examples in RH-30499.

Yeah, I know. We have lots of work to finish before the SubD object move beyond a proof-of-concept test.

Grips are on the short-term todo list.

  1. Yup, custom meshing will be needed, but this comes after grips and after fixing bugs in SubD to NURBS.

  2. Not “soon”. Custom meshing will happen first.

  3. None exist yet. We need a solid SubD object before we start telling people how to use it.

I imagine this response is a bit disappointing. Thank you for testing the SubD bleeding edge work in progress. It is extremely helpful.

When we deliver a SubD object to the general users, we want it to be a high quality and useful tool. We are at about 1% as far as the basic code and command support we need to deliver the first pass at SubD to our general users.

1 Like

Hi Dale, thanks for the feedback.
Then I’ll try as best as I can to live with it as it is right now.

Anything in particular you want me/us to test out for you?

Side note:
Maybe you guys could add a “What we need tested” Panel “blog” ala “Help” that the developers could add notes to. It would surely be read by me.

SubD will not be finished before we ship V6. We won’t be pushing it in a blog or any other way because it will just get the general user excited and then disappointed.

We are working on documentation that will help all of our users (General and people we’ve invited to Serengeti) know what to expect in V6. This will be ready in a month or so.

1 Like

Hi Dale,

Thanks for the clear info on this.
I truly appreciate how much RMA informs us on what is going on.

-Willem

1 Like

As Willem said: Thanks for the info!
If of interest I can write down what would make a (for me) useful tool with minimum work.
(Must have vs Nice to have)

Cheers

1 Like

Hi @dalelear,

Thanks for explanation.

In your example vertex is shared between three edges and creates a creased corner.

Please see my example enclosed. This is done in Gulio’s WB with option 2.
This means that it should be possible to fix 2-side vertices.

Will it be possible to introduce it in SubD object as well?

Thanks,
Dmitriy

CornerFixed.pdf (260.0 KB)

Here are short videos displaying the capabilities in the most basic way. If you want further information about the “what” let me know. Furthermore, if you want some reasons as to why these are critical in the subd worflow I use let me know as well.

Let’s see if I can embed a vimeo … A starter for me.

Insert edge Simple:
Insert edge Simple Vimeo link

Subdivide Face Simple:
Subdivide Face Simple Vimeo link

Subdivide Face Exact:
Subdivide Face Exact Vimeo Link

Pull Control points to match geometry:
Pull Control points to match Geo Vimeo Link

3 Likes

This video in particular and the others to some extent show the user toggling between something akin a display of the limit surface and the control polygon. In some cases the toggling appeared to be to clarify what was being shown, but it others it appeared certain operations required the display to be in a certain “mode”.

Any command that requires display to be in a certain mode is a confusing burden on users and we will attempt to have all Rhino SubD commands work with whatever is currently displayed. We have enough information to provide vertex / edge and /face picking from either a limit surface, a control polygon, or a hybrid display that shows elements of both. As we move forward, Rhino should have the same “feel” for all objects that visually have obvious “patches”, “edges” and “vertices” (breps, meshes, SubDs, NURBS surfaces being examples). No significant new work has been done here, yet.

Giulio is working on tools to easily select “obvious” groups of edges. Inserting edges “parallel” to the selection set is an obvious tool for adding more control to a region.

Both appear to be global tools that replace a single quad with 4 new quads. The second appears to be a single application of the subdivsion algorithm - the limit surface geometry is not changed. This is a reasonable thing to do if a user needs more control over a large portion of the SubD. When more control is required locally, we have other ways we will explore to avoid “control polygon bloat”. I’m not certain what modeling problem the “simple” version is designed to solve. Perhaps you can offer some details?

This appears to be matching a boundary to a non-rational uniform cubic spline and is one of the key strengths of the additions Biermann, Levin, and Zorin made to the original Catmull-Clark algorithm. As with many demos, it looks like the curve being matched was a non-rational uniform cubic spline with the same number of control points as the boundary of the SubD, which is the only case an exact match can be produced as shown in the video.

With tools we have in Rhino, we can build a uniform cubic approximation to any curve, we can provide nice tools to match subd boundaries to any curve as accurately as possible without refining the subD.

When that level of matching is not accurate enough (for example a circle can never be exactly represented as a non-rational uniform cubic spline), there will need to be an option to specify a fitting tolerance and we will do the minimal amount of local refinement to match the curve. This is akin to some of the “rebuild” commands we currently have in Rhino for curves.

Finally, tangent matching can be done as well and matching a SubD boundary with optional G1 matching will be a powerful and useful tool. The calculations to do this are similar to ones we use for NURBS surface edge + G1/G2 matching.

4 Likes

that’s a valid point of view Dale, but i think you guys should also allow us to toggle between low-poly and limit surface any anytime, even mid-operations if possibel. Some of us care to have clean pol poly cages without self-intersections and that’s something you cannot see when only modeling/editing in limit surface mode.

when you scale this bevel on a cube:

you can’t see you are making this mess:

G

How is that different from just turning on the control points… just like on all other Rhino objects. Do we really need to hide the object and mesh the control net? If we need that for SubD objects, why not for all objects?

It might be difficult to make out that specific issue with just dashed lines and points.

Hi Gustavo,

In response to my comment Any command that requires display to be in a certain mode is a confusing burden on users, you replied:

I could not agree more.

Out intent is to have the modeling tool set be as independent as possible from the display mode. For reasons like you pointed out and for ease of selection, I can imagine a user would want to see views something like the ones in the list below and to be able to change the viewing mode during any command as often as needed.

  • Limit surface (shaded or wireframe)
  • Control polygon (shaded or wireframe)
  • A visually dominant limit surface with a background control polygon.
  • A visually dominant control polygon with a background limit surface.
  • Both surface and polygon in wireframe/ghosted with some visual queue to distinguish between limit surface iso curves and control polygon edges.

A wild guess is that “visually dominant” is might be shaded and “background” might be a thin grey wireframe.

I can envision situations where a user would want to see some representation of both the limit surface and control polygon but have component selection filters restrict what can be selected to either the limit surface or control polygon and to components with certain attributes (edges, face, vertices, non-quads, extraordinary vertices, creased internal edges, …). The selection filters need to be able to be adjusted multiple times during a command as well.

All of this is technically possible and not that hard to implement in the core plumbing. From my point of view, the most difficult part is providing some self evident user interface to do all this changing in a way that is convenient for experienced users who are may be doing 1000’s of commands, view mode changes, and selection filter changes during a long modeling session.

If you have any insights here, especially with respect to changing view modes and selection filters in a way that is both efficient for experts but can be easily discovered by newer users, please share them with us.

Thank you for helping us with your ideas and feedback. It’s fortunate that we have users like you with extensive SubD modeling experience to help us design Rhino’s SubD modeling experience.

– Dale Lear

because what Steve said: difficult to see. in theory yeah you could need this also for any object type, however I think maybe only SubDs are the ones that can show you a visually correct topology flow in one mode (limit surface) and all screwed-up/selfintersecting in another mode (poly cage)

Won’t it also make it easier to see crap NURBS surface too?

I guess my point is that I don’t want to see a bunch of special case code and u/i just for SubD objects.

happy to help Dale, I like this stuff! so I can’t help myself :slight_smile:

how about a toggle on the display tab that shows/hides a transparency/transition slider that floats on a given viewport to transition between the 2 geometry modes?

So here’s what it looks like in cage-only mode:

2/3 cage + 1/3 limit:

1/3 cage + 2/3 limit:

1/3 cage + 2/3 limit, with limit color override to green:

1/3 cage with wireframe override to red + 2/3 limit, with limit color override to green:

…you get the idea.

G

you are right. it will. it would also be great if is certain types of self-intersection (math detectable) the wireframe and/or shading could highlight a problem area. with a gradient shader, like draft analysis stuff? but I can imagine there would be many exceptions/cases where it’s not self-detectable and then users would stop trusting the diagnostics. or worse, trust it too much.

Dale, your assumption is incorect. The Insert edge simple (and all other functions) are independant of the view. ie these work the same if the model is viewed in Box-mode (control polygon) or Sub’d. At times it is easier to select in one more than the other. I tend to spend 70% of my time modelling in Box mode. And once the “topology” is correctly set for the model I am designing, I then refine the model in sub’d mode.

At time, the sudivision exact will a. add increased level of details but b. modify the topolgy in an undersirable way which make subsequent changes cumbersome or makes the new topology unconsistent with the rest of the model (if a part needs to be welded to another for example).
Consequently, I most often give preference to a add simple and then adjust the model verts to obtain the desired result and maintain a streamlined topology which can be modified and enhanced.
Here is an example with the edge add Exact to illustrate the purpose. It leads to the exact same issue with subdivide face exact.

Although I personally try to avoid messy geometry with intersecting edges (when viewed in box mode), I believe these are inherant to box mode subd modeling and do not pose a problem per se.
This will happen when one maintains low number of verts and try to match a geometry. Here is an example.

The “match” is not perfect for the reasons Dale invoked but for this organic model maybe be good enough.
Now, if this needs to be send to a 3d printer, I would “thicken” it, then export the box model in .obj to Zbrush for example and decimate there. The fact that the base model had intersecting geomtery is no issue. Here is the decimated model viewed in Zbrush (no attention paid here to controlling settings for adequate 3d printing).

Yes, if you have a nicely laid out control grid you will have a high-quality surface.

It does seem uncommon for nurbs surfaces to show the control grid as a mesh. Part of this is probably due to not having to worry about bad topology, since nurbs are always a grid. Perhaps the other part is that the knot vector isn’t easy to represent in the box-mode display.

It’s very possible to have two very different nurbs curves/surfaces that have the same control mesh, but different knots. Subds are uniform, so they don’t have this problem.

I’m late to see this, but I’m excited about it. I pulled some points around, looks great so far! Weighing in on a topic dear to my heart:

I agree with Holo that adding symmetry to subD objects should not be delayed until it can be added for all Rhino objects. It’s uniquely functional here.

Rotational as well as reflective symmetry is of the utmost importance to me.

If you’re adding both of these, how about one more option for improper rotation? It only takes a -1 in the right place, and with this you would, alone among CAD software, completely close the subject of symmetry. No feature requests there ever again! Imagine.

Thanks.

2 Likes