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.

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.

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.

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.