Thoughts about TRUFORM?

My thoughs: It’ll rock!

I agree wholeheartedly that is will indeed rock. All we need is for there to be a big push to get an extension finalized and supported by every vendor possible.

I really like the idea that even low-polycount content can get a big boost in visual quality. This would make it a lot easier to design low-poly models for pre-N-Patch cards, but that will look sweet on cards that support the feature.

Looking over the preliminary spec on ATI’s page, though, I have a few issues:

  • It might be nice if there were the same kind of support for fractional tesselation that nVidias evaluators have, so that we can get continuous LOD.
  • It would be nice if the tesselation parameter could be automatically generated based on one or more of the following things: distance from the viewpoint, dot product of face normal with view direction (so that silhouette edges could be tesselated more), and maybe even screen space area occupied by the triangle.

The last two methods of tesselation are probably unlikely to happen as they would require transforming the defining vertices of the patch before tesselation in order to perform the tests.

ED - Now that I realize it all three of these generation modes would require transforming the defining vertices beforehand.

[This message has been edited by timfoleysama (edited 06-01-2001).]

i think the nv_evaluators possibly have more power… possibly… but ati can do one thing that nvidia always forgets… user friendly extensions… and rendering with glBegin( GL_ATIX_TRUFORM );
glVertex…
glEnd( );
is much simpler than the nvidia version with the glEvaluatorNV stuff and those…

and thats why i really like this new extension of ati, even if i dont have an ati… i wait since now long time for new glBegin statements… why dont they do that more often?

I like the idea a lot. Much easier to use than evaluators.

I’d be interested to see the speed. Evaluators aren’t fast enough to build a real model with on the Geforce3.

– Zeno

I think you’re missing the point of NV_evaluators. The point is to provide an interface to the kind of surfaces that content creation apps actually use – specifically, control points for real patches. This provides the kind of control that artists need to produce quality curved surface content.

I would argue that the NV_evaluators extension is very easy to use. What could be easier than providing control points and then rendering? It’s a clean, simple extension, one that’s not too picky about how the tessellation occurs, but that insists on a few basic ground rules to make sure things work.

As for the performance, it’s not perfect, but there’s plenty of room for optimization on our side. This is a first release we’re talking about, after all. If all the extensions work, I’m happy.

It’s very easy to criticize, but if you’ve tried to write a curved surface implementation that ensures crack-free boundaries between patches and supports 4 different types of patches (quad/tri crossed with int/frac), and also supporting normal generation and different tessellation on each of the 4 sides, you’ll know that it is a very tricky problem.

I have a lot of opinions about the so-called “N-patches”, but for reasons that should be obvious, I’m not posting them.

It would be extremely short-sighted to add new enumerants for Begin. Begin is one of those entry points that is most definitely not meant to be extended. I surely hope no one other than the ARB adds new primitive types, because it would be a huge mess if someone else tried to.

  • Matt

I should refine my previous post

When I said easier to use, I meant easier to use in that no change of data is needed. You used to be rendering triangles, you are still rendering triangles.

On performance: I didn’t mean to rip on the amount of effort it must have taken to get these things to work (which must have been extraordinary) only that from what I have seen, they are not so fast. I made the assumtion that, since the surfaces are hardware accelerated on the GF3, they wouldn’t get appreciably faster. Apparently a lot of work must be going on in the software part of the driver?

At any rate, the demo from nvidia with the character made from patches is not fast enough to make it usable. It definitely overwhelms the bandwidth savings that you get from these surfaces, which is one of the reasons they would be nice to be able to use.

– Zeno

After reading through ATI’s papers and playing with their tools a bit, I’m still questioning the ease of implementing this without checking all your meshes for cracks.

TruForm, or subdivision surfaces, is prone to the same artifact as T-junctions, right? Cracks. Cracks in the geometry of the mesh after it’s been tesselated. If the tesselation is performed in software, it’s easier to check for cracks, and fill them. But sending it to the card for tesselation post primitive assembly is problematic (unless the card is psychic) because it doesn’t know if another triangle coming down the pipe that shares an edge, but the points which form that shared edge have different normal values.

So, there’s a plug-in for 3DStudioMax that checks for cracks and fills them. But, that requires the additional work of an application that may not be the tool of choice by the developer.

I’m interested in understanding nVidia’s opinion of n-patches/TruForm/Subdivision surfaces. IIRC, GeForce3 doesn’t support them? Is it because of the gaps? Or merely because NV_Evaluators are superior?

My 2 cents…

Glossifah

You have fallen victim to the trap of assuming that there are just two levels of performance that can exist in 3D graphics: “unaccelerated” and “accelerated”, or, in the alternative form of this not-entirely-accurate dichotomy, “HW vs. SW”.

An example I’ve used in the past to illustrate this is drawing lines. One way (not the only way, by a long shot) to draw GL lines is to perform T&L in SW and draw a quad, using the line width to compute where the quad vertices go. Is this a “HW line” or a “SW line”? Clearly, neither is fully accurate. It is a combination of both.

I won’t go into greater detail, but I will say that (1) GF3 does accelerate the rendering, but that doesn’t mean that there isn’t more we can do, and (2) some of these enhancements are actually algorithmic enhancements that can provide more than just a factor-of-X speedup.

  • Matt

Originally posted by Glossifah:
[b]After reading through ATI’s papers and playing with their tools a bit, I’m still questioning the ease of implementing this without checking all your meshes for cracks.

TruForm, or subdivision surfaces, is prone to the same artifact as T-junctions, right? Cracks. Cracks in the geometry of the mesh after it’s been tesselated. If the tesselation is performed in software, it’s easier to check for cracks, and fill them. But sending it to the card for tesselation post primitive assembly is problematic (unless the card is psychic) because it doesn’t know if another triangle coming down the pipe that shares an edge, but the points which form that shared edge have different normal values.

So, there’s a plug-in for 3DStudioMax that checks for cracks and fills them. But, that requires the additional work of an application that may not be the tool of choice by the developer.

I’m interested in understanding nVidia’s opinion of n-patches/TruForm/Subdivision surfaces. IIRC, GeForce3 doesn’t support them? Is it because of the gaps? Or merely because NV_Evaluators are superior?

My 2 cents…

Glossifah[/b]

Well, I think ATi’s comment on the cracks issue says it all: “If your model is broken, your model is broken.” …

If your models isn’t broken, it works. Very simple The extension is already there in the Radeon drivers (though software driven) and I’ve used it and it’s very easy to use. I have also yet to come over any model that it doesn’t work well for, I’ve never seen any cracks on neither models I’ve created myself of models downloaded from the net.

It’s like

glEnable(GL_PN_TRIANGLES_ATIX);
glPNTrianglesiATIX(GL_PN_TRIANGLES_TESSELATION_LEVEL_ATIX, preferredLevelOfTesselation);

and there you go with new life on your old model. N-patches are such an elegant solution, I think it’ll be a good selling point of Radeon II cards since it may even be possible to enable it for older games through the driver.

As an advocate for true subdivision surfaces (Truform is approximating it by assuming the normals actually mean something about the surface), I must say that they are not prone to cracks, as long as you followed the subdivision scheme’s boundary condisions properly. Of course, this depends on your subdivision scheme, but that’s a bit off topic.

As to Truform vs. evaluators, I would say that Truform is much easier to implement on the developer side, since the model data has not “changed.” In other words, the artists don’t have to switch from using triangles to using some other primitive. For some artists, this can be an issue.

Truform has a problem, however. The artist cannot be absolutely sure of what a particular change will do to the high-LOD model in whatever 3D modeling package he is using. With evaluators, if the modeling package supports patches, then the artist knows exactly what will be changed by any particular change in the model. ATI should release a Truform plugin for popular modeling programs that will allow the artist to at least see what he is changing.

Originally posted by Korval:
ATI should release a Truform plugin for popular modeling programs that will allow the artist to at least see what he is changing.

there is already a 3dsmax plugin.

ok… i think both do some very different things… one is supporting the not-triangle-stuff of modelling program, the other wants to optimise the triangle-stuff…

but what i ment with glBegin-flags, is not having something new there in ( i know its very slow ) but having new primitive-types to render… ( i missed once the GL_LINE_FAN… ) and there can be a lot of new things… i mean… this TRUFORM is just something that wants to get out the best of the triangles… so its a new type of “primitive” wich uses the same data structure than before…

as you perhaps know a GL_POINT_SPRITE_EXT would be a nice new primitive, too… there are others…

oh, and i think the evaluators look nice, yes… but no one of my modelers really know how to work with them yet cause they learned all triangle-meshing… so it takes some time for them to change… and during this time TRUFORM is great

I wrote demo which transforms triangles data to NV_EVALUATORS.

ironpeter.narod.ru/np.rar

This demî was based on ATI “software” patches tesselation demo.

It’s really a bad idea to try to take existing triangular models and convert them into models built out of patches, especially for use with NV_evaluators.

The original model was likely tessellated beyond what is necessary for building a new model; you will get far too many patches.

There is no local algorithm that can produce C_1 (or even G_1) continuous patches out of a triangular mesh. I believe this has been proven. The only such algorithms are global algorithms, i.e., they look at the whole mesh at a time rather than just a triangle, or just a triangle and its neighbors. They are also slow.

Constructing N-patches from a triangular model and feeding them into NV_evaluators is especially bad. For example, if you use AUTO_NORMAL, you will get lighting discontinuities due to the non-C_1 nature of the surface.

You can’t even simplify the mesh and then generate patches, to improve performance; this will amplify the discontinuities.

I would rather you just draw the triangular mesh than try to hack something like this together.

Either design your models using surfaces in the first place or don’t use surfaces at all. Sometimes surfaces are the right choice, and sometimes they aren’t. When they aren’t, don’t try to pretend that they are.

I would point out, also, that there are two entirely separate reasons why tessellating a model to a higher resolution may enhance visual quality. The first reason is that curves are filled out better, rather than being blocky. The second reason, which in many cases is very important, is that it improves the sampling rate for per-vertex computations; this improves, for example, the quality of lighting, especially specular highlights.

When you see images of this stuff, you should keep both of these in mind. Remember that there is actually a very cheap way to accomplish high-quality specular lighting without tessellation – a reflection-gen cubemap. Likewise, you can often get higher-quality diffuse lighting using a normal-gen cubemap, though the difference here is smaller. (Remember that both of these techniques are basically per-pixel lighting methods.)

There are other cases where tessellation still matters for per-vertex computations; in fact, even for cubemap diffuse and specular, tessellation matters. (That it matters for diffuse is rather surprising, but true.)

Keep in mind these two separate goals, and judge images accordingly. Using lots of tessellation to improve lighting quality can look nice, but in the big picture, it’s wasteful. The curves are what usually matters.

  • Matt

Originally posted by mcraighead:
[b]
There is no local algorithm that can produce C_1 (or even G_1) continuous patches out of a triangular mesh. I believe this has been proven. The only such algorithms are global algorithms, i.e., they look at the whole mesh at a time rather than just a triangle, or just a triangle and its neighbors. They are also slow.

  • Matt[/b]

Hi
Well, if you mean to produce C1 joined bezier patches from triangular mesh - I think you’re right. But the Butterfly subdivision scheme can generate C1 surface from the triangular mesh (it even interpolates control points), and the Loop scheme can generate C2 surfaces, which are approximating, but for well pre-tesselated mesh are very close to the original mesh.
Regards
Martin