Archived

This topic is now archived and is closed to further replies.

Dinamic LODing in BSPs

This topic is 4945 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, to start I mention BSPs but this method can be used in quad/oct-trees, so its not in any way restrictive. I had this idea while playing Return to Castle Wolfenstein, Multiplayer, the beach map. Basicly, much of the map can be seen from a small hill top in the beach. You can see the entire beach, the bunkers, the ocean, the players, etc, etc, etc... Now, from my position in that hill top, i would guess that the engine would have a lot to deal with, a lot of geometry to dump onto the graphics card. After doing basic occlusion using the BSP, and determining wich BSP leafs we have to draw, we could pass all of the visible geometry through a real-time LOD algorithm, to reduce the polygon count of map-meshes and player-meshes that are farther away. But then I had the idea of pre-processing some of that at the BSP compilation stage. Lets look at these two positions: [Hill Top] -> [Entire Beach] [Boat] -> [Small part of the beach] (->) means "i can see". Now, this is after the BSP has been compiled, but we are going to add a few stages to it still. For each leaf we compute the number of static (map) polys seen: [Hill Top] = 140k [Boat] = 32k Then, if that leafs'' visible polygon is above our threshold, we run a LOD algorithm on it, to reduce the number of polys, and for that we clone the visible leafs: [Entire Beach] => LOD Algo => [Entire Beach2] Lets check our polycount now: [Hill Top] = 55k [Boat] = 32k And the apearence of the BSP leaf structure: [Hill Top] -> [Entire Beach2] [Boat] -> [Small part of the beach] So, in other words, while at the Hill Top I''m no longer looking at the original beach geometry, but instead a 2nd LOD''ded version was created... This process makes sure that wherever we are in the map, the number of visible polys is allways under a certain pre-determined budget... I''m pretty sure other engines already do this, either in real time, or using pre-processed (BQO)SP trees.... What do you think? Salsa cooked it, your eyes eat it!
[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak

Share this post


Link to post
Share on other sites
Actually, if you''re interested in this subject, there''s an opensource game engine called Sauerbraten based on LOD in BSP. The engine handles the universe entirely as an octree of distorted cubes. Its still in pre-alpha, but the development lead (Aardappel) has already got another complete game engine under his belt (Cube) so it looks likely to go somewhere.

Share this post


Link to post
Share on other sites
Interesting...

I would like to further dicuss the intricacies of such a method here on gamedev.

Has anyone else done this?

Salsa cooked it, your eyes eat it!
[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak

Share this post


Link to post
Share on other sites
The hard point is how do you reduce dynamically the number of polygons ? If you have spline based geometry, you can do that because you have mathematical equation. In the other cases, there is maybe some algorithms which perform a LOD. Another thing, you cannot change the LOD of a near object ! I think LOD can be performed according to the distance between the camera and the objects, or according to the speed of the action =)

Share this post


Link to post
Share on other sites
quote:
Original post by Prozak
*bump*
anyone?



There was an article by Jonathan Blow, Inner product. Now it is online too. There he divides the level into chunks (octree..?), LOD each chunk, then generates the geometry to connect neighbour chunks (for each combination of LODs) and that''s it. Resembles geomipmapping in some way.
AFAIK there was an example with Q3 level.

Share this post


Link to post
Share on other sites
quote:
Original post by Zemedelec
quote:
Original post by Prozak
*bump*
anyone?



There was an article by Jonathan Blow, Inner product. Now it is online too. There he divides the level into chunks (octree..?), LOD each chunk, then generates the geometry to connect neighbour chunks (for each combination of LODs) and that''s it. Resembles geomipmapping in some way.
AFAIK there was an example with Q3 level.


This sounds a lot like Chunked LOD (Ulrich Thatcher)

Share this post


Link to post
Share on other sites
quote:
Original post by WhileTrue
This sounds a lot like Chunked LOD (Ulrich Thatcher)


...since it uses space partitioning + LOD?
First, there is octree instead of quadtree, LOD is run over general geometry, and holes between LODs are solved properly.
And no morphing, so far.
Well, maybe it is something similar.

Share this post


Link to post
Share on other sites
For this LOD thing, if you're just rendering a heightmap from a square bitmap image, would it be feasible to just render octree nodes that point to either up close, mid-range or far-range versions of each section and build three separate octrees on startup? Any ideas? I just started thinking about this when I saw this thread so I don't know if I'm insane or not, because the first time I learned of LOD was about 15 minutes ago looking at a freakin picture :-\

[edited by - uber_n00b on June 1, 2004 2:17:03 PM]

Share this post


Link to post
Share on other sites