• Create Account

### #Actuallawnjelly

Posted 15 April 2012 - 09:36 AM

Yeah, sorry that's posting when tired lol.

Sure to do it you have to partition space into something reasonable memory wise. Whether you can use your grid directly depends how big your maps are. Your screen there looks to be about 20x20 so let's use that for an example:

20x20 = 400 bits per grid square for a naive PVS = 50 bytes

then 50 bytes x 400 grid squares = 20000 bytes, so under 20K, so not that memory hungry.

That's very naive though .. you can also cut this by half if your PVS is reciprocal (i.e. if you can't see 40,40 from 20, 20, then you also know that you can't see 20, 20 from 40,40)

You could also use RLE if memory really was a problem (although the cost of decompressing this probably wouldn't be worth it unless you have a complex environment lol).

Then other ways is to use different partitioning for your space. If for example you used a 10x10 grid for the PVS instead of 20x20, that quarters the memory size. Or use a 2d BSP tree maybe, not sure. Grid sounds more tempting, if you keep it small.

As to how to handle the case of tanks being in different 'parts' of the gridsquare, and the visibility being 1 in some parts and 0 in others, just mark it as invisible ONLY when there are no parts of the grid squares that are visible to each other.

Then if it is marked as potentially visible, do a runtime check. For enemy AI often you can afford to be lazy about this, and there's no reason you need to do vis checks every frame. You could also store 3 (or 4) states in the PVS, instead of just 2 - i.e. definitely not visible, maybe visible, definitely visible, that way you only have to do runtime checks in say 2% of the grid squares.

Given that your current grid is only using 20K, I'd be tempted to just increase the resolution of the PVS grid by about 5x and then just go with the definitely visible / definitely invisible approach, and forego the accuracy.

For a BSP tree you may be able to be more exact than this.

You don't even need to use a BSP tree .. you could use something as simple as AA bounding boxes and probably still get a decent result, the only limit is your imagination!

And this is pretty much one of the simplest situations for using a PVS. There are some really good solutions in 3d for far more complex environments (see quake stuff using BSP and PVS, or portal engines, etc etc). If you do some googling you should get some good ideas.

### #4lawnjelly

Posted 15 April 2012 - 09:29 AM

Yeah, sorry that's posting when tired lol.

Sure to do it you have to partition space into something reasonable memory wise. Whether you can use your grid directly depends how big your maps are. Your screen there looks to be about 20x20 so let's use that for an example:

20x20 = 400 bits per grid square for a naive PVS = 50 bytes

then 50 bytes x 400 grid squares = 20000 bytes, so under 20K.

That's very naive though .. you can also cut this by half if your PVS is reciprocal (i.e. if you can't see 40,40 from 20, 20, then you also know that you can't see 20, 20 from 40,40)

You could also use RLE (although the cost of decompressing this probably wouldn't be worth it unless you have a complex environment lol).

Then other ways is to use different partitioning for your space. You could use a 10x10 grid for the PVS instead of 20x20, that quarters the size. Or use a 2d BSP tree maybe, not sure. Grid sounds more tempting, if you keep it small.

As to how to handle the case of tanks being in different 'parts' of the gridsquare, and the visibility being 1 in some parts and 0 in others, just mark it as invisible ONLY when there are no parts of the grid squares that are visible to each other.

Then if it is marked as potentially visible, do a runtime check. For enemy AI often you can afford to be lazy about this, and there's no reason you need to do vis checks every frame. You could also store 3 (or 4) states in the PVS, instead of just 2 - i.e. definitely not visible, maybe visible, definitely visible, that way you only have to do runtime checks in say 2% of the grid squares.

For a BSP tree you may be able to be more exact than this.

You don't even need to use a BSP tree .. you could use something as simple as AA bounding boxes and probably still get a decent result, the only limit is your imagination!

And this is pretty much one of the simplest situations for using a PVS. There are some really good solutions in 3d for far more complex environments (see quake stuff using BSP and PVS, or portal engines, etc etc). If you do some googling you should get some good ideas.

### #3lawnjelly

Posted 15 April 2012 - 04:40 AM

Yeah, sorry that's posting when tired lol.

Sure to do it you have to partition space into something reasonable memory wise. Whether you can use your grid directly depends how big your maps are. Your screen there looks to be about 20x20 so let's use that for an example:

20x20 = 400 bits per grid square for a naive PVS = 50 bytes

then 50 bytes x 400 grid squares = 20000 bytes, so under 20 megs.

That's very naive though .. you can also cut this by half if your PVS is reciprocal (i.e. if you can't see 40,40 from 20, 20, then you also know that you can't see 20, 20 from 40,40)

You could also use RLE (although the cost of decompressing this probably wouldn't be worth it unless you have a complex environment lol).

Then other ways is to use different partitioning for your space. You could use a 10x10 grid for the PVS instead of 20x20, that quarters the size. Or use a 2d BSP tree maybe, not sure. Grid sounds more tempting, if you keep it small.

As to how to handle the case of tanks being in different 'parts' of the gridsquare, and the visibility being 1 in some parts and 0 in others, just mark it as invisible ONLY when there are no parts of the grid squares that are visible to each other.

Then if it is marked as potentially visible, do a runtime check. For enemy AI often you can afford to be lazy about this, and there's no reason you need to do vis checks every frame. You could also store 3 (or 4) states in the PVS, instead of just 2 - i.e. definitely not visible, maybe visible, definitely visible, that way you only have to do runtime checks in say 2% of the grid squares.

For a BSP tree you may be able to be more exact than this.

You don't even need to use a BSP tree .. you could use something as simple as AA bounding boxes and probably still get a decent result, the only limit is your imagination!

And this is pretty much one of the simplest situations for using a PVS. There are some really good solutions in 3d for far more complex environments (see quake stuff using BSP and PVS, or portal engines, etc etc). If you do some googling you should get some good ideas.

### #2lawnjelly

Posted 15 April 2012 - 04:36 AM

Yeah, sorry that's posting when tired lol.

Sure to do it you have to partition space into something reasonable memory wise. Whether you can use your grid directly depends how big your maps are. Your screen there looks to be about 20x20 so let's use that for an example:

20x20 = 400 bits per grid square for a naive PVS = 50 bytes

then 50 bytes x 400 grid squares = 20000 bytes, so under 20 megs.

That's very naive though .. you can also cut this by half if your PVS is reciprocal (i.e. if you can't see 40,40 from 20, 20, then you also know that you can't see 20, 20 from 40,40)

You could also use RLE (although the cost of decompressing this probably wouldn't be worth it unless you have a complex environment lol).

Then other ways is to use different partitioning for your space. You could use a 10x10 grid for the PVS instead of 20x20, that quarters the size. Or use a 2d BSP tree maybe, not sure. Grid sounds more tempting, if you keep it small.

As to how to handle the case of tanks being in different 'parts' of the gridsquare, and the visibility being 1 in some parts and 0 in others, just mark it as invisible ONLY when there are no parts of the grid squares that are visible to each other.

Then if it is marked as potentially visible, do a runtime check. For enemy AI often you can afford to be lazy about this, and there's no reason you need to do vis checks every frame.

For a BSP tree you may be able to be more exact than this.

You don't even need to use a BSP tree .. you could use something as simple as AA bounding boxes and probably still get a decent result, the only limit is your imagination!

And this is pretty much one of the simplest situations for using a PVS. There are some really good solutions in 3d for far more complex environments (see quake stuff using BSP and PVS, or portal engines, etc etc). If you do some googling you should get some good ideas.

### #1lawnjelly

Posted 15 April 2012 - 04:19 AM

Yeah, sorry that's posting when tired lol.

Sure to do it you have to partition space into something reasonable memory wise. Whether you can use your grid directly depends how big your maps are. Your screen there looks to be about 20x20 so let's use that for an example:

20x20 = 400 bits per grid square for a naive PVS = 50 bytes

then 50 bytes x 400 grid squares = 20000 bytes, so under 20 megs.

That's very naive though .. you can also cut this by half if your PVS is reciprocal (i.e. if you can't see 40,40 from 20, 20, then you also know that you can't see 20, 20 from 40,40)

You could also use RLE (although the cost of decompressing this probably wouldn't be worth it unless you have a complex environment lol).

Then other ways is to use different partitioning for your space. You could use a 10x10 grid for the PVS instead of 20x20, that quarters the size. Or use a 2d BSP tree, which is probably the best way of doing it.

As to how to handle the case of tanks being in different 'parts' of the gridsquare, and the visibility being 1 in some parts and 0 in others, just mark it as invisible ONLY when there are no parts of the grid squares that are visible to each other.

Then if it is marked as visible, do a runtime check. For enemy AI often you can afford to be lazy about this, and there's no reason you need to do vis checks every frame.

For a BSP tree you can be more exact than this and you can pretty much predetermine it exactly save for the dynamic objects.

You don't even need to use a BSP tree .. you could use something as simple as AA bounding boxes and probably still get a decent result, the only limit is your imagination!

And this is pretty much one of the simplest situations for using a PVS. There are some really good solutions in 3d for far more complex environments (see quake stuff using BSP and PVS, or portal engines, etc etc). If you do some googling you should get some good ideas.

PARTNERS