Sign in to follow this  
d000hg

Progressive meshes?

Recommended Posts

d000hg    1199
So I'm thinking these would be nice to use rather than having a few different detail copies of each model, but I'm concerned whether they are very memory and speed hungry. If I had a 3000poly mesh like a car and wanted to be able to go to about 2-300 polys, how bad would it be?

Share this post


Link to post
Share on other sites
CoffeeMug    852
The problem with progressive meshes is that they require a lot of AGP bandwidth. You'll be forced to transfer the entire model to the video memory every frame (or you'll have to allocate video memory for every instance of the model). In practice it's usually not worth it. Descretizing the model to a number of LOD models will get you visually appealing results with much less demand for bandwidth and CPU work.

Share this post


Link to post
Share on other sites
Karg    133
Depending on how you impliment you progressive mesh, you don't need to transfer the entire model to the video memory every frame. Writing a good progressive mesh is no small task either.
Another thing you have to test is the size of the model that gives good effeciency. Obviously a 10 poly mesh won't benifit from simplification but a 100,000 poly mesh would. Basically, see if it's worth it.

karg

Share this post


Link to post
Share on other sites
paulc    132
You can just use a single copy of the vertex buffer stored statically on the graphics card. The only data that needs to be modified is the index buffer or list, and you can have multiple copies and so have instances of a particular mesh. Good implementations can use minimal CPU time to update the index list and then that is the only thing that needs to be sent across the AGP bus (using something like VBO's in OpenGL to perform the transfer efficiently). There is an article in Game Programming Gems 2 by Tom Forsyth that details and compares a variety of different progressive mesh implementations, comparing them in terms of a number of measures including overall memory useage, memory per instance, cpu cost and bus bandwidth.

As Karg mentioned, the difficulty is in writing the code to create the collapse sequence in the first place. There are a varietly of special cases to deal with, and you also have to consider what features of the mesh you use to calculate the collapse order. You have to assign each edge with a cost to collapse it, these cost could simply be the difference in face normal between two tris or it could involve more complex parameters such as tex co-ords, vertex normals, vertex colour etc. Its a question of what your worried about and what level of visual quality you want.

The one thing that progressive meshes do not work well with is vertex lighting. The sudden disappearance of a vertex can be very noticeable, although morphing the changes can alleviate matters altough this does add some extra overhead to any implementation. The prevalence of cards capable of per-pixel lighting does negate this problem to a degree, but it still needs to be considered.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this