• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
EternityZA

Oclusion testing in a FPS

12 posts in this topic

HI.

Im working on a FPS using my own engine. I allready subdivide the map and use frustum culling to greatly reduce the amount of geometry i draw but its not enough it seems. When im standing on the outskirts of the map looking into it the frame rate drops even though im in a small little room and im staring at a wall. Im a little unsure of how to go about implementing oclusion testing in a FPS.Testing all the ojects against all the other objects that might be infront of it seems way too expensive. Im guessing I might have to do something like set up volumes and link objects to them. Like if the player is in volume X only objects a,b and c could possibly be vissible to him. (objects a,b and c being stationary. Like walls) or something like that. I could create a script to create these volumes on the maps and store it in the map files so the game doesnt need to do it. Does this sound like a feasible idea? or is there maybe a better solution that im missing.

Thnx in Advance!
0

Share this post


Link to post
Share on other sites
[url="http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html"]http://http.develope...ugems_ch29.html[/url]
That's what I used and it worked great for my purposes.

I'm pretty sure there are loads of improvements you can do to it to make it work better for your particular purposes, like bunching close objects together when querying, and other tricks that take advantage of the overall designs of your maps.

However, note that I'm that sure there are plenty of data structures better suited for rough occlusion culling for FPSes than occlusion testing all objects I'm pretty sure, but it kind of depends on your ambition.
0

Share this post


Link to post
Share on other sites
You can use portal culling. Basically, Split the world up in zones connected by portals. when rendering a zone check all portals that lead to different zones for visibility and include those zones in the rendering.
0

Share this post


Link to post
Share on other sites
what I am experimenting with at the moment is as follows:

define a number of objects that can act as occluders (large in occlusion value, walls, boxes, simple buildings and low in poly count)

then for each frame grab the nearest 5 to 50 to ? of them depending on horse power, render those to a small buffer on the cpu.

next step is to test bounding boxes against this buffer, not the bb for every object but bb's from either a spatial structure or a custom set, you could divide your scene into a grid.

that way if you have some dense areas containing a large number of small objects or a large number of polygons, they can be culled away very quickly

it is by no means perfect occlusion culling but it is instant and gets a good ratio culled, so might work out for you.... if you have a massive open space with only small occluders it probably will not work so well.

(if you have raised terrain you can just plant in some planes that run along under any ridges and then you can really quickly (after drawing a few simple polys on the cpu) you can cull away objects on the other side of raised terrain pretty easily)

make sense?
0

Share this post


Link to post
Share on other sites
if anyone wants I can pop a demo or two online so you can see it in action.
i.e. a simplified 3D scene with some occluders and occludees with the occlusion map rendered in a smaller window
0

Share this post


Link to post
Share on other sites
Right, I quickly through this together so bare with me.

[url="http://bwhiting.co.uk/b3d/occlusion/"]http://bwhiting.co.uk/b3d/occlusion/[/url] <-- demo app here (will need flash player 11.1 - [url="http://get.adobe.com/flashplayer/"]http://get.adobe.com/flashplayer/[/url] )

What you will see (after a small wait while it loads)... is a simple terrain model with some boxes on it.
The boxes represent areas that will contain some complex data. i.e. a high poly model or 2 or 50 or whatever
The boxes will dissapear as soon as the high poly models are loaded in (in our case a lovely t-rex model)

The boxes are then occlusion tested against some predefined geometry that mimics some sections of the terrain.

You can see this in real time in the bottom left hand side of the screen where the occlusion buffer is rendered for your convenience as well as some dots representing the success/failure of bounding box occlusion queries.

As you can see, from some angles you can cut down the number of polygons sent to the GPU massively (from 3 million polys down to a few hundred thousand)
This was a super quick test just to try out an idea, it is not optimised and could run a great deal faster but you should get the idea.

If anyone is interested in the implementation details I could do a thorough write-up explaining how it all works.
0

Share this post


Link to post
Share on other sites
[quote name='bwhiting' timestamp='1327596952' post='4906461']
[url="http://bwhiting.co.uk/b3d/occlusion/"]http://bwhiting.co.uk/b3d/occlusion/[/url] <-- demo app here (will need flash player 11.1 - [url="http://get.adobe.com/flashplayer/"]http://get.adobe.com/flashplayer/[/url] )
[/quote]

added some statistics in there - the green stuff [img]http://public.gamedev.net//public/style_emoticons/default/rolleyes.gif[/img]
0

Share this post


Link to post
Share on other sites
This actually looks pretty neat for static terrain, although certain dynamic elements wouldn't be too hard to add. A more interesting thing to see would be a fast heuristic occluder calculator that would build the occlusion faces. The fastest I can think of is probably periodic sampling for the entire terrain in both directions and using regular occlusion query techniques to optimize fillrate. I can't see much use for this in a closed environment, though.
0

Share this post


Link to post
Share on other sites
Outside your terrain is rarely this largely varying. There may be some large hills but they are often in the distance and you are in a large open area with very expensive things to draw. :(

Areas with tall occlusions of interior walls or buildings would be the best place to apply this technology.
It really all depends on your scene. Unfortunately our game has equal of both.
0

Share this post


Link to post
Share on other sites
I agree my terrain was perhaps not the best example but even very small hills could hide anything from a tank to a whole city depending on the view so could save some serious rendering time, especially if the occluder is only rendered when the player is near enough to it (i.e. if no occluders nearby then non are rendered and 0 time is lost)

With regards to generating a low poly occlusion mesh, when i threw that terrain together in max, a plane with a much lower resolution (10x10 as opposed to 50x50) was used with the same displacement map and slightly tweaked values...and it generated a really good mesh! BUT! because it was an organic mesh, not a plane or box, it either needed to be z sorted or drawn with a z-buffer... which would slow things down considerably. At the moment no z-buffer is used when drawing the occluders.

The same thing should also be able to work just fine indoors too, just grad the nearest few walls and use them. that way if you indoor level could be divided into chunks, whole segments could be disregarded pretty quickly..

Have put together a few other scenes, and will make 2 more demos on Monday and upload them, this time there will be some dynamic objects and a better test environment (I hope... two hills, a tunnel, a room*, and a building**)

** a box
* an open box
:)
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0