Jump to content
  • Advertisement


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


DirectX makes my octree too slow

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I recently implemented an octree in order to display a landscape. But I was quite surprised about the result. Instead of increasing performance, it made my program much slower than without octree. Then, I tried to display (without using octree) a 24k faces mesh, once by drawing the whole mesh directly, and the other times by drawing the first 12k faces and then the last 12k faces. The results were : - no subdivision : 105 fps - subdivised into 2 : 76 fps - subdivised into 4 : 50 fps So, this is why my octree was so slow.. Are octree really useless for rendering big objects?

Share this post

Link to post
Share on other sites
What you need to do to make any spacial algorithm more renderer friendly is use an intermediate renderqueue which combines any objects that use the same material for rendering.

THe problem with your method is you (probably) increased the number of calls to DrawPrimitive, and decreases the number of polys sent per call. This is generally bad, and is what caused your drop in performance.


[edited by - jamessharpe on July 28, 2003 10:42:08 AM]

Share this post

Link to post
Share on other sites
1) On modern hardware 24k faces isn''t really too big an object. Definately not enough to stress any hardware even just being drawn all in one chunk. Repeat the experiment with 240k...

2) Drawing too many batches (i.e. separate Draw*Primitive*() calls) is a good way to kill your performance. Particularly if each batch doesn''t have many polygons OR causes the whole vertex range to be transformed (implies badly organised data).

3) Personally I''d aim for between 200 and 1000 polygons per leaf node of the octree - i.e. the smallest batch size.

4) I''d also ensure the vertex and index data is pre-sorted into node traversal order so you get the opportunity to coalesce neighbouring visible nodes.

5) If you really want to know where your performance has gone: profile. Maybe you''re getting terrible CPU cache performance with your tree traversal code for example - until you profile you''re actually in the dark and jumping to conclusions - it may not even be anything to do with D3D.

Simon O''Connor
ex -Creative Asylum
Programmer &
Microsoft MVP

Share this post

Link to post
Share on other sites
Also node that according to your message you dont do anything useful in the octree. Surely drawing objects through an octree is slower than drawing the whole object in one call.

The trick is that with the octrree you should not draw the whole object, or not draw it in full resolution. All this nifty things like portals and octrees just give you something if there IS optimisation to handle. Like a larger landscape where part of the octree cells are not visible (behind the view frustrum) or drawn in lower resolutions (as in "far away").

Otherwsie an octree IS overhead. I think, though, it should not be that much overhead.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!