I`m trying to save the time of my modeller and save him from re-modelling the same character three times - since we want 3 levels of detail (Original, Half tris of Original, Third tris of Original). Considering, we have about 10 different characters in our game with 3-5 animations per each, it`s a LOT of work to be made and exported into engine. So if it takes me a week to program a routine that makes quality low-poly version of the original, than it`s great. Since I don`t plan to do it real-time, all LODs shall be preprocessed (and selected via Options Menu), any slow O (N^2) method (or worse) is fine. It just needs to be quality and preserve outline curves because of diffuse lighting (no per-pixel lighting). Just for the record, our models are 1500-2000 tris each. Thanks VladR

there is an app here which shows a few different methods. I'm sure you could load you model and check them out.

http://www.jsomers.com/vipm_demo/meshsimp.html

I think it's still there's still a lot of call for LOD today - even if cards can push out so many polygons. Look at a game like Spiderman 2 - the size of the city, all the cars and people, etc. I can pick out a number of LOD methods they are using to keep things smooth, and I'm very impressed.

I would just use some sort of progressive mesh method mixed with a normal map to compensate for lost details. Pre-compute all meshes and store in files, or if you're not LODing much, just compute at load-time. A great thing about doing at load time, you can update your project later and not have to redistribute the precomputed files. The best way would be to generate the LOD files every time you update your prog, or the first time you run your program (during the install for example).

Quote:Original post by lonesock
there is an app here which shows a few different methods. I'm sure you could load you model and check them out.

http://www.jsomers.com/vipm_demo/meshsimp.html

Interesting link, Thanks, I`ll try it.

Quote:Original post by mikiex
infact reading your post again, your models are pretty low
as it is for these days.... many games are looking to push 5000+ polys for a top LOD character

Well, I`m targeting Budget range of games, not a AAA game that can push it`s HW limits. I still need this game to be playable on TNT1-level cards that can be found in many 500-1000 MHz machines still. Since I`m animating characters through Vertex Shaders, these shall run on CPU with such old cards, so the less vertices, the better for CPU too.

Quote:Original post by mikiex
Depends on how you make your models, if they are built from
patches then u can get your LODs for free.

Nope, pure triangles.

Quote:Original post by mikiex
For standard models you could use 3dsmax's multi-res or
anything else that maintains uv's

That`s what we want to avoid ! No more manual work with models ! We`ve done that with our first game and we had just 4 characters there with 1-2 animations. It was a tough experience and I definitely want to avoid it here when we have separate animations for weapons and for character. Just Reexporting and Reimporting it all already detriangled into Game would take us 2 days. And with so many different directories and files, errors are bound to happen. That`s where the function shall take care of it itself.

Quote:Original post by mikiex
one question would be, why do you need LODs ?
why not build your models to one level?
newer graphics cards will kick them out fine
try some tests??

Man, I`m not competing with BIG GUYS out there so I can say that min. config is 1,5 GHz with GF3. Then no one would take my game into retail budget. I don`t expect those with 4GHz machines and ATI X800 to run and buy my game. Those probably never even look into budget section (if I actually make it there, that is).
And based on my previous tests with our first game, it`s quite a difference in fps if all characters on screen have 10k polys, or just 3k polys on TNT1.

Quote:Original post by Jim Adams
or if you're not LODing much, just compute at load-time. A great thing about doing at load time, you can update your project later and not have to redistribute the precomputed files.

Load-time preprocessing is absolute NO-NO. What I hate most is looking at the load screen in any game for 2 minutes and guessing what on earth is this game actually doing if I have 256 MB of RAM and the textury quality is low, and I freed 200 MB of RAM before running the game ? Besides, such LOD preprocessing eats up RAM very quickly, and I want to avoid swapping, if at all possible, at least on 128 MB of RAM. Because then during the game, the game would swap because of my previous preprocessing.

The only viable preprocessing during load-time is decompression of character animations into Vertex Buffers.It`s much faster to load just 200 KB of data and decompress it and make a 1 MB Vertex Buffer, than to load whole 1 MB Vertex Buffer from HDD. Besides, I already have a Vertex Decompression Shader in-place, so after some performance test on low-spec machines, I might stuff the packed animation directly into Vertex Buffer thus shortening the load-time to absolute minimum.

Quote:
Load-time preprocessing is absolute NO-NO. What I hate most is looking at the load screen in any game for 2 minutes and guessing what on earth is this game actually doing if I have 256 MB of RAM and the textury quality is low, and I freed 200 MB of RAM before running the game ? Besides, such LOD preprocessing eats up RAM very quickly, and I want to avoid swapping, if at all possible, at least on 128 MB of RAM. Because then during the game, the game would swap because of my previous preprocessing.

If you're using DirectX, I would recommend checking out the progressive mesh sample - it's extremely fast at reducing the polygon count, so load-time is not a problem. Coupled with the load-time and save to disc for later use method, I don't see a big problem.

Also, you can use the same vertex buffers for the vertex data and just swap out the index buffers for the various levels. If an LOD creates extra vertices, jsut append those to the end of the vertex buffer and compensate in the index buffers.

Have your artist do everything in NURBS if he/she can. That way he/she can simply reduce the tesselation level for the different models (with maybe a few touchups). That should give the best overall result, but it might be harder to model at first.

Quote:Original post by Raloth
Have your artist do everything in NURBS if he/she can. That way he/she can simply reduce the tesselation level for the different models (with maybe a few touchups). That should give the best overall result, but it might be harder to model at first.

Well, it`s too late for that now that hero and all creatures are already animated. And now he`s finishing animations for second game, so it`s late for that game too. Maybe in next game.

Besides, this still brings the problem of exporting countless animations into many subdirectories which is very error-prone. We`ll see later if I find the time to implement some of above mentioned algorithms. Though I currently prefer devoting the time to finishing Radiosity than this.