Pixar's Open Subdiv (Source code)

[Rodney]

This will mainly be of interest to programmers... and if you are into such things you likely know about this already but just in case...

 

Pixar has released Open Subdiv as Open Source.

What does that mean? I'm not a programmer so I really don't know.

 

http://graphics.pixar.com/

 

http://graphics.pixar.com/opensubdiv

 

OpenSubdiv Overview

OpenSubdiv is a set of open source libraries that implement high performance subdivision surface (subdiv) evaluation on massively parallel CPU and GPU architectures. This codepath is optimized for drawing deforming subdivs with static topology at interactive framerates. The resulting limit surface matches Pixar’s Renderman to numerical precision. The code embodies decades of research and experience by Pixar, and a more recent and still active collaboration on fast GPU drawing between Microsoft Research and Pixar.

 

OpenSubdiv is covered by an opensource license, and is free to use for commercial or non-commercial use. This is the same code that Pixar uses internally for animated film production. Our intent is to encourage high performance accurate subdiv drawing by giving away the “good stuff”.

 

The source code for OpenSubdiv is located on github and is entering open beta for SIGGRAPH 2012. Feel free to use it and let us know what you think through the github site.

 

https://github.com/PixarAnimationStudios/OpenSubdiv

 

Platforms supported: Windows, Linux, limited OSX.

[Gerry]

That is interesting! Wish I knew what it meant!

[Rodney]

That is interesting! Wish I knew what it meant!

 

 

I watched some videos that suggest that with Open Subdiv, animators are finally getting to enjoy the ease of moving animated 'meshes' in the same way that A:M Users have been doing for... well, since this is v17... over 17 years.

 

There are some things that can be done more effectively with splines and some with polygons but this should allow more flexibility with poly surfaces while also allowing the animator to more directly see the results of their changes. Before it was largely guesswork.

 

Approaching from the other angle what it means to me is that due to the iterative nature of Subdividing, polygons systems are now approaching more closely to 'real patches'. They can at least share a closer relationship.

 

The real benefit appears to be that Pixar can now use a more common language between models, animation and renderings whereas before they could only do that through translation.

 

This is the realization of some goals that Pixar, Ed Catmul, etc. have had for over 25 years and it takes time to build things that aren't invented yet.

It's interesting to note that much of that Martin Hash picked up on early on, which lead to where A:M is today. Pixar is closer to their original vision than they've ever been.

 

One could hope this signals a significant move to evolve polygons... actually, we don't have to hope... that's what they claim when they state they have returned to the old ideas of Catmul and Clark from over twenty five years ago.

 

Where this really pays off is in real time rendering.

 

That's some of the potential I see.

 

(Secretly I hope that Yves Poissant and the Hash boys being let loose into the wild had something to do with this.)

[ypoissant]

Nope. I had nothing to do with that.

 

Btw, what this really means is that Pixar had a patent for subdivision surfaces. Seeing that all 3D applications have been supporting subdivision surfaces for quite some time, it seems that they did not enforce their ownlership on this technology though. But now, it is open source. In principles, this means that anybody can use subdivision surfaces without worrying being sued by Pixar.

 

The other aspect of what it means is that now, anybody who wants to use subdivision surfaces have a very efficient open source library to start with.

[Rodney]

Interesting.

I hadn't considered patents. Pixar has a ton of them.

[jakerupert]

For A: M it does mean that the advantages it had with its patchmodeling over subd polymodeling are further melting away.

 

In the struggle of systems (there also have been Nurbs, if someone remembers) subd clearly came out as winner and has become industrystandard in games and movieproduction.

Another major proaspect of that pipeline is that sculpting mode can be integrated into it,

Which also is standard nowadays.

 

A:M s live will become harder in the future, i guess, as competion is coming closer.

[Rodney]

For A: M it does mean that the advantages it had with its patchmodeling over subd polymodeling are further melting away.

 

...and...

 

A:M s live will become harder in the future, i guess, as competion is coming closer.

 

You say that like it's a bad thing.

 

The advancement of the competition and furtherance of technology is a good thing. Advancement helps everyone. Competition keeps prices low so that customers can access technology that is prohibitively expensive.

 

Only time will tell the tale but it's obvious to me that A:M is here to stay.

How many other spline drawing options are out there waiting in the wings?

None. Zilch. Nada. Nothing.

 

In this regard, A:M has no competition.

A:M is that unique.

 

And herein lies the beauty of the thing.

As competition gets closer, A:M's life doesn't get harder... it gets easier.

[Fuchur]

just to mention it: it is not as anybody else hasnt used such techniques before... there actually are software packages which had more or less equal approaches already built in. and there are other spline tools available too... am is a very good one but jpatch spatch and shade are using mainly splines too... A:M is the best to use because it has a great workflow... that is A:Ms strongest point.

 

For A: M it does mean that the advantages it had with its patchmodeling over subd polymodeling are further melting away.

 

...and...

 

A:M s live will become harder in the future, i guess, as competion is coming closer.

 

You say that like it's a bad thing.

 

The advancement of the competition and furtherance of technology is a good thing. Advancement helps everyone. Competition keeps prices low so that customers can access technology that is prohibitively expensive.

 

Only time will tell the tale but it's obvious to me that A:M is here to stay.

How many other spline drawing options are out there waiting in the wings?

None. Zilch. Nada. Nothing.

 

In this regard, A:M has no competition.

A:M is that unique.

 

And herein lies the beauty of the thing.

As competition gets closer, A:M's life doesn't get harder... it gets easier.

[Rodney]

jpatch spatch and shade are using mainly splines too.

 

Using splines and drawing with splines is a very different thing. A lot of programs use splines.

There is a limited amount of comparison we can do here when the forum rules prevent such comparisons of software in the forum but all one has to do is download the trials and compare for themselves. In my experience just a few moments with these other programs makes it all the more easy to return to A:M and appreciate its approach.

 

I suspect you have actually used those programs you have listed so you know this. They have an edge because they at one time followed/complemented the A:M approach. Jpatch? Please. It's a wonderful effort... truly... but it is not even 5% to what we see in A:M. I am being overly generous here as anyone who has launched jpatch will know. The recent move away from core functionality established in A:M suggests that jpatch's author couldn't get Martin Hash's vision to work so he made some critical concessions that will move his trajectory further away from A:M rather than closer (IMO). The hope would be that he retains at least some compatibility after all is said and done. Who knows, maybe he'll break through and bridge the gap for us all.

 

Workflow is key but it's the tech below the hood that allows such a streamlined workflow.

Otherwise the competition would have overtaken A:M's workflow a long time ago.

[jakerupert]

Yes, competition is not bad at all.

 

Maybe it can push A:M to become more flexible in working together with the polygonworld.

 

(I think Malo`s investigations are heading in that direction.)

 

Integreation with sculpting apps and external renderers would be great for A:Ms future.

 

At the moment I have the impression also from this forum here - correct me, if I am wrong- that the userbase is rather constant

instead of growing.

 

I don`t want to sound ungratefull after having the new great A:M 17 , but as sure as A:M is steadely evolving, some competitors , even open source,

are developing even faster and with more manpower.

 

Allthough this might sound a bit neagtive, its not meant that way and I am a loyal fan to A:M nevertheless,

who just tries to follow the "global" cgi-development trends as well.

[Rodney]

At the moment I have the impression also from this forum here - correct me, if I am wrong- that the userbase is rather constant

instead of growing.

 

Big numbers are not the goal, and if I've read Martin correctly in the past they never were.

A:M is for the rest of those people that the popular crowds laugh to scorn.

And in the meantime we press on modeling... rigging... animating...

 

Firstly and foremostly, the A:M User base cannot and should not be measured by who frequents this forum.

To consider the A:M User base in that light would be to discount 80% or more.

It is true that we would like to see a lot more A:M Users frequent the forum.

Here in the A:M Forums we want to support those who want to use A:M. (period)

That is the whole reason this forum is here.

 

Sometimes the Forum populous increases. Sometimes it tapers off.

If you see it remaining stable and constant that's something the current generation of A:M Users can be proud of.

If one considers the number of people who have used A:M to learn the ropes and then move on into the industry or to excel in other programs it's a wonder there is anyone left.

 

As far as competition goes, A:M cannot compete and so it won't.

But it will keep on being the best animation program out there.

(Word on the street says its still better than PIXAR's brand new program 'Presto')

 

All that A:M would need to be 'more flexible' is an army of programmers.

A:M Users won't support that. Get this.. this is special... and the reason they won't is because they are still happy with versions of A:M that are four to five years old. Seriously think about that for a moment. Is that a testament to A:M or what. (Rhetorical question)

[Malo]

I see this as a very good thing for AM. It must not be forgotten that AM is a polygonal subdivision program .

This open source gives solutions to boost the display and polyganal subdivision in realtime. This can be very useful to AM.

[Rodney]

I see this as a very good thing for AM. It must not be forgotten that AM is a polygonal subdivision program .

This open source gives solutions to boost the display and polyganal subdivision in realtime. This can be very useful to AM.

 

Most definitely. You've succinctly captured the reason I posted this to the Open Forum.

There are many programmers who have waited a long time for this kind of code to be available to them.

And now that it is here hopefully we (collectively... I'm certainly no programmer) will be able to take full advantage of it.

[jakerupert]

-. It must not be forgotten that AM is a polygonal subdivision program .

 

 

 

-- maybe then i was wrong always living with the asumption, that A : M is spline/patch based and only turning to polygonal for the rendering?

[robcat2075]

-- maybe then i was wrong always living with the asumption, that A : M is spline/patch based and only turning to polygonal for the rendering?

 

That's probably the best way to think about it. For us it's all splines and patches.

[Rodney]

-. It must not be forgotten that AM is a polygonal subdivision program .

-- maybe then i was wrong always living with the asumption, that A : M is spline/patch based and only turning to polygonal for the rendering?

 

It's probably not worth noting... it'll just create false hope... but circa v13 Hash Inc added code (polygon modifiers or somesuch) designed to better interface with polygons. If I had to guess I'd say it was largely a byproduct of the early effort to create Simcloth... that was abandoned for a more spline-centric approach to cloth animation. The polygon modifiers were turned off in the interface because there wasn't really anything to connect it to... still isn't... no one from the polygon world has been interested in interfacing. But Steffen knows it's there. It may even be documented in the current SDK.

 

That's probably the best way to think about it. For us it's all splines and patches.

 

That's definitely the best way to get things done in A:M!

[jakerupert]

Big numbers are not the goal, and if I've read Martin correctly in the past they never were.

 

Thats quite a curious statement for a company, that's striving for economical succsess, don't you think?

 

As far as competition goes, A:M cannot compete and so it won't.

 

Could be one possible explanation for martins longtime absence.

 

All that A:M would need to be 'more flexible' is an army of programmers.

I am not a programmer, but from my observations sometimes one good programmer can achieve more than an "army"

of them.

Steffen is one very good example. The dynatopolgy branch is developed by one very talented programmer, it seems cycles

Is done also by very few. Martin himself was starting out alone, i guess.

So maybe its too easy to say: its impossible, so we better even don't try?

 

Sorry, i am on my i-pad right now, therefor that quotemess above, please read inside.

Will try to fix that on Monday...

[Rodney]

Big numbers are not the goal, and if I've read Martin correctly in the past they never were.

 

Thats quite a curious statement for a company, that's striving for economical succsess, don't you think?

 

Not at all. The value of A:M itself has always been intrinsic to the product.

The users then add even more value to the product when they follow his vision.

 

As far as competition goes, A:M cannot compete and so it won't.

 

Could be one possible explanation for martins longtime absence.

 

Nope. I believe you've got the cart before the horse here but really, Martin's private life and what he does with it is none of my business.

If I told you Martin's absence (especially from the forum) is a calculated business decision would you be able to perceive that?

Hasn't Martin made his desires well enough known that we can plot our own way?

 

All that A:M would need to be 'more flexible' is an army of programmers.

I am not a programmer, but from my observations sometimes one good programmer can achieve more than an "army"

of them. Steffen is one very good example. The dynatopolgy branch is developed by one very talented programmer, it seems cycles

Is done also by very few. Martin himself was starting out alone, i guess.

So maybe its too easy to say: its impossible, so we better even don't try?

 

I know the David and Goliath story well, and it still holds true today.

I speak in terms of the numbers game here as it seemed to me that by the term 'more flexible' you meant changing A:M into another program, to abandon what is core to the whole idea of A:M. Yes, it is too easy to say staying the course is impossible. Too easy. By why would we ever want to speak that sort of self fulfulling prophesy anyway? Negativism and doubtful murmurings will always be the easy way.

 

Have ye no faith?

'(Now) faith is the substance of things hoped for. The evidence of things not seen. Hebrews 11:1'

 

Sorry, i am on my i-pad right now, therefor that quotemess above, please read inside.

Will try to fix that on Monday...

[Malo]

It is true that the user does not handle polygons. It is the interest of AM for the artist (say no to polygons).

 

But they are there (in patches) to display on the screen in realtime. these are what we see when we interact with AM in directx or opengl.

If this technology is best for calculating the display of these polygons, then it is beneficial for AM. This is to check, maybe opensub algorithms are slower than AM or even unusable. The programmers who will study the problem, will know.

[jakerupert]

>I speak in terms of the numbers game here as it seemed to me that by the term 'more flexible' you meant changing A:M into another program, to abandon what is core to the whole idea of A:M.

 

 

 

I remember Martin saying, that this would be almost impossible. But this was a long long time ago.

Maybe "programing" times might have changed since.

 

And nowadays in most pro-pipelines multiple softwares are used, like for animating, sculpting, rendering , post and such.

 

(There surely exist some great efforts already in this direction from Fuchur, Soulcagedepartment and malo for instance)

 

I feel sorry, that it seems that my opinion is considered as kind of negative criticism, so I better stop posting in this thread now, since I don`t want to be

taken for some kind of negative forum troll.

 

My only intention as a longtime user is, to make A:M and its great comunity even better and stronger.

 

And you are right, A:M is already a fantastic tool as it is now.

 

all the best

 

Jake

[Malo]

Jake, you're not a troll! ... You express your opinion and that of many people. Each opinion is constructive even if it seems negative.

 

It was during a review such as this one on the inability to properly import a polygonal model textured as a splines model in AM, "TROER" that is born, or the PHP script to convert into Ngones patches.

I wanted to show there, it was possible to move on polygonal programmer to create programs that handles Ngones as patches.

Of course I would prefer that this be included in AM directly ... But it is a lot of work for Steffen in a short time.

 

Personally, if I had to choose priority in the AM programming, it would simplify the process of the creation of patches. And for the bridge betwenn the polygons, change the subdivision of the patches with 3 sides. But that's another debate

 

Another idea that I come to mind when reading the article by Pixar:

This can be positive for the props. And import a new function , in props, to give the possibility to import low-poly, that AM subdivide at various levels, depending on its size to screens, as it does for patches.

[robcat2075]

The subdivision you see in real time is a convenient approximation only.

 

Final renders don't use that subdivision process. Final renders divide the surface into many small faces about the size of a pixel, because it is faster to calculate the image for something flat than something microscopically curved, apparently. These small faces are thrown out and redone for every frame to suit the needs of the image, they are not like a polygon model that is defined by a consistent set of flat faces.

 

That is based on stuff Martin said and stuff I've read about CG rendering, none of which I understand completely.

 

that said...

 

-The purpose of Pixar's subdivision process is to create smooth surfaces with a fairly light mesh of control points.

 

-The purpose of Hash's splines and patches is to create smooth surfaces with a fairly light mesh of control points.

 

 

We pretty much have the same result already.

[robcat2075]

I remember Martin saying, that this would be almost impossible.

 

I recall him saying "It's possible... like going to Mars is possible"

[Rodney]

I feel sorry, that it seems that my opinion is considered as kind of negative criticism, so I better stop posting in this thread now, since I don`t want to be

taken for some kind of negative forum troll.

 

By your response I see that your head is in the right place.

I wouldn't worry too much about being taken as a negative troll, but consider that there is only one kind of troll. Don't be one of those.

Consider how your words may be taken. That is all.

 

My apologies if I came off as a troll buster.

 

*I wrote other words but thought they might be misconstrued. I don't mean to be short in my response to you. But short often = good.

[Malo]

"The subdivision you see in real time is a convenient approximation only.

That final renders do not use subdivision process... "

 

I am surprised by this ... I can not find the differences in the following images (made in version 8.5):

The shape of the splines and patches are identical in all three cases.

The only difference is the topology of the polygonal subdivision to form the patch. The problems in the realtime rendering of polygonal topology that are the same in the final rendering. We guess even little polygons in the final rendering in critical areas.

[robcat2075]

I am surprised by this ... I can not find the differences in the following images (made in version 8.5):

 

Well, it doesn't look any better in v17

 

that's certainly a bad case for three pointers.

 

But I think that it looks bad because the patch math creates a bad shape and not because subdivision is adding a bad shape. Whatever subdivision is happening is trying to recreate the patch shape as accurately as possible. I think the math of the patch needs to be rethought or that a special exception needs to be made to handle 3-ponters better. I have no idea what that would involve.

[Rodney]

Were those splines attached in the modeling window manually or were they attached programatically?

 

Something is obviously wrong there but moreover than that, something is wrong there.

In my experience, that is not the way most three point patches react.

I see the point on the tri that your are interest in but barely that.

 

Edit: It that a flipped normal on that tri-patch?

 

Perhaps you can share the steps you used to setup and render that?

[robcat2075]

Here, Rodney.... here's approximately the same situation, when a triangular patch is on the peak of a very convex shape is a worst-case situation for 3-pointers.

 

Triangle.prj

 

It doesn't look quite so severe in the modeling window but if you light it from the side in a chor it's more obvious.

[robcat2075]

Here's a tweak of the same situation where the triangle is almost invisible.

 

I fiddled with the biases so that the sides of the triangle bulge away from the center rather than being just straight lines between the CPs.

 

TriangleSmoother.prj

 

[Malo]

Here are the files: model1 model2 model3 . The first one was done by hand, the other two are the first model modified by the code.

 

Is that the final render is based on polygons? I don't know, it seems to be the case.

Is this another topology for the triangle would be better, I think.

[robcat2075]

A_BiasAdjusted.mdl

 

 

I can't make the 3-pointer perfect with bias adjustment but I can make it less bad so that I don't think it would be noticed in any typical situation where the model is textured. The original probably would not be noticed either if it had a texture on it.

 

It would be nice to have the 3-pointed shade better than they do. Someone very familiar with how it works internally would have to look at it, although I suspect this hasn't gone unnoticed.

 

I avoid using 3-pointers in conspicuous spots like in the middle of a character's cheek. Usually they can be used just to tie together loose ends in hidden corners.

 

It's like the old joke:

 

Patient: Doctor, my arm hurts when i do this.

Doctor: Don't do that!

[Malo]

although I suspect this hasn't gone unnoticed.

I think so. I guess also when creating the patch to 5 CPs the problem is posed. It was possible to integrate the quad in the 5-sided patches like this:

But this is not what has been done, there are probably good reasons.

 

 

Patient: Doctor, my arm hurts when i do this.

Doctor: Don't do that!

[robcat2075]

 

To me, that looks like you will have the same triangle problem at the top.

[Rodney]

This is somewhat related...

 

I've been staring at an issue but don't fully comprehend how to approach understanding what to do with the information.

 

Specifically that of how most programs and plugins (and approaches for that matter) tend to advance from a perspective that works against our goals of having smoother surfaces.

 

In the image below this can be seen in (what I perceive as current approach) versus an optimal approach.

What we tend to see is:

 

Block - Prevalent in Bump and Displacement

Linear (Triangle) - Prevalent in the Grid Plugin (except optimal Control Point placement by assignment of lower Step Width and Height)

 

We don't see Linear and Bilinear very often and with good reason but they still would be preferrable in some cases over Block and Linear. (Triangle).

 

What we only tend to see in optimal spline generation is biquadratic and that seems to be where the crossroads of optimization is in applying scale, control point placement and magnitude to mesh creation.

 

Note that all of the approaches are (under the hood) comprised of the same spline continuity and are quadratic in nature they just seem to get 'pinched' at critical points along those splines due to the given interpolation.

 

 

This image taken from 'Efficient Animation Techniques Balancing Both User Control and Physica Realism by Zicheng Liu. It's well worth reviewing as it has a chapter on Optimizing Keyframes (Chapter 4) as well as some exercises for animators.

[robcat2075]

I'll note that we can minimize the "block" stair-stepping of displacement maps by using hi-range maps (OpenEXR in A:M's case) images for our gray-scale maps.

 

I'm not sure if I've seen stair-stepping in bump map cases.

[robcat2075]

That "linear (square patch)" is pretty odd.

 

An example of how you can graph something in math that you'd never find in the real world. Or is there?

[Rodney]

An example of how you can graph something in math that you'd never find in the real world. Or is there?

 

I read this similarly to the old saying, "There is no such thing as a straight line in nature."

And if that is true then linear square patches is (purely) theoretical.

 

In my messing around here I note that the thing about linear/square patches seems to be that they are aligned (or in line) with other points in order to formulate 90 degree angles (hehe... no doubt hence the name 'linear'). This does leave the occasional point out of alignment which I think that a fix (not in the graphic) might be to scale or move the extruded points out until aligned with the original. An alternative method might be to scale the original and extruded point together (I assume an average here) but that would remove the original away from it's place with respect to it's own origin. Therefore I think scaling the extrusion back in line with the original would yield the best linear spline square interpolation.

 

(Yes, I have exactly no idea what I just said)

 

Added: While messing I came up with another construct and I'm not sure how or even if it would fit in.

It'll require more experimentation.

[Malo]

To complete the problem of topology triangles, here is a simple experiment:

 

[Fuchur]

To complete the problem of topology triangles, here is a simple experiment:

 

 

Really good example!

Thanks for showing... maybe it would be worth to have a look in that direction.

 

See you

*Fuchur*

[robcat2075]

To complete the problem of topology triangles, here is a simple experiment:

 

 

However... that turned the five-pointer into a six-pointer. New problem!

 

 

Martin would likely be the ultimate authority on how A:M deals with these things since he originate the code for it. Too bad he doesn't visit much anymore!

[Fuchur]

To complete the problem of topology triangles, here is a simple experiment:

 

 

However... that turned the five-pointer into a six-pointer. New problem!

 

 

Martin would likely be the ultimate authority on how A:M deals with these things since he originate the code for it. Too bad he doesn't visit much anymore!

 

he is only adding the cp to force another subdivision behaviour... it would not really be there. it is only to illustrate the difference.

 

see u *fuchur*

[jakerupert]

Maybe it's possible to introduce something similar to n-gons into A:M to be able to have valid patches with more then 5 cps?

[Malo]

Fuchur you understood what I wanted to show.

Robcat, sorry, The Npatches are another problem that was far from my mind.

I just add a CP to the triangle to keep the shape of thetriangle, and change the topology of the top of the triangle.

Here is another example that avoids misunderstanding:

and this is what I suppose might have happened if the topology of the triangular patches will be changed.

Jake, I think it is possible to use the same principle to create Npatches ... but I don't know if these patches will be stable in animation and rendering.

[mouseman]

Malo ... excellent analysis on the 3-point patches. I agree they could look better. One question ... how did you get the line outline of the polygon breakdown in post 25? Did you export to OBJ and re-import it as a prop?

[Malo]

Hi Mouseman,

 

Version 8.5 AM, had different rendering options, which allows you to see the triangulation of the patches :

[Rodney]

It's interesting to note that the concern with regard to triangular shapes has long been an area of interest and resisted easy solutions. Pixar's current way of dealing with the problem echos Martin Hash's with regard to how to deal with surface anomolies. In short, they use 'infinite resolution' to make the problem (appear to) go away. Through subdivision the problem still exists but at such a reduced level that the anomolies become imperceptible.

 

One way Pixar is further reducing the problem is to craftily transform the tris into quads via factors of 3 and 4 with the lowest common denominator being a quad-compatible surface (i.e. the subdivision of a tri resulting in groups of 12 tris). This quad shaped tri can then be better matched to it's quad shaped neighbors.

 

In texturing terms this can also be seen in Pixar's approach to Ptex: http://ptex.us/tritex.html

 

There is also that pesky matter of using Normals to determine the smoothness of surfaces . A problem arises when incompatible surfaces cause their normals to face in sub-optimal directions (the don't know where to look so they look where we tell them... yielding surfaces that too precisely display our control point and spline placement). As the intersection between tris and quads cannot perfectly match, something must be sacrificed, unless the problem is reduced/subdivided/hidden in some way. This equates to the subject of seams in textures as the overlapping of textures is yet another approach to masking/hiding the problem incompatible surfaces. But even here we see an effort to subdivide the seams in such a way as to transform noncontinuous tris into continuous quads for the purpose of matching otherwise incompatible surface shapes. (see attached image)

 

Ref: Below image is from Ptex-slides (Page 31)

[Malo]

I got the V.17.

So I pushed my analysis of polygons that are behind the patches using the new export plugins.

By chance, I using Jpatch by curiosity, and found that Jpatch exported and converted patches triangular polygons differently to AM ... so I could compare and see some of the problems of the two methods.

Here the analysis:

AM exports in subdivision X1, X4, x16, x32, x64. with UVs

Jpatch exports in subdivision X4, x16, x64 and x128. Without UVs

Therefore not possible to compare the subdivision X1, x32 and X128 and Uvs.

For AM :

1. All export models of AM have the same problems related to triangular patches:

-An abnormal number of normals to the number of vertices.

- Degenerated faces (see the alert window meshlab on the pictures).

-Polygons with vertices whose normals seems reversed?

- Asymmetric topology of the polygons of the model.

2. Export 32 and 64 has torn joints, not exploitable.

 

For Jpatch. I have found two problems:

1. polygons triangular patches are not welded, making rendering the polygons visible. Some polygonal program can weld to import (eg, Poser, Metasequoia ...), and corrects this problem.

2.Triangular patches form corners where it should be smooth.

Here's a little experiment to illustrate this problem:

I create a sphere with three perfect circles and 8 triangular patches.

Impossible to create a perfect sphere in AM with this method. as we see from this little image. the patches is unstable, just making a rotation of some millimeter, the patch changes shape.

Export this sphere by the export of AM is identical to AM.

Export this sphere by Jpatch is more spherical, but has a big problem, it gives the feeling of a square inside as the center point of the polygon patches.

Red sphere is just to compare :

 

not find the good solution

[Rodney]

It is interesting to note that recently a Nobel Prize went to three men involved in research related to real world topology.

On the surface (pun intended) this might seem somewhat unrelated to our concerns with 3D but of interest is how 'holes' form in complex shapes and what that implies relative to our need to use 3 and 5 point patches and exotic shapes in our efforts to model in the virtual world.

 

Their research is more specifically related to quantum mechanic properties (entanglements) and electric conductivity in order to create new materials.

My interest is where the theory applies (or does not apply) to extraordinary vertices (i.e. to my way of thinking anything that is not a four point patch).

As this seems to be an area where computer technology and the real world converge I can easily imagine that some of the folks at PIXAR deeply interested in such matters of topology are paying attention.