Nice shot - the LoD works well at preserving the human shape, and there is no large anomalies.

One problem you seem to have though is quick loss of prominent features. You are losing extremely angled polygons (the spikes) very quickly. I would normally aim for the knees, elbows, neck and facial polygons to collapse before the spikes, as they are prominent features and likely to contribute to the outline of the image.

Otherwise, well refined and good avoidance of texture problems etc.

Impressive !

What kind of model is this ? Skeletal animation ?

How does the algorithm perform on animated models (skeletal/keyframe) ? Do artifacts appear while animating ?

Tim

Very nice !

In your evaluation function, do you handle texture mapping coordinates ? If so, how..?
And how many polygons are there in each image ?

Thank you very much for such a positive comment. The model is actually a half-life model from polycount.com, it has a complete skeletal animation system. The only artifact that the animation produces is when the character gets to the really low levels of detail like in image number 5, his feet and hands tend to disconnect from his body.

As i am unaware of the process (I am in the process to read the article) i have certain questions.

1. Are there any new polygons that gets created while reducing the other???
2. What about calculating Texture Coord for these new polys.

Thank You. No I totally ignore the texture coordinates. In image 1 there are 639 triangles, and the vertex count is decreased by 25% in each addition image. The vertex count is never aloud to go below 10% of the total vertex count.

There are no new triangles created, you just remove the vertexes that will affect the overall look of the model first.

Thank you very much for your comments.

I think that this algorithm would work well for distance based LOD. As the model gets further away those "prominent" spikes would likely contribute zero pixels to the scene, while the overall knee area would still be relatively significant.

Zero pixels for nearly horizontal triangles that look fairly long? Not likely :)

One thing that I don't understand is how you prevent seams from forming when you change parts of the texture that you use.

For example, if you were to have a model that used 2 sections of a texture. One for the front, and one for the back. Wouldn't it be impossible to remove the verts that are connected to both sections of the texture?

"For example, if you were to have a model that used 2 sections of a texture. One for the front, and one for the back. Wouldn't it be impossible to remove the verts that are connected to both sections of the texture?"

Well, it's not impossible, it just results in a lower quality image. For this reason, those modifications are penalized so that collapses which have a larger effect on the geometry of the model (but do not cause problems with the texture mapping) are made first.

Max

Nice IOTD.
I've been doing some work recently on LOD mesh generation for a 3dsmax exporter for a game I've been working on... seems static "Levels" of LOD are more plausible than more complicated geometry (and art, for that matter) generation systems such as patch rendering (wasn't that supposed to be the Next Big Thing?!). Off topic, I think it's peculiar how 3D developers go through phases of the "next cool thing" code trends.. I swear it's almost a right of passage to being a complete 3D coder, everyone at some time or another seems to turn their hand to "obligatory" milestones in their coding career - starting with particle systems and raytracers, the infamous terrain engine (no offence to people who take the time to implement one, but why do they always seems to come straight from someone elses graphics paper on the subject?), the Quake2/halflife level renderer and finally on to stuff that really needs some heavy math like realtime CSG and rigid body dynamics. Excuse my meandering.

Anyhow, as for the questions regarding texture/material/shading preservation using this vertex collapse method - typically each vertex contains a "cost" precached value, indicating the visual impact removing this vertex from the mesh would have (edge length is often a good weight) and allowing the reduction code to leave those vertices in existance until last. In meshes that contain areas where two verticies occupy the same [x,y,z], but yet have differing normals, colour, U/V's or or material- it may be advisable not to remove these vertexes AT ALL to preserve the visual integrity of the model, as it generally avoids removing verts that define the primary edges. Just my 2c.

Anyhow - nice IOTD, I'll crawl back in my box now :)

The reason people do terrain renderers from graphics papers is that they are trying to implement something that the paper suggests MIGHT work.

I dont think thats a bad thing IMHO, because you have to understand the problems better to understand the solution.

With the bsp level renderer, its probably just a matter of having something nice to display (it was for me).

As for me, I am steering clear of rigid body dynamics and all that math heavy stuff :)) I am a game programmer, not a mathematician jim!

Phil.