I''m about to undertake the task of writing an octree class. I do not need code (I want to learn to do it myself) but I was wondering if anybody had any ideas about the interfact of the class itself. I.E. how to set up the public procedures. I grasp the idea of how to make an octree and what all is involved, but I just need to know how to set up the class before I begin. Any ideas?

Just like a binary tree, except you will use 8 child instead of 2.

I understand this, but seeing as how I''ve never used one before, I''m kind of stumped as to what the class interface should look like. Do I feed all the vertexes into the octree and divide them up and then draw them from there? I wanted to know if anybody had some sample of how the class would be setup.

Thanks

forgive my inexperience...
what are octrees used for?
maps with tiles?

---

There aren''''t problems that can''''t be solved with a gun...

http://www.gametutorials.com/Tutorials/OpenGL/Octree.htm

"An octree is a way of subdividing 3D space, otherwise known as space partitioning. It allows you to only draw the part of your world/level/scene that is in your frustum (camera''s view). It can also be used for collision detection. Let me give you an example of why space partition is necessary. Assume you created a world for your game and it has over 100, 000 polygons to draw. If you did a loop and passed in every one of those polygons, on top of your characters polygons per frame your frame rate would come to a crawl. If you have a nice Geforce card it might not be as horrible, but you just restricted anyone from viewing your game that doesn''t have a $300+ graphics card. Sometimes, even though you have a really nice graphics card, the part that slows it down a considerable amount is the loop that you use to pass in that data. Wouldn''t it be great if there was a way to only render the polygons that the camera was looking at? This is the beauty of an octree. It allows you to quickly find the polygons that you are in your view and only draw them?"

There you go...

Nobody seems to understand me. I know very well and good what they are and what they do. What I want to know is the best way to pass the data to the octree and what the interface should look like. For example:

class TOctreeNode
{
private:
.....
public:
void DrawNode();

void AddPolygon(V1, V2, V3);
}

would this be the correct way to go about setting up an ocree node?

(Sorry if the class is butchered, I can read C code, but I program in Delphi)

Thanks

I personally made it with 2 different classes. cOcttree and cCubeNode. you send vertices to cOcttree and then you assing them to cCubeNodes. (When drawing vertices you call cOcttree.Dra() a pass your frustum planes to it so it draws only nodes that are in your view frustum volume.)

Tyderium : Adding triangles one by one is not such a good idea. Try passing a whole bunch of them at once. Just pass the node one big vettex array (vertices & indices & any other attributs). If you don''t know how to use vertex arrays you should learn that first. Then inside a node you have a list ov VA''s. And when you draw it just call them in some order (this also helps minimizing statechanges). There area bunch of implementations avabile on the net. Look at them and then make your own.

Thor82 : STFW (no offense but this has been discused a bazilion times)

You should never let your fears become the boundaries of your dreams.

But, what if you have 3 models in the octree... All of them have different textures... How would you do this?

James:
Maintain separate arrays (vertex, index, etc) for each material.

Then, if you store geometry data in these "buckets" according to material, you can traverse the tree at render time, and simply create a list of pointers to these "buckets" as you traverse (effectively creating a larger bucket of geometry for that material, for that particular frame). Then, after the traversal is complete, you can render all of the geometry for a given material in a single batch.

hmmm... apologies if that was a bit random/staight over anyone''s head... time for another beer