some questions

[Malo]

Hello,

 

I ask myself some questions about the history and evolution of the polygonal subdivision in Hash patches after reading this link from pixar, which reminds me a lot with AM patches : http://www.opensubdiv.com/?page_id=84

 

- When was the last consolidation made ​​on patches?

- When was made the triangle patches?

- When was made the quad patches?

- When was made the five sides patches?

- Is that the subdivision of polygons in the interior of patches has evolved since the beginning?

- Martin Hash did he actually abandoned his baby, or does he think back on it later?

- Stephen Gross, does it have the right to change the code of the constitution of the patches?

 

(I do not know where to ask these questions, feel free to move the topic.)

[Rodney]

Hi Malo,

 

I only know the answer to two of those.

Hopefully others know the historical record and can share their knowledge.

 

- Martin Hash did he actually abandoned his baby, or does he think back on it later?

 

Martin has not abandoned his baby. To everything there is a season... turn... turn... turn... and return.

 

Those who find themselves too far ahead may have to wait for others to catch up and Martin doesn't have the personal resources to catch everyone up.

Of course, Martin is not the only one who is waiting for others to catch up. The document you linked to from PIXAR is illustrative of that.

Also: Reference the historical connection between Catmull and Hash.

 

- Stephen Gross, does it have the right to change the code of the constitution of the patches?

 

This is not something that is likely to be discussed here in a public forum.

Launch an personal email to Steffen that outlines your interest and he will likely respond.

To prevent misunderstanding, confirm with him if what he shares with you privately can be discussed publicly.

 

- When was the last consolidation made ​​on patches?

 

I do not know what you mean here by the word 'consolidation'.

[robcat2075]

- When was the last consolidation made ​​on patches?

I'm not sure what that means either.

 

 

- When was made the triangle patches?

- When was made the quad patches?

 

Those have been around since v1 in 1992 or 1993. They may have been even earlier in Animation:Journeyman, but I know nothing of that program.

 

- When was made the five sides patches?

I recall those being introduced sometime after v5, perhaps around 1997

 

- Is that the subdivision of polygons in the interior of patches has evolved since the beginning?

Martin said once here that in the beginning there were no polygons at all, ever, it was ALL splines through the whole pipeline. Later, to improve render time, temporary subdivision of the patches was added. I don't understand it all.

 

Based on Martins' comments, A:M's renderer seems to be a REYES renderer

 

- Stephen Gross, does it have the right to change the code of the constitution of the patches?

 

Possibly, but it would have to be for a fabulous reason.

[Malo]

Hi Rodney and Robert,

 

Thank you for the answers!

 

"Martin has not abandoned his baby." I am pleased

 

"This is not something that is likely to be discussed here in a public forum."

I understand that ... I will not bother Stephen Gross, my questions are related to my curiosity

I do not know what you mean here by the word 'consolidation'.

I meant the latest evolution technicque for the subdivisions of patches.

 

In version V8.5 (2001), it is possible to see the subdivision patches.

I just wanted to know if it has evolved since 2001.

 

This 2001 subdivision intrigues me, especially the patch to 3 sides:

 

if I use an orange line for the first subdivision, and a purple for the second, 3-sided patch is different in the subdivision (the orange lines and violets grow in a single vertex ).

The three-sided patches, can produce a triangle among the quads. What appears to be a problem reading some articles on the web.

Hence a question that I come to mind: a subdivision of patches for 3 sides, would not it better like that?:

I want to clarify my total ignorance on the subject, if the question sounds stupid

 

"Martin said once here that in the beginning there were no polygons at all"...

Very interresting! So far, I thought that there were only triangles and voxels in 3D.

 

"Possibly, but it would have to be for a fabulous reason."

Luckily

[Rodney]

"Martin said once here that in the beginning there were no polygons at all"...

Very interresting! So far, I thought that there were only triangles and voxels in 3D.

 

I believe Robert is referring to A:M only.

Previous to A:M (Animation:Apprentice etc.) others were certainly used.

 

Hash Inc made an attempt to push the tech to graphics cards but (as I understand it) the math is easier to understand when using polygons.

I see ut as the equivalent of working with straight math versus dealing with intensive algorithms. The algorithms perform better but someone first must create and then optimize the algorithms. This as opposed to crunching the obvious numbers via "perform math, perform math, perform math and recycle."

 

Nice images Malo. They nicely illustrate your idea.

 

(Disclaimer: The following is VERY naive)

I can't say much regarding your thoughts on three sided patch division except to say that it appears that your proposed scheme would create shapes that are not rectangles (which are then subdivided into two polygons). They would appear to be modified rectangles/trapezoids. Therefore this new approach would have to be handled/interpreted in a different way than all other divisions, perhaps by sliding either the top/bottom or right/left sides within the given subdivision. I could see this going one way (to a renderer or to export) better than the other (import or continuity of 're-unsubdivided' or reconstituted splines). I'm trying to imagine how that would work for an importer it would have to test for both rectangles and trapezoids. I assume trapezoids first because they would be rarer and require more attention so they would have to be dealt with specially after ID'ing.

 

So I'd guess we'd have to start with the question: Are all patches already (currently) simularly subdivided?

If they are then implementing this new way to subdivide would constitute an exception which would work against optimizing.

 

Of course, being an exception does not make it not worth pursuing.

Exceptions to a rule often turn out to be that same rule (at least partially) optimized.

[robcat2075]

You are right that triangle patches seem to be like a 4-sided patch with one side squished together.

 

For smoothness, I think they seem to be more of a problem than 5-pointers.

 

I don't know how much of a problem changing the internals of 3-pointers would cause for old models?

 

I'd draw your subdivision more like this...

 

 

 

 

"Martin said once here that in the beginning there were no polygons at all"[/i]...

Very interresting! So far, I thought that there were only triangles and voxels in 3D.

 

In the beginning of... A:M! Of course CG had polygons long before A:M.

 

I understand Martin's first program, Animation:Apprentice, used voxels but i don't know much about it.

[Rodney]

Nice pic Robert!

 

I think that is closer to how the patches are (or can be) optimally subdivided.

[robcat2075]

Nice pic Robert!

 

I think that is closer to how the patches are (or can be) optimally subdivided.

 

It's the same idea as Malo's but I moved the centerpoint to be more like a five-pointer.

[Rodney]

It's the same idea as Malo's but I moved the centerpoint to be more like a five-pointer.

 

I've see that same thing before. Perhaps in Martin's patch technology write-up?*

 

Edit: Didn't find it.

 

It may also help in the understanding of it all to why such a change is needed.

For instance, is there a specific issue you've run into or are you simply trying to explore and optimize?

 

Here's a write up I'm sure you've seen Malo. I include it here for those that want to catch up: http://www.cs.sfu.ca/~torsten/Teaching/Cmp...ML/08_2Dcurves/

 

Of interest to me was the very last slide where it talks about testing for sharp edges and exceptions (this would be the realm of three point patches). It should be no surprise to see that they suggest handling those differently than the rest of the mesh. From that early Pixar paper you pointed to that seems to be where the scientists have been spending a lot of their time.

[robcat2075]

I'm looking at a 3-point patch in real time and the subdivision level just above the lowest sort of looks like maybe it's doing the Malo subdivision already.

 

But that might just be real time. I have no idea really.

[Rodney]

I'm looking at a 3-point patch in real time and the subdivision level just above the lowest sort of looks like maybe it's doing the Malo subdivision already.

 

But that might just be real time. I have no idea really.

 

Herein is one aspect that needs to be further defined.

 

Are we talking about subdivision in a Model Converter? For import? For export?

Optimized for a Renderer? Which one?

Optimized for a Graphics Card? Which one and should we assume it is for modeling, animating or final rendering in real-time?

 

While the end goal of each of these might be to make surfaces smooth, each of these will have different approaches and requirements.

 

For fast playback one might assume the exceptions (things that require more computation) are simply skipped or approximated for the purpose of displaying in real time.

[robcat2075]

Maybe Yves might see this and comment.

[Rodney]

It's funny you mention Yves. I just ran across this:

 

A:M subdivides the patches at render time until it is smooth enough. This is an adaptive subdivision technique that can subdivide way much more, at some places, than normal poly models or even the subdividing scheme of sub-D. "untill smooth enough" means that the subdivision process will keep going until the polygonal approximation are close enough to the actual patch surface.

 

Thus, if your patch topology is organized in such a way that it would produce creases, the subdivision process will keep subdividing untill the polygonal mesh conforms to the crease that is modeled by the patch.

 

The assumption is that the renderer will render whatever the artist have put in the model, creases included.

 

This is never the case with poly models because there where no patches to conform to in the first place. But a polygon modeler have to deal with the idiocyncrasies of polygon renderers too. After a while, a poly modeler don't even think about it but have learned to avoid certain types of mistakes. Those mistakes where recognized through the renderer feedbacks and solution where integrated through trial and error. With time and only with time does a poly modeler become excellent. Achieving the craftmanship of a Paul Steed with polygons for instance, takes time and experience (and talent of course).

 

As for crease producing modeling techniques in A:M such as crossover, dangling splines, dead-end splines, flaring splines, etc., in my experience, they are all avoidable in any models whatever the patch density either through spline rerouting or with hooks. I even believe there is a tutorial about exactly that somewhere on the Sherwood forest.

 

If you where to use NURBS (which BTW means "Non-uniform Rational B-Splines") tools, for instance, you would not have those particular problematic constructs because the paradigm doesn't even allow them to be constructed. You would have to deal with patch set discontinuity though. You would also have to tweak 16 CVs per patches.

 

The A:M way of modeling is much more flexible. This flexibility comes with a price though. The price is that there are much more ways to make mistakes in the mesh topology. But A:M is forgiving in that it allows the modeler to make those mistakes and even renders them (with creases though but at least it renders them). After all, is it the application role to decide if it is really a mistake of if it is really the well thought intention of the modeler?

 

Yves

[Malo]

Thank you for your answers, they allow me to better understand certain thing.

I went further in understanding, here is what I see:

 

The first thing that strikes me is the lack of symmetry of the division of 3-sided patches.

It offers three possibilities when the quad and the pentagon have only a possibility.

Here is the rendering of the same model with the three cases for the triangle to see the influence of the latter.

There are differences in the rendering.

 

In writing MDL format, it is this difference, mostly repeating twice the CP "problem" in writing the patch. (here the first-line, the others being the 4 and 5 patch sides)

(?*8) CP1 CP2 CP3 CP1 NormalCP1 NormalCP2 NormalCP3 NormalCP1 0

(?*8) CP1 CP2 CP3 CP4 NormalCP1 NormalCP2 NormalCP3 NormalCP4 0

((?*8)-1) CP1 CP2 CP3 CP4 CP5 NormalCP1 NormalCP2 NormalCP3 NormalCP4 NormalCP5 0

 

The other system of division would he give a better result?

I do not know. She ask me other questions:

- Does it Bring a division more homogeneous?

- Subdivide 3 rectangles instead of 4 rectangles, it does not reduce 1/4 subdivision calculations?

- It does not reduce the weight mdl format? :

(?*8) CP1 CP2 CP3 NormalCP1 NormalCP2 NormalCP3 Normal 0

- Topology for export would not it more compatible with the desired topology in other apps polygonal subdivision?

[Malo]

Hi,

 

By studying the different subdivisions built in AM and Obj export:

 

I had a surprise when exporting patches with three sides.

Whatever the level of subdivision, all models are exported to obj consists of quads, even triangles! :

Even stranger, exporting functions with the "Export triangles", we end up with flat triangles, which are useless.

So I'm probably wrong, there are only quads in AM and there will not solitary triangle in the subdivision of AM, but couple of flat triangle and good triangles.

 

PS : The table is misleading to the subdivision level "Variable". Subdivision is compared to the side of the model on the screen in realtime, while the export is based only on the size of the model. I would have had to find the right size for export.

Example: here the same model enlarges or reduces in order to have a different resolution export.

[Rodney]

Very nice Malo. Excellent presentation.

 

I"m not sure what all it means but you've come close to enlightening me.

 

there are only quads in AM and there will not solitary triangle in the subdivision of AM, but couple of flat triangle and good triangles.

 

VERY INTERESTING!

[robcat2075]

Flat triangles are useless. What does that mean?

[Malo]

The purpose of the triangles in 3D are to create a face. While these flat triangles have no faces, so no need for rendering.

AM using only quads for subdivision mathematical reason, the flat triangles are inevitable in the topology of the creation of 3-sided patches.

The topology of the 5-sided patches suitable for 3-sided avoid that.

 

Now ... is this flat triangles have an impact on the rendering? ... I don't know. I guess the renderer ignores these triangles, but I guess it gives a little more calculations.

[robcat2075]

hmmm... this must be some use of the word "flat" that I am not familiar with.

 

Are not all triangles flat?

[Malo]

Escuse me for my english ... I mean a triangle which is reduced in line with two vertices that have the same coordinates.

Of course all triangles are flat