Quote:

---

ist marco gruber der typ von thiny things?

---

In Antwort auf:

---

TRUFORM™ FAQ


If you any questions on the contents of this page, please contact ATI Developer Relations at devrel@ati.com.


What is TRUFORM™?
Is there any research to back this up?
Why should I consider using TRUFORM™ in my game?
How much work does it take to start using TRUFORM™ in my game?
Can I control the order of TRUFORM™ tessellation?
Can I use TRUFORM™ as an extension to my existing LOD techniques?
How can I author art for TRUFORM™?
I've heard that TRUFORM™ is incompatible with skinning. Is this true?
How much does using TRUFORM™ impact my performance?


What is TRUFORM™?

TRUFORM™ is a technology developed by ATI which enables higher-order surface rendering through traditional triangle rendering APIs. In DirectX 8, these surfaces are referred to as N-Patches. In OpenGL, they are referred to as PN Triangles and are accessed through the ATI_pn_triangles extension.
See the TRUFORM White Paper for more details.


Is there any research to back this up?

ATI recently co-authored a paper on this technology with researchers from the University of Florida and Microsoft. This paper, Curved PN Triangles, was presented at the ACM Symposium on Interactive 3D Graphics in March 2001.


Why should I consider using TRUFORM™ in my game?

When a game uses TRUFORM™ to tessellate geometry that should have smooth organic shapes, the silhouettes and lighting of the objects are improved. This is particularly important on characters, whose blocky shapes so often detract from the immersive experience of a game. TRUFORM™ is unique in that the same data and same API entrypoints are used when using TRUFORM™ as when not using TRUFORM™. This means that any application that uses TRUFORM™ is backward compatible with chips that do not render any higher order surfaces (i.e. all previous generations of graphics chips). Additionally, models require little tuning to look good with TRUFORM™, even for a game near completion or already released . Most models "just work." This ease of integration was one of the fundamental goals in the creation of TRUFORM™.


How much work does it take to start using TRUFORM™ in my game?

In terms of visual impact for time spent on the coding, TRUFORM™ is one of the best features you'll ever integrate into your engine. It was designed to be that way from the start.
There are three basic steps to using TRUFORM™ in your game:
Art preparation
Vertex Buffer creation/layout
Rendering

Art Preparation consists of making sure that the triangle-based art that comes out of the end of your art pipeline has crease polygons in the right places. For much of your art, this will "just work." For edges in your models which are defined to be hard edges (by MAX's smoothing groups, for example), you will need to insert crease polygons. We have both a MAX previewer and a sample exporter (with a standalone viewer) that you can look at to see how this can be done for automatically. The TRUFORM™ resources page on our website has these downloads.

Vertex Buffer creation and layout merely consists of making sure that you are passing both positions and normals to the API (Direct3D or OpenGL). This is necessary for TRUFORM™ rendering since the Bézier control mesh is derived from the position and normal information associated with each polygon. In cases where you are currently doing your own lighting in the application and not using the 3D API for lighting, you may not be currently passing normals to the API. You should pass the normals to the API when using TRUFORM™ and let the hardware do the lighting, environment mapping etc on all of the vertices, including the ones generated on-chip by the TRUFORM™ tessellator. In Direct3D, you'll be using either a flexible vertex format (FVF) or a stream declarator (the first parameter to CreateVertexShader()) to define the layout of your vertex buffers and vertex streams. When using a stream declarator, it is necessary to use the D3DVSDE_POSITION and D3DVSDE_NORMAL tokens appropriately when specifying which components of your vertex are the position and normal. Your vertex structures don't have to change; you just have to be specific about where your positions and normals are. There are no restrictions on the data types of the components. For example, you have traditionally used float triples (D3DVSDT_FLOAT3) for normals, but you could use D3DVSDT_SHORT4 and it would work just as well.

Rendering consists of turning on TRUFORM™ and drawing your models. In Direct3D, this means that as long as your vertex buffers are created with the D3DUSAGE_NPATCHES flag and the vertex buffer has positions and normals, you can just draw with the usual DrawPrimitive() entrypoints, setting the D3DRS_PATCHSEGMENTS render state to control the amount of tessellation. Setting D3DRS_PATCHSEGMENTS to 1 means tessellation is essentially off, as each triangle edge has one "segment" by default. Setting D3DRS_PATCHSEGMENTS to 2 means that the triangle has two segments per original edge (or one new vertex per original edge), which results in 4 triangles for every original. In OpenGL, you use the following code: glPNTrianglesiATIX (PN_TRIANGLES_TESSELATION_LEVEL_ATIX, tessLevel). In OpenGL, the numbering scheme for tessellation levels refers to the number of new vertices added along the edge of the original triangle. In this scheme, level 0 refers to no tessellation, level 1 refers to four triangles generated from the original and so on. Also keep in mind that OpenGL also has an explicit gl{En|Dis}able(PN_TRIANGLES_ATIX) for enabling and disabling tessellation.

If your models are prepared for TRUFORM™ tessellation, the only cases in which this is not as simple as flipping bit are if you were previously using a custom software lighting model or environment mapping method that is not expressible in the fixed-function API. In this case, you should use a hardware vertex shader to do the custom lighting on all of the vertices post-tessellation. This will include the ones generated on-chip by the TRUFORM™ tessellator. In DirectX 8.0, N-Patches were exposed via the D3DRS_PATCHSEGMENTS render state. As long as you've created a vertex buffer with the D3DUSAGE_NPATCHES flag and the vertex buffer has positions and normals, you can just draw with the usual DrawPrimitive() entrypoints. By default, you will see cubic interpolation of positions and linear interpolation of normals.


Can I control the order of TRUFORM™ tessellation?

TRUFORM™ supports linear or cubic interpolation of position and linear or quadratic interpolation of normals. In DirectX 8.0, this was hard wired to cubic position and linear normals. In DirectX 8.1, you have more control over the interpolation order of the positions and normals of the generated vertices. Specifically, the new D3DRS_POSITIONORDER and D3DRS_NORMALORDER render states control interpolation order. The position interpolation order can be set to either D3DORDER_LINEAR or D3DORDER_CUBIC. The normal interpolation order can be set to either D3DORDER_LINEAR or D3DORDER_QUADRATIC. In OpenGL, use the following code: glPNTrianglesiATIX (PN_TRIANGLES_POINT_MODE_ATIX, PN_TRIANGLES_POINT_MODE_{LINEAR|CUBIC}_ATIX).


Can I use TRUFORM™ as an extension to my existing LOD techniques?

TRUFORM™ is designed to fit right in with an application's own geometry LOD techniques. Essentially, you can think of TRUFORM™ as a means of providing LOD models beyond those already used in the application.


How can I author art for TRUFORM™?

Since the input to TRUFORM™ is just a triangle mesh, your art pipeline needs very little modification. As mentioned earlier, we have provided a 3DS MAX plug-in which will allow your artists to preview their art with TRUFORM™ tessellation right in a MAX viewport, without ever leaving the tool.



I've heard that TRUFORM™ is incompatible with skinning. Is this true?

A correct statement would be "higher order surfaces are incompatible with matrix palette skinning." Anyone who is saying that their higher order surfaces are compatible with matrix palette skinning is doing a large amount of work on CPU thus negating the bandwidth saving benefits of hardware higher-order surfaces. ATI's TRUFORM™ implementation occurs completely in silicon. Because of the fact that matrix palette indices cannot be interpolated across a polygon in any meaningful way, it is not possible to index into a matrix palette for the newly-generated vertices. This makes higher-order surfaces and matrix palette skinning incompatible. It is possible, however, to use traditional 4 (or more) matrix skinning where the references to the bones is implicit. The downside to this is that the model must be broken down into sub-chunks and rendered in several API calls. In practice, however, we have not found that segmenting a character into chunks is nearly the performance penalty that most game developers believe it to be.



How much does using TRUFORM™ impact my performance?

Often times, graphics chips are fill-rate or memory bandwidth limited. This means that the chip may be capable of more geometry throughput than you ever see, due to the fact that the memory systems simply aren't able to feed the voracious geometry processor. One of the major goals in our creation of TRUFORM™ was to allow you to feed the geometry processor despite memory bandwidth limitations. In this way, you can think of it as a form of geometry compression, like any higher-order surface. Since your low-polygon geometry is what is input to the chip, you keep memory bandwidth low, while increasing geometry detail with TRUFORM™ tessellation just prior to vertex shading. The result of this is that you may see no performance impact at all when using TRUFORM™ tessellation if you weren't limited by the geometry processor's power in the first place.

---