Results 1 to 9 of 9

Thread: Octree vs. scene tree

  1. #1
    Senior Member Regular Contributor
    Join Date
    Feb 2003
    Location
    Westerville, Oh, USA
    Posts
    201

    Octree vs. scene tree

    I'm expanding my Jupiter simulation to be a complete solar system simulation. Since the number of bodies (and thus triangles) is increasing, I'd like to employ some sort of frustum culling - an octree.

    However, the hierarchical tree I use to store and render the sun/planet/moons is somewhat orthogonal to the spatial organization of the octree. My render code traverses the solar system tree -- which starts at the sun -- and then pushes/pops the modelview matrix as it places the planets and moons. It all works nicely, but if the camera is located at Pluto I don't want to be drawing Mercury.

    My first idea is to first cull with an octree and mark each body as "visible" or not. Then, when I traverse the solar system tree, I'll merely check if the body is visible before trying to draw it.

    This seems like an awkward solution. Would a BSP-tree be better? Or is there some other structure that will allow me to maintain the hierarchical integrity of the sun/planets/moons as well as cull the frustum?

  2. #2
    Senior Member Regular Contributor
    Join Date
    Feb 2003
    Location
    Westerville, Oh, USA
    Posts
    201

    Re: Octree vs. scene tree

    Actually, when I think about it, perhaps a brute force method might not be a terrible approach as a first pass. Sun, nine planets, a handful of moons is still less than 50 objects. I could test each one of them against the view frustum prior to drawing and skip the octree. Of course, if I use a realistic number of asteroids that approach goes out the window...

  3. #3
    Senior Member Regular Contributor
    Join Date
    Dec 2002
    Location
    Poland
    Posts
    234

    Re: Octree vs. scene tree

    Hi starman!

    Originally posted by starman:
    I could test each one of them against the view frustum prior to drawing and skip the octree. Of course, if I use a realistic number of asteroids that approach goes out the window...
    IMHO the frustrum culling would be fairly enough. It depends, of course, on how complicated your objects are. You surely don't want to render a whole planet which conatains thousands of triangles if only one of them is visible, do you?
    I would go for frustrum culling since it's an easy solution and then I would try to add some LOD alogorithm to speed up your application.

    Orzech

  4. #4
    Senior Member Regular Contributor
    Join Date
    Feb 2003
    Location
    Westerville, Oh, USA
    Posts
    201

    Re: Octree vs. scene tree

    I'm using gluSphere to draw the planets and moons, so I really don't have access to the tesselated triangles.

    Now I'm reading about scene graphs. I've come across a couple different approaches: one stores geometry at every node, the other only at leaf nodes. The intermediate nodes would contain texture, lighting, transformation, and bounding volume info.

    Perhaps that's a good place to start - with a simple scene graph.

  5. #5
    Senior Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    680

    Re: Octree vs. scene tree

    I am a little astonished about so much effort for just some planets, really not very much 3d objects.. I have made the experience that if you use a tree structure for culling, to gain performance, there have to be really many many objects.. you can easily test several thousand objects witout getting really worse performance than with a tree on current hardware, I would put every planet into a display list, it should really be running fast witout any tests at all.

  6. #6
    Senior Member Regular Contributor
    Join Date
    Dec 2002
    Location
    Poland
    Posts
    234

    Re: Octree vs. scene tree

    ... and if you are using gluSphere you can easily approximate level of detail by just checking distance to a camera and drawing spheres with particular number of divisions.

  7. #7
    Senior Member Regular Contributor
    Join Date
    Feb 2003
    Location
    Westerville, Oh, USA
    Posts
    201

    Re: Octree vs. scene tree

    JanHH - That's good to hear. I'm falling into the trap I've warned others about - premature optimization! I still need to organize my scene better, but I'll leave out the frustum culling until I notice performance problems.

    Orzech - Good idea about level of detail.

  8. #8
    Member Contributor
    Join Date
    Jul 2001
    Location
    Jönköping, Sweden
    Posts
    81

    Re: Octree vs. scene tree

    I think you should do some brute culling. Check every planets bounding SPHERE against the frustum, that should be very fast. Don't bother with more advanced scene-trees yet. Just a note: if your FOV == 90 degrees, 1 unit into the screen == 1 unit left.

  9. #9
    Senior Member Regular Contributor
    Join Date
    Feb 2003
    Location
    Westerville, Oh, USA
    Posts
    201

    Re: Octree vs. scene tree

    Well, a tree is the logical data structure to organize my scene anyway: sun at the root, planets are children of sun, moons are children of planets. The world transform of the moon is the concatenation of its matrix to its ancestors: [S][P][M]. It won't be too hard to add textures and lighting to that tree.

Similar Threads

  1. octree or BSP ?
    By crischprolch in forum OpenGL ES
    Replies: 3
    Last Post: 05-15-2008, 12:24 PM
  2. Octree in CAD.
    By HanWu in forum OpenGL: General
    Replies: 1
    Last Post: 08-19-2006, 11:56 AM
  3. Scene graph Data from the tree structure
    By in forum OpenGL: Basic Coding
    Replies: 3
    Last Post: 12-05-2005, 08:45 AM
  4. octree
    By user09 in forum OpenGL: Basic Coding
    Replies: 2
    Last Post: 02-19-2003, 09:37 AM
  5. is an octree the same as a bsp?
    By grady in forum OpenGL: Advanced Coding
    Replies: 2
    Last Post: 01-07-2001, 11:24 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean