DirectX makes my octree too slow
Author
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?
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.
James
[edited by - jamessharpe on July 28, 2003 10:42:08 AM]
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.
James
[edited by - jamessharpe on July 28, 2003 10:42:08 AM]
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
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
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
