Octrees for Collision?

General Discussion
1

I’m struggling to figure how to leverage octrees when working with a lot of collision geometry.

Essentially, I have a starmap with ~30,000 vertices (using a point primitive). Currently, I am generating a node containing a collision sphere solid at each point so I can click on stars (using a ray from the mouse).

However, now I’m trying to make names of stars display when they are within a certain range of the camera. I have methods for creating/showing/hiding star names using TextNodes, and I trigger those methods by detecting collision between a sphere near the camera and the collision solids at each star. This work swell for small distances, but if I increase the size of the camera’s collision solid much, it slows down very quickly.

So, my question is twofold:

  1. Is using a collision sphere at the camera like this a decent approach? If no, how might I approach differently?

  2. If octrees might help speed up collision detection – how might I leverage them in this case? I’ve seen the various versions of treeform’s script; however, it seems to have errors (addVertices() takes 3, 4, or 5 arguments (2 given) … ). Could someone point me at some reading or example code that might help me build a collision octree?

2

Just modify my script to take 2 parameters?

In theory it generates polygons and you would want to generates some sort of points or tiny spheres. After you do that it should work.

3

(i know this is an old post now, ahh oh well, for anyone who still reads it) couldn’t you just go through and calculate the distance between the camera and the stars? Instead of using collision solids? That seems like a lot of extra effort…

Also, since there are so many verticies, all the square roots might cause slowdown too, so maybe check out computing using fast square roots which are at least six times faster than normal square roots http://www.mactech.com/articles/mactech/Vol.14/14.01/FastSquareRootCalc/

In addition to the fast square root which uses double precision, I’m sure converting it to floating point precision would reduce clock cycle cost down to next to nothing! 8D