See what's going on with flipcode! |
Rendering An Oddball 3D Model Type Question submitted by (16 June 1999) |
Return to The Archives |
My artist submits his models to me using a program called Nendo. Nendo
uses per face mapping rather than using planar or cylindrical mapping
techniques. The problem comes when we try to draw the model - as each vertex within Nendo has any number of U & V coordinates and Direct3d only allows one UV coordinate per vertex - Nendos .X format exporter exports one vertex PER UV pair. So a model with 100 vertexes can in practise wind up with 300-400 'vertexes'. If all of these are transformed, clipped and rendered then things tend to get terribly slow. My current solution involves analysing the model at load-time, transforming the unique vertexes ONCE then propogating the transformed vertexes into the vertex list so they pick up the appropriate UV coordinates. This seems like a terrible fudge, there must be some method of dealing with this that is elegant. |
||
The most common way to accomplish this goal is to store the UV
coordinates in the polygon rather than in each vertex. When doing this,
a polygon will have an array of world-space vertices (either by pointer,
index, hash lookup, whatever) as well as an array of texture-space
vertices (UVs). On output from your Nendo tool, you'll need to visit each polygon and grab the UVs from each vertex and move them into the polygon's texture-vertex list. At some point, you'll need to optimize your vertices. A common way of doing this is to find all vertices that are within a threshold distance (say 1.0e-4) of each other and combine them into one vertex. Each time you combine a group of vertices into one, you'll need to update the affected polygons. In rare cases, this optimization pass can cause two vertices of the same polygon to become one (very thin polygons get collapsed into a line or a single point.) So you'll need to detect this case. If you're lucky, your tool will create groups of vertices that are identical in location, so you can simply compare locations and not have to worry about collapsing groups of vertices via a threshold (and hence, not have to worry about "collapsed polygons." Response provided by Paul Nettle |
||
This article was originally an entry in flipCode's Fountain of Knowledge, an open Question and Answer column that no longer exists. |