I currently have 2 octrees that work on the server, one for calculating the potentially visible set (PVS) that stores meshes and a finer grained one for physics that stores 'collides'.
Then on the client there is one for determining the currently visible set.

Does this make sense? The server has to relink objects to two separate octrees all the time and so has to traverse through them twice as much.
Also, if you are playing a singleplayer game that's 3 octress you're dealing with.

Any advice here? On cutting down the time spent on relinking and octree traversal?

[color=#1C2837][size=2]

I currently have 2 octrees that work on the server, one for calculating the potentially visible set (PVS) that stores meshes and a finer grained one for physics that stores 'collides'.[/quote]
[color=#1C2837][size=2]

[color=#1C2837][size=2]Is there any reason why you can't use the same tree for both? You can have a very fine grained octree for physics and just not traverse it all the way down when you are determining PVS. Are the trees the 'same' except for depth, or are the splits in completely different places?

[color="#1C2837"]

I currently have 2 octrees that work on the server, one for calculating the potentially visible set (PVS) that stores meshes and a finer grained one for physics that stores 'collides'.

[color="#1C2837"]Is there any reason why you can't use the same tree for both? You can have a very fine grained octree for physics and just not traverse it all the way down when you are determining PVS. Are the trees the 'same' except for depth, or are the splits in completely different places?
[/quote]

This is what I was just thinking... Probably the best option. But I will still have to 'relink' each object twice each frame (three times since the client stores it's own octree too), once for physics and once for the mesh.

EDIT: But with some hacking it could be faster, if you relink both at the same time. Find the depth for pvs and link the mesh there and keep going down till you hit the bottom for physics.