[quote name='Vereor' timestamp='1310030946' post='4832183']Traversing the octree to the players depth, and collecting a list of potentially visible octree nodes along the way, doesn't satisfy my above requirement as very far away objects (planets) will not necessarily be in that traversal path

I don't quite understand this. Usually when you traverse an oct-tree, you visit all 8 children of a node, provided that they are visible, and repeat. So starting at the root, visiting it's 8 children, and their 8 (times 8) children, and so on, performing a visibility test for each node, how do some 'visible' nodes not end up being visited? Can you explain this part of the problem?
[/quote]

>Usually when you traverse an oct-tree, you visit all 8 children of a node

Well, apparently it is not necessarily for the ray-octree-traversal since ray may cross some subset of 8 sub-volumes so no need to validate all 8 of them. If you just scan octree (to find min,max, to update octree etc...) then it makes sense to look through all 8 sub-volumes.

Stefan

Not sure who is who here? stefanbanev == vereor ? At any rate, OP suggests a depth of 27, which would mean the number of nodes in the octree would be in excess of 8^27 power, which I wont bother to write out. Vereor, I think you might want to lay out what you want and see which techniques line up and their implications.

For example, if you want to display a large area from a zoomed out view, you couldn't hold everything in ram because the costs would far exceed your available memory. As a person zooms out, objects from the scene should be removed, and as a person zooms in, the opposite should happen. So, your scene would need to be dynamic, loading objects as they come into view and then discarding them after some viewing threshold. Octrees and other tree type structures are used alot in many video games, but they generally only complicate things, not make then easier.
The point of a spacial tree such as an octree is simple, right? It divides the visible area into neat chunks, it sure sounds good to me --I like organization. But, whats the point? What I mean is, what does this give you? How does this make your job easier? I have seen many people want to use a spacial tree just because they thought it would benefit them to divide their world up --and everyone else does it, right? I thought the same and wrote an octree that has extremly fast find/insert/remove, but i stopped writing the code after seeing it just complicated everything.
Could you use a quadtree? Or make up a different type of way to divide your viewing area?

If you allow zooming in and out perhaps there can be fixed zoom distances. For example, if a person hits the zoom out, it will zoom out to the solar system view, if he or she hits zoom in again, it would zoom in close to an orbital view of a planet. If a person zooms out of the solar system, it would show the galaxy. In this manner you could manage the number of objects in the scene and provide yourself some consistency --and an easier job programming.

> [color=#1C2837][size=2]At any rate, OP suggests a depth of 27, which would mean the number
[color=#1C2837][size=2]> of nodes in the octree would be in excess of 8^27 power,
[color=#1C2837][size=2]> which I wont bother to write out.
[color="#1c2837"]

[color="#1c2837"]For such sparsely populated volume as space 99.99% of volume is empty the number of leafs is very low.
[color="#1c2837"]

[color="#1c2837"]However, 27 levels are not enough to represent solar system if lowest level represent 0.1km then 44 light-second volume can be indexed (8 light-minutes is the distance from Earth to Sun), besides the diff data structures for diff levels are advisable (see my post above).
[color="#1c2837"]

[color="#1c2837"]Stefan
[color="#1c2837"]