Quote:
Originally Posted by narcberry
Why do it as a tree? Wouldn't it be much faster to hold the water/lava data as a 3d matrix that is quickly addressable by map position (each matrix entry representing a block of size x)? You should be able to entirely avoid the tree traversal that way. It should also reduce the size of your data (but just slightly).
Sorry if I misunderstand the problem.
|
This is how the EQ zone geometry is stored in the zone S3D files that come with the client. You sound like you know a lot more about 3D geometry than me, but there is an article over at Wikipedia explaining why BSP trees are used in 3D games (more for rendering and stuff):
http://en.wikipedia.org/wiki/Binary_space_partitioning
I just extracted the relevant bits of data in the same tree format it was organised in the zone files. I'm sure it could be optimised just for the purposes of water detection, but once I get something that 'works' for me, my interest kinda stops there
