[ODE] visibility detemination?

[Kevin Reid]

Clint Brewer <clint@haptek.com> wrote:

> Kevin:
> Thanks for the code for the frustum,  exactly the sort of thing I was
> thinking about. have you used this with lots of objects in your world?
> how's it working?

I have now done some testing with a vehicle moving among 300 scattered
geoms.

My first test found that it was extremely slow even when the testing
geom's AABB was away from all of the 300 geoms.

I then optimized the program by using two separate spaces, one which
contains geoms that have bodies (so can move), and one which contains
geoms that don't. Collision testing is then done between the
non-moving-geoms and moving-geoms spaces, and within the moving-geoms
space. This change should allow O(N*M+M^2) run time instead of
O((N*M)^2) (assuming simple spaces; hash spaces would be even better).

Testing this, I found that frame rates were quite reasonable (I don't
have a precise FPS counter yet) within the 300-geoms area, and outside
that area it ran apparently as fast as without the 300 geoms.


(A relevant note: the frustum's-bounding-box geom is a very poor
approximation, as it hits many objects 'too far to the left/right' since
the box must enclose the full width of the frustum at its far edge, and
testing only against the AABB makes it worse:
  +------/\-----------+
  |     /  \          |
  |  +--     \        |
  | /|  ---    \      |
  /   |    ---   \    |
  \    |      ---  \  |
  |\    |        --- \|
  |  \   |          --/
  |    \  |         / |
  |      \ |      /   |
  |        \|   /     |
  +----------|/-------+
Also, I just realized from this that a better approach would be to set
the box to be the frustum's AABB, so the box's AABB is the frustum's
AABB.
)

-- 
Kevin Reid