hello
I'd like to create a game that looks like aquanox (terrain based, more static objects than moving ones but the vessels can be very big -> lot of occlusion). For the moment, I'm only interested in the geometry handling, not the rendering.
My question is, what are the state of the art methods for visibility and occlusion detection in such "outdoor" engine ?
My first idea was to use octrees for space partionning and a method similar to the one on Gamasutra, "Fast Occlusion Culling for Outdoor Environments", where the author creates a frustum and use bounding spheres for trivial rejection and then bounding boxes if the sphere is half inside the frustum. I think there will be a lot of occlusion, the fight can be close to big vessels. Is there anything better (I'm sure there is or more adapted for the hardware pipeline (I'm using DirectX) ?
[edited by - bashung on September 3, 2003 9:21:30 AM]
You don''t like aquanox or is it the wrong forum ? I know there have been a lot of questions about occlusion but I''m interested in an implementation that is specially suited for large occlusions frustum (ie. lot of small objects hidden by a large one), that''s what is happening most of the time in aquanox.
There is no occlusion done against vessels, only the terrain. To "obscure" that, engines of this type usually do 3-part rendering...
1) Non-translucent (no alpha) Dynamic and Static Objects, in Near-To-Far order (by objects, polys are handled in hardware) 2) Terrain, with occlusion against only terrain 3) Translucent objects and particles, in Far-to-Near order
At all times, Z-write and Z-test is enabled. And a Zbuffer clear (or possibly reversal) is performed before each frame is rendered. Lighting only need be enabled for the first two stages, and you can probably pre-render and run-time lightmap the second stage anyway.
This way, very few pixels are double-rendered in the first two stages, and everything is drawn and waiting by the time the translucency kicks in.
Now, what does this have to do with geometry handling? Well, you don''t need to occlude terrain or ships because a big ship is in the way. Especially considering the odd shape of ships, this would be just too much overhead. Instead, let the rendering system battle it out, because it can do this per-pixel far faster than you can per-quadtree-node.
RIP GameDev.net: launched 2 unusably-broken forum engines in as many years, and now has ceased operating as a forum at all, happy to remain naught but an advertising platform with an attached social media presense, headed by a staff who by their own admission have no idea what their userbase wants or expects.Here's to the good times; shame they exist in the past.
Thanks for your answer, if I understand there''s a tradeoff between CPU and GPU z-buffering. I thought that when half of the screen is filled with a big vessel, it would be a lot of waste to render all the hidden moving objects (that could be quite big as well) and better to remove geometry with some node checking.
I wanted to discard most hidden objects for another reason. The occlusion information could be used to know which enemies are visible and perform some computation (distance between my vessel and the enemies -> is a guided-missile able to "keep" it and get there, what path,...), for collisions too. The less I have to compute that, the best.
My question is, what are the state of the art methods for visibility and occlusion detection in such "outdoor" engine ?
My first idea was to use octrees for space partionning and a method similar to the one on Gamasutra, "Fast Occlusion Culling for Outdoor Environments", where the author creates a frustum and use bounding spheres for trivial rejection and then bounding boxes if the sphere is half inside the frustum. I think there will be a lot of occlusion, the fight can be close to big vessels. Is there anything better (I'm sure there is 
or more adapted for the hardware pipeline (I'm using DirectX) ?
[edited by - bashung on September 3, 2003 9:21:30 AM]
