Octree + Moving objects...?
Hi!
I'm implementing my first shot at octree's, and it's going great with static objects... Basically I've divided each cell into eight new, and if a cell isn't occupied with an object it will be erased - no need to check empty cells!
This causes a big headache for objects that can move thou... since they might move into a cell that doesn't "exist"...?
How is this handled normally? Should I avoid having a octree that isn't uniformly divided and simply divide ALL cells...?
Cheers!
How do you decide when a cell is to be divided? When it contains more than one element? Until it reaches a certain depth?
I made a dynamic octree before, but it took a lot of work. I plan to use it for future projects.
I found that dividing cells when they have more than X entities inside them, and recombining cells when they have less than Y entities, was most efficient. When I divided a cell I created all 8 sub-cells. This way, the entire space in the simulation is divided into existing cells.
So there are many different sized cells, depending on how populated the nearby area is.
When an entity moves, it usually stays within the same cell. If it moves to a different cell, the model above says that it moves into an existing cell.
There is lots of creating and deleting nodes, lots of dynamic allocation. I played around with randomly moving objects, and decided that splitting when a cell had 16 entities, and recombining when it had less than 8 worked well. (X = 16, Y = 8).
Of course, these factors depend on how you use your Octree. If you're using it to decide on what objects to draw per frame, it's pretty quick to check whether an entity might be visible on screen.
Not sure how much sense that makes, hope it helps.
I made a dynamic octree before, but it took a lot of work. I plan to use it for future projects.
I found that dividing cells when they have more than X entities inside them, and recombining cells when they have less than Y entities, was most efficient. When I divided a cell I created all 8 sub-cells. This way, the entire space in the simulation is divided into existing cells.
So there are many different sized cells, depending on how populated the nearby area is.
When an entity moves, it usually stays within the same cell. If it moves to a different cell, the model above says that it moves into an existing cell.
There is lots of creating and deleting nodes, lots of dynamic allocation. I played around with randomly moving objects, and decided that splitting when a cell had 16 entities, and recombining when it had less than 8 worked well. (X = 16, Y = 8).
Of course, these factors depend on how you use your Octree. If you're using it to decide on what objects to draw per frame, it's pretty quick to check whether an entity might be visible on screen.
Not sure how much sense that makes, hope it helps.
Currently I'm dividing as long as an entity can fit inside a cell's children.
But I've got a limit of 5-6 divisions, this allows me to use a 2x2x2 "meter" precision.
So basically: Should I do changes to the number of cells during run-time...?
Wouldn't this perform worse than using a fixed number of cells?
The problem with using a fixed number is that the program will probably spend a lot of time looping through empty cells... :/
I plan on using my octree for pathfinding (location of nearby nodes), collision detection and for rendering.
But I've got a limit of 5-6 divisions, this allows me to use a 2x2x2 "meter" precision.
So basically: Should I do changes to the number of cells during run-time...?
Wouldn't this perform worse than using a fixed number of cells?
The problem with using a fixed number is that the program will probably spend a lot of time looping through empty cells... :/
I plan on using my octree for pathfinding (location of nearby nodes), collision detection and for rendering.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement