#### Archived

This topic is now archived and is closed to further replies.

# Octree too slow :(

This topic is 5489 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Over the past 2 weeks, I''ve been writing an octree class. I finally got it working but its slower than not using it at all. Here''s the deal. I''ve got a tiled terrain in d3d so I have texture groups. I use one large vertex buffer to render from. For each node in the octree, there''s an array of texture groups that contain an index buffer for all the vertices that are in the node that are also associated with that texture. So when I render, I loop through the texture groups in the node, setting the texture and rendering (using indices) for the node. If I set the max number of triangles per node up to around 400, I get around 30fps on average. Of course, as I move the camera to the edge of the map, it shoots up over 100fps. Is this way of doing this too slow or am I more likely making a mistake somewhere? Has anyone done something like this before? Is there any other way to do it? I can''t think of another way to do it using texture groups. Thanks.

##### Share on other sites
Are you implementing some sort of frustum culling? If you''re not, then you''re drawing the whole scene, and you''re having to recurse through the octree. With my octree class, I tend to use about 1000 triangles per node as not to get the recursion too deep, and I also set a max depth, depending on how large my scene is, and how far I want to recurse.

##### Share on other sites
hmm, yeah I think you''re right. Setting the triangles up to 1000 definately improved the fps. I am doing frustum culling but I''m rendering across the entire map if I''m on one side looking across. I guess I need to get the option to set the far plane on the frustum closer when constructing it. Thanks!

##### Share on other sites
Are you setting the render state for each array in each node? That will definately hurt performance aswell. Try passing the indicies off to some sort of cache that renders all the indicies for each render state in one hit after you''ve gone through the octree.

##### Share on other sites
hmm, can you maybe explain or give ideas on how to do that? Right now, I''m thinking just creating another class to hold the indices and then telling it to render when the octree is done doing its render method but that doesn''t seem like a good solution. Thanks!

##### Share on other sites
A quick example could be to use std::multimap.

  class Material;typedef unsigned int* IndexArray;typedef std::multimap<Material*,IndexArray> VisibileIndexArrays;VisibileIndexArrays visibile;// ...// Every time you reach a leaf of the octree, dovisible.insert(VisibileIndexArrays::value_type(materialptr,indexarray));

Then after you've finished in the octree, go through the multimap from begin() to end() drawing the indicies, only setting the rendering state when your Material* changes.

Naturally, there would be better methods than this, but it gives you a starting point.

[edited by - joanusdmentia on February 9, 2003 7:31:00 PM]

##### Share on other sites
hmmm. I think the part that is slowing it down so much is that I have my index buffers split too much after a few levels of recursion. So I''m looping through all the textures in a node, setting the indices, and drawing them. Some of these could only be drawing one texture.

Is there a way to combine index buffers so that once I find all the indices that will need to be drawn each frame, I can set it once and draw? There''s no way that recreating a new index buffer could improve speed.

In your method, does it sort them on the material (or texture in my case)?

I''m using one large vertex buffer so I can easily set that before I even start recursing through the nodes.

##### Share on other sites
quote:

Is there a way to combine index buffers so that once I find all the indices that will need to be drawn each frame, I can set it once and draw? There''s no way that recreating a new index buffer could improve speed.

Well, you could pre-allocate one large index buffer when the octree is created and then fill it in as you traverse the octree. That should help, but the only real way to find out is test it. Also, that will only work if you''re storing 3 indicies per triangle in your index buffer, as opposed to using triangle stripping or fanning.

quote:

In your method, does it sort them on the material (or texture in my case)?

Yep, the std::multimap will sort by the Material* (or Texture*, whatever). I wouldn''t worry too much about the actual order of the textures, all that since std::multimap is sorting all the same Material* will one after the other when you go through using an iterator. So you just bind your texture when you reach every time the Material* changes.

If you''re filling the video cards memory, then you''d start looking at the order in which textures are sorted. For example you''d keep them in a fixed order and alternate directions every frame in order to minimize transferring textures to the card. In this case you wouldn''t just be able to use std::multimap.

Joanus D''Mentia