PDA

View Full Version : PN_Triangles & NV_Evaluators



V
04-19-2001, 07:32 AM
"PN_Triangles", which are an ATI's HW surface solution, have many differences from Nvidia's HW surface solution "NV_Evaluators".

PN_Triangles can be sent via standard tri-arrays, while NV_Evaluators are sent via an 'immediate' mode with ctrl pts. Both create cubic Bezier patches which can be tesslated to a smooth degree. NV offers more control via actual ctrl pts. and individual edge tesselation, but require a totally different data path than today's triangle-meshes, whilst ATI offers backward compatibility and less control. Both require proper continuity between the primitives or cracks occur.

Anyways, there is much to consider on both sides-

Was wondering what everyone thought on this topic, (pros/cons) as this is the first time that upcoming hardware GeForce3/Radeon?X? will natively handle curved surfaces since the NV1 chip.

mcraighead
04-19-2001, 09:12 AM
I am biased, seeing as I wrote the NV_evaluators spec, but I'd like to begin by pointing out some details that I think are important. (To alleviate some of that bias, I will speak solely in the positive, and solely about NV_evaluators, without reference to anything else.)

NV_evaluators will allow you to build surfaces with any degree of continuity you desire. Zero-order continuity (no gaps), first-order continuity (no gaps, smooth surface, continuous normal vectors over the surface), or higher. This is a modeling problem.

NV_evaluators ensures that normal vectors are consistent with the actual surface; they are analytically derived, after all.

NV_evaluators supports both quad and tri Bezier patches. Most modeling tools should be able to output in either this form or in a form that can be reduced to Bezier patches.

NV_evaluators has non-integral tessellation support. This is _very_ important for building smoothly morphing LOD control.

NV_evaluators requires that implementations adhere to strict rules that guarantee that there will be no cracks or gaps between adjacent surfaces. Importantly, you can also match up quad and tri patches in a single mesh.

NV_evaluators supports rational patches, as well as proper normal vector evaluation for rational patches. This allows you to build exact conic sections, such as spheres and tori. (Spheres are tricky because they have singularities at their poles.)

In an appropriately optimized implementation, NV_evaluators MapControlPointsNV calls can be captured inside a display list to optimize for static data.

- Matt

Gorg
04-20-2001, 02:48 PM
Yes. N-patches and and Evaluators are for a very close but subtly different purposes.

N-Patches are to give smoothness to a non-smooth representation of a model.

Evaluators are for a smooth representation of a model.

daveg
04-26-2001, 05:24 AM
The goal of PN triangles is to give developers an easy means of increasing the level of tessellation in their models without impacting memory footprint or memory bandwidth. For each triangle the app sends to OpenGL, the PN Triangle tessellator takes the positions and normals and produces a Bezier patch from only that information. Since this doesn't require any information about the neighboring triangles, it allows a developer to leverage existing artwork to give a better looking model on higher-end cards while still providing a reasonable fallback case (the original mesh) for cards that only render triangle primitives. This smoother surface provides smoother silhouettes and better looking specular highlights with very little programming or modeling work.

For more information, have a look at the paper Alex Vlachos, Jörg Peters, Chas Boyd and Jason L. Mitchell, \"Curved PN Triangles\" (http://www.ati.com/na/pages/resource_centre/dev_rel/CurvedPNTriangles.pdf) ACM Symposium on Interactive 3D Graphics (http://www.siggraph.org/conferences/i3d/) , 2001. And the ATIX_pn_triangles spec (http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/RadeonSDK/Html/Info/ATIX_pn_triangles.txt) .