Questions about moving objects and quadtrees

In my implementation, I found that rebuilding the quadtree every cycle worked just fine. That is, rebuilding the entire tree is relatively fast compared to the subsequent collission search logic (it tracks about a thousand or so items). I'm sure I could optimize the quadtree by incremental updates, as the objects move relatively slowly. But the algorithm would get far more complex, so I'm not doing it until I really have to.

Yeah I guess because it's faster quite a bit, since 10 objects would be 10^2 checks 50 would be 2500 checks D: rebuilding doesn't seem too intensive when you put it in that perspective.

Yes, rebuilding takes N log N which is far faster than N^2. But what I meant was comparing it with the collission search. Iterating each item and looking for others within a certain radius also takes N log N. So the conclusion is that the incremental version is of the same order compared to the non-incremental one. Making the optimization *can* be worthwhile, but as always, you should measure first.

[edit]

PS. Making the optimization would actually be an excellent educational excersize. If you do, make sure to measure performance before and after.

"Loose" octrees as described by Thatcher Ulrich might be something that's interesting for you if you're doing this for educational purposes (note: octree is the same as quadtree, just with one more dimension).

But for something that "just works" for reasonable numbers, I agree with Felix Ungman, nothing wrong with just rebuilding the tree, and it's nice and easy.

Also not ussing a quadtree at all is probably even faster :p. I don't get why everyone instantly jumps to quad trees for broad phase collision detection. Just grids/cell lists are often easier to implement AND perform better. Especially in the asteroids case where the domain is limited.

Why do you need to rebuild the quadtree ? I mean, it sounds that you are clearing and inserting all the objects when updating?

It is perfectly fine to just update the nodes which are affected by the moving objects.

I'm using a loose octree for a 3d world and I have no performance problems with 200-300 moving objects. Of course there are some possibilities for optimizing such as "if object is inside the same octree node as it was before moving, no update is necessary".

Probably for a limited play area game a grid based solution will be easier to implement and it'll perform better.

Cheers!

In a space partitioning structure, for either collision checking or graphic optimization (or both), you have two kinds of objects, mobile and static.
The proportions of the population will change depending on the game itself, some will have just a few mobile and tons of statics and some may have truckloads of mobiles and just a few statics.

How you update your space partitioning structurte will likely be driven by these characteristics, in games with mostly static content the best approach is to keep the structure stored for the statics and have the mobiles update their position in the structure, if your object knows which node of the structure it is stored in, you could trigger the reevaluation of the object from that node, make a check for containment, if its contained check child nodes, if its intersected by the node boundaries or has no overlapping at al move it up the hierarchy and re check.

If you have more mobile entities than static, a full recalculation may be the best approach, though in these cases, like bullet hell games, entirely different techniques than space partitioning are usually more effective.

If its an entirely learning experience, try to abstract yourself of the quadtree, the octree, the bsp or any specific structure and try to think of a system that would allow you to use any of these and even combine them, what is a space partitioning structure? what do they all have in common? its a node structure with space containing boundaries and a hierarchy where all nodes are fully contained by their parent.
Think of special cases that would still qualify, for instance, this one is assumed invalid by many people not familiar with these structures, the only rule is that the child node is fully contained by the parent, it doesn't say nor there is any reason why it wouldn't be valid, that the child nodes must not overlap each other, which could solve the horribly annoying defect that if an object is on the exact center of a quadtree, it can only be stored on the root node regardless of how small the object may be.

You could for instance, have a quadtree that stores an exterior, open world, in which there is somewhere a large building, the building will have its own space partitioning structure for the objects inside it, this structure can be a sub node of the quadtree node in which the building is located. The inside of the building may best be represented by a graph of rooms and the conent of those rooms may best be repesented by a BSP, which would be a sub node of the graph node for that room.
If you design your classes and system well, this should be entirely possible and efficient.