Using Rendering Pipeline to calculate Fog of War

I am working on a top down strategy game (the player controls a number of units).

One thing I am trying to do is give each unit a view Frustum.

Hence you can only see an enemy unit if it’s in the view of one of your units.

I want the visibility calculation to take obstacles and terrain into account (if something is in the way, your unit can’t see the enemy unit).

Q1)  Does the following approach make sense (best approach / flaws?):

Build 2 scenes (two root nodes).

The first (Complete) scene has the entire world as it really is.

The second (Local) scene has the world minus all enemy units.

I will use the “Complete” scene to calculate which enemy units are visible ** then add these units to the “Local” scene.

Next position the camera above an area of the Local scene and render it to the player.

Q2) Can I use the rendering pipeline to calculate visibility.

Per question 1 I need to know which enemy units a friendly unit can see.

I don’t need to do a full render just calculate if the enemy is in the view Frustum and if there is anything blocking (possibly partially blocking) the view.

This logic appears to be the same as the graphics pipeline used for doing the main render, so:

  • Can I reuse some of the graphics pipeline?
  • Does it make sense to do this (is it overkill)?

    Q3) Optimizations

    Because it is a strat I am thinking about implementing a grid system, both for the terrain and for placing units.

    If I was to do this are there any other optimizations I can make ?

    For example I could model the “complete”  scene using only cubes (each grid location is either occupied or it isn’t).

    How much would this help with performance ?


I think you might be able to make that work, but I doubt it would be a very effecient way of doing it.

Creating a complex scene twice will give you that much extra geometry, transforms etc. to update.

One of the major reasons you won't be able to see something in that sort of game is because it is beind something else, and normal rendering dosn't do a lot to figure that out - it just draws it all. Also, you probably don't need pixel-perfect calculation of what your units can or can't see - the player won't be able to judge it that accurately anyway.

Your cube idea is closer to what I would do, but I wouldn't bother with 3D geometry at all. Maybe just create a 2D grid based map. For each grid square you could store if it blocks line of sight or not. Given a position, facing and field of view you can easily decide which squares are visible. Work out from the viewer, check if this square blocks LOS. If so, flag it. Then flag all squares further out that it blocks from the viewer. Cycle through all squares, ignoring those already flagged. When you're done, any units in squares still unflagged are visible.

This process should have a really low performance overhead and work quite well.

That would be quite crude but probably as effective as many strategy games out there have. To make it a bit better you could store the height to which a square blocks LOS - that would allow the possibility that large or flying units can still be seen where ground units below them are hidden.