Rhino 7 Subdivision Surface Project

Rhino SubD
1

A few of you have asked for an update on the Rhino WIP subdivsion surface project that was mentioned at RM 2014.

We are adding a core subdivision surface object to Rhino and it will be available for testing in Rhino WIP in the next month or so. If the state of the code is solid by the time Rhino 6 ships, it will be part of Rhino 6. Otherwise it will remain in Rhino WIP until it is ready for commercial use.

The core geometry component will be the ON_SubD class which will be part of opennurbs. All subdivision code will be available in the Rhino plug-in SDK. It is not known at this time if the subdivision surface evaluation code will be part of the free opennurbs file IO source code toolkit.

The ON_SubD class will have full support for Catmull-Clark quad subdivision surfaces and for Loop-Warren triangle subdivision surfaces.

The Rhino subdivision surface control polygons have no limits on vertex valences (edge and face counts) or facet edge counts.

Boundaries, creases, corners (fixed vertices) and darts (internal creases ending in a smooth point) will be supported for both subdivision types. The limit surface curves for boundaries and creases are uniform cubic splines which means that Rhino NURBS surfaces and polysurfaces can abut subdivision surfaces and be joined into Rhino polysurface.

Fast and exact meshing of the limit surface will be used for display. In the current prototype, the limit surface mesh is calculated faster than it can be displayed. A refreshing bit of news in light of the slower polysurface meshing you are used to.

Rhino subdivision objects will be automatically converted to cubic NURBS polysurfaces or meshes when a subdivision object is selected as input to a command that is expecting a polysurface or mesh. The customer experience we want is that if a command expects a surface and something looks like a surface, then the object works in the command. (This is the way extrusion objects behave in Rhino 5)

The ON_SubD object is designed to support custom subdivision algorithms that plug-ins can provide. The SDK for custom subdivision support is currently in the conceptual phase and this feature will not be ready for Rhino 6.

Currently, the basic ON_SubD geometry object is designed, Catmull-Clark subdivision, Catmull-Clark limit surface evaluation and meshing, and conversion of Catmull-Clark subdivision objects to NURBS is finished. The Rhino object and grips will be added in the coming weeks.

This work started with Giulio’s Weaver Bird project. Giulio is taking the lead on work involving the .NET SDK. Giulio and Mikko are collaborating on the overall customer experience and special attention will be focused on making sure subobject selection and the gumball work well with subdivision objects. Dale Lear is doing the core ON_SubD design and evaluation code and C++ SDK.

I will add some pictures of the limit surfaces of a few test objects to this topic. If you have a subdivision control polygon you want us to test, please post a Rhino .3dm file with a mesh object of the control polygon and we will add it to our test suite.

Thank you for your interest in this project. When it ships in a public WIP, the announcement will be in this topic.

– Dale Lear

40 Likes
2

Tremendous news, congratulations ! !

Joao

3

Wow great news!

Have you guys seen OpenSubdiv by Pixar? http://graphics.pixar.com/opensubdiv/docs/intro.html

Over the holidays I’ve attempted to integrate this with Rhino, but did not have enough intimate knowledge of either OpenSubdiv or Rhino to get it to an acceptable level. It seems, however, like a very interesting technology to base sub division surfaces on, especially in the way that edges can be tuned in terms of roundedness/creasing and the possibilities for hierarchical editing.

1 Like
4

We considered OpenSubdiv but decided that putting the geometry object in opennurbs would be a better option for our customers. Once we get something you can start using, we’ll find out if we guessed right. As with everything else we do, the development process will be public as soon as there is enough stuff for somebody to do something slightly meaningful.

3 Likes
5

So you’re taking the plunge – bonne voyage!
@opensubdiv: While large parts seem to concentrate on interactive display of super high density geometry, which indeed may not be of central relevance for first implementations of SubD inside Rhino, there’s one interesting area which can’t get supported when doing SubD purely as a Rhino / openNurbs implementation:

That’s relable transfer of creasing information between different apps. Thus far every mesh app had its proprietary vertex weighting methods, which wasn’t supported by anyone else. When bringing geometry with creases to any other SubD app, the appearance inevitably changed as the unreadable stuff gets skipped. Now as openSubD gets broadly adapted on can exchange reliably between products of different manufacturers, say between Maya (Autodesk) and Modo (The Foundry).

Just out of curiosity: What were key reasons to create the plugin in openNurbs?

6

I, just, can’t wait!
That’s Amazing!

7

We can always choose to have a file importer or exporter that uses opensubdiv (or someone else can write one.) Our plug-in architecture makes this relatively easy and self-contained.

1 Like
8

Hi Steve,
I have difficulties to imagine that such would work properly. Creases are interactive effects which remain life – weighting created in Modo can therefore get edited in Maya. If only the importer understands openSubD one had a frozen effect,no? Dragging one vert inside Rhino would invalidate the openSubD data stored in the third party created model.
Don’t get me wrong – SubD modelling also worked very well for many years without openSubD, there’s alternative workflows to weighting and I can also well imagine that using own tech could be beneficial in a Nurbs environment. On the other hand this framework delivers some cannned stuff which already proves to work very well in various other apps…

9

Some compact info on what openSubD is, for those who are interested.

1 Like
10

This doesn’t mean that the internal implementations are entirely different on each application. It just means that their file exporters and importers work correctly for creases.

11

This is an image of a bike helmet. The subd control polygon is in red and the limit surface is shaded.

7 Likes
12

I am beyond words right now! WOW!
This is on top of my wishlist for V6 and it’s future as a design tool. I am truly thrilled and happy for you guys (and for my self of course) This is such great news and I can’t wait to try to try this out!

Can you show some close ups with zebra turned on? Or even convert the file to V5 and post it so we can take a look?

PS: :smiley:

13

I can’t tell you how pleased I am to hear this news.

Yippee!! Steve

14

In the spirit of turning vapor into reality, I’m going to hold off on posting more pictures so we can focus our efforts on delivering something for you to use in the Rhino WIP as soon as possible.

Then you can use your models, your analysis techniques, and tell us what we need to improve.

Thanks for your patience.

3 Likes
15

6 Likes
16

This is great news! I can’t wait to start working with it.

Will the SDK be available at the same time as the Rhino WIP?

Alex

17

The latest C++ SDK should ship with the WIP. The .NET SDK may lag a few weeks behind. Whenever you build a plug-in with a WIP SDK, that plug-in will work only with that specific WIP.

For new stuff like this, we are sure to break the SDK every WIP, where “break” means that on a good day your plug-in won’t load and on a bad day it will simply crash mysteriously.

NEVER publish a plug-in built with a WIP SDK in a place the general public can get it our your customers will be very frustrated.

1 Like
18

I would like to crash my computer every day for this! :smile:

2 Likes
19

Amazing news!

20

Should be interesting. Do you see this as completely superseding t-Splines by the time it’s “finished”?