Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Right now, each node of my octree contains a list<Triangle*> (pointers to mesh triangles).

So basically an octree query returns poly soup.

Sometimes I want to query the octree for entire objects however. Each Tri has a pointer to its "owner object", but should I park the object references in the same octree (ie give each node a list<GameObject*> or maintain a completely different octree altogether?

share|improve this question
up vote 2 down vote accepted

The thing is, your object octree's final structure is going to be different than your poly octree's structure, because the objects are larger than the polys in your soup. So I think it might be wise to aim for a separate octree. After all, octrees are an optimisational bit of architecture. If aiming for faster throughput, I would definitely duplicate the octree so each one fits it purpose. Space optimisation, as you know, is not usually our primary concern as game developers :)

share|improve this answer
You must not work on consoles where space is the number one limiting factor in game development. – James Sep 8 '11 at 20:20
@James a list of pointers should not be a space concern for you. – dcousens Sep 8 '11 at 23:00
@Daniel I was commenting on the last sentence. In a for instance say you have a memory tracking system that uses a pointer to track the allocations. Now suppose you see you have around 200,000 single byte allocations (was not happy when I came across this and replaced it with a pool). You now use 5 bytes of space for every 1byte allocation taking up a meg of space for those 200,000 allocations. This is a huge problem on a PSP where you have 32MB of RAM, a big chunk is reserved for OS and another for your exe leaves you around 20MB say. 1MB is gone and you have to allocate 19MB still. – James Sep 10 '11 at 0:08
In that case the cost of the list is almost the cost of the data itself, I'd visit using a different method altogether. A list of 200,000 pointers to single bytes stands out as bad design to me. – dcousens Sep 10 '11 at 0:37
That's a handheld device, not a console, in any case. And really one has to accept that the complexity of what you can construct on that device is not the same as what you can expect from a desktop or console. It may be that expecting a performant AND large voxel world there is a biting off more than you can chew. In other words, much as I'm a fan of making minimal resources work for you, something has to give. – Arcane Engineer Sep 10 '11 at 7:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.