Scene Management Question.
Author
Im at the stage in my engine where I need to implement some type of scene management algo. My engine is a 3D engine but the game itself is a 2D game but in 3D (think civ3 in 3D). so there will be terrain and models all over with a top-dow / isometric view. Im wondering what type of scene management would be nice for such a game.
Currently Im thinking of doing a simple Frustrum Culling Test that checks to see if the object's bounding sphere is inside the frustrum. This shouldnt be hard to implement, i dont believe. I dont know if OctTrees or Quad Trees are worth while for this game...they might be overkill?
Whats your opinion??
EDIT: I did take a look at the Occlusion Culling Using DirectX 9 Article and it peeked my interest.
What sort of numbers and technology are we looking at?
You trying to push the upper limits of hardware (1000's of models all with shaders and funky effects?!) or are you aiming a bit lower down?
Scene management is essential if you want efficiency, but if you're not looking to push the upper limits you can slack off a little if you have to. But, note that a generally efficient engine targetting low-to-mid hardware will still benefit as it means you'll be able to run on more slower/worse hardware...
Anyway, for terrain it wont take much work to create a stupidly powerful renderer that is both beautiful looking and exceptionally efficient. Quadtrees and optimized index buffers are the way forward here - neither being more than a day (or two) of work.
Implementing quadtree's into your frustum culling algorithm (I'm a fan of a simple Cohen-Sutherland 6-bit plane test) isn't too hard - its more a case of designing your data structures so that the code is simple and straight forward. The algorithm itself isn't really that difficult.
Once you've got quadtree's you can look at attaching a subset of a large IB/VB pair to each node (think in terms of DrawIndexedPrimivive()) parameters. Also, unless you're dealing with HUGE terrains a bit of data-duplication won't hurt your memory requirements but can reduce the number of draw calls (which gives better performance) [wink]
As for the models on the terrain - difficult to say for sure. Some sort of simple state management and re-ordering algorithm (e.g. batching based on state changes) is a definite good move, but thats largely dependent on the details of what you're rendering...
Also - final tip - PROFILE PROFILE PROFILE! [grin] Once you move onto making these sorts of changes you want to know exactly what sort of trade-off (good or bad) that your changes are making to the performance characteristics of the application.
hth
Jack
You trying to push the upper limits of hardware (1000's of models all with shaders and funky effects?!) or are you aiming a bit lower down?
Scene management is essential if you want efficiency, but if you're not looking to push the upper limits you can slack off a little if you have to. But, note that a generally efficient engine targetting low-to-mid hardware will still benefit as it means you'll be able to run on more slower/worse hardware...
Anyway, for terrain it wont take much work to create a stupidly powerful renderer that is both beautiful looking and exceptionally efficient. Quadtrees and optimized index buffers are the way forward here - neither being more than a day (or two) of work.
Implementing quadtree's into your frustum culling algorithm (I'm a fan of a simple Cohen-Sutherland 6-bit plane test) isn't too hard - its more a case of designing your data structures so that the code is simple and straight forward. The algorithm itself isn't really that difficult.
Once you've got quadtree's you can look at attaching a subset of a large IB/VB pair to each node (think in terms of DrawIndexedPrimivive()) parameters. Also, unless you're dealing with HUGE terrains a bit of data-duplication won't hurt your memory requirements but can reduce the number of draw calls (which gives better performance) [wink]
As for the models on the terrain - difficult to say for sure. Some sort of simple state management and re-ordering algorithm (e.g. batching based on state changes) is a definite good move, but thats largely dependent on the details of what you're rendering...
Also - final tip - PROFILE PROFILE PROFILE! [grin] Once you move onto making these sorts of changes you want to know exactly what sort of trade-off (good or bad) that your changes are making to the performance characteristics of the application.
hth
Jack
Author
Well the game itself will probably have about 100-300 models on the screen (most likely using some sort of instancing), plus lights, particle effects, and terrain. I guess I can use quadtrees for the terrain, although the terrain is going to be very small. Ill definately use the 6-plane test for figuring out which model to draw and when. Although thats a bit resource intensive for every frame, no??
But since the game is almost tile based in a sense, I guess having the models and the terrain inside a quad tree might be easiler to implement.
But since the game is almost tile based in a sense, I guess having the models and the terrain inside a quad tree might be easiler to implement.
Quote:EDIT: I did take a look at the Occlusion Culling Using DirectX 9 Article and it peeked my interest.I'll leave it to Dustin (circlesoft) to comment further (I believe he wrote the article you're referring to?), but suffice to say that Occlusion Queries can be very difficult to use effectively. On paper they sound amazing, in practice they're not so great. People often throw in predicated rendering using this mechanism and end up with substantially SLOWER code [lol]. Direct3D 10 should fix this I hope...
Quote:Original post by MastadexRendering small terrains via brute-force techniques isn't necessarily a bad route. I managed to get over 30 million triangles per second using a brute-force terrain rendering technique.
I guess I can use quadtrees for the terrain, although the terrain is going to be very small.
Quote:Original post by MastadexIts got a lot of opportunities for "early-out" rejections, so it shouldn't be too bad. Also, why are you checking visibility on EVERY frame?
Ill definately use the 6-plane test for figuring out which model to draw and when. Although thats a bit resource intensive for every frame, no??
A simple optimization that can be very useful is to only check visibility when you think it might have changed. Obvious cases are where the camera moves (but also consider delta evaluation methods) and/or objects move, but at a sufficiently high frame rate (say 50fps and above) you could easily get 10 or more sequential frames where nothing changes - why recompute the same results if you know the results will be the same?? [grin]
Quote:Original post by MastadexIf your models are "fixed" to the terrain then a quadtree is fine, but if they have sufficient 3D movement (e.g. flying vehicles) then an octree might give better results.
But since the game is almost tile based in a sense, I guess having the models and the terrain inside a quad tree might be easiler to implement.
hth
Jack
Author
I read through your article on brute-forcing terrain (great article btw), and ill keep this in mind if my game slows to a crawl. Im tryin to think up a way to use the queries effectively. Hmm...
Would it be faster to do an occlusion culling (from that article) using bounding boxes or checking agianst planes of the frustrum?? Im thinking frustrum...
Not every frame, most likely, like you said, whenever the camera moves or model moves. The quad tree (or some type or partitioning system) will weed out large patches of area that dont need to be rendered and will leave me with a small amount of models that need to be rendered. Then i would use the frustrum culling check on the remaining models to see if they should be rendered.
Do you think this is a good way to go?
BTW, all the models will be tied to the terrain somehow (trees, rocks, people...), so there will be no 'air-bound' objects.
[Edited by - Mastadex on June 12, 2006 3:46:08 PM]
Would it be faster to do an occlusion culling (from that article) using bounding boxes or checking agianst planes of the frustrum?? Im thinking frustrum...
Quote:Also, why are you checking visibility on EVERY frame?
Not every frame, most likely, like you said, whenever the camera moves or model moves. The quad tree (or some type or partitioning system) will weed out large patches of area that dont need to be rendered and will leave me with a small amount of models that need to be rendered. Then i would use the frustrum culling check on the remaining models to see if they should be rendered.
Do you think this is a good way to go?
BTW, all the models will be tied to the terrain somehow (trees, rocks, people...), so there will be no 'air-bound' objects.
[Edited by - Mastadex on June 12, 2006 3:46:08 PM]
The problem with occlusion queries is the delay for getting results back. It can be several frames (due to a deep pipeline) - so you'll either have to accept delayed feedback or (worst case) you stall the application until the pipeline is flushed and can return the query data. A lot of people seem to go with trivial implementations of the latter case and end up spin-waiting and completely destroying the performance with this so called "optimization" [smile]
Cheers,
Jack
Quote:Do you think this is a good way to go?Yes, that sounds reasonable to me.
Cheers,
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement