AttributeRange in OctTree...experimenting...

[FOO]

hi all...

i tried to use Direct3D.AttributeRange in an octtree tutorial from http://www.gametutorials.com ... just to see what happens and if i get any extra performance...u know...things like vertex fill-rate and so...

but i found that Mesh.DrawSubset isnt fast enough...also some triangles will be drawn more than once...

i thought to put the source code here so if anyone found something wrong...or learn something from it or just look at it ...

cant copy-past the code here...it is in the attached file...

 

[Kavan]

Theres a lot of things that are bad in here performance-wise but Ill just point to the main problem you have. When youre using attributes to gain performance it is not meant to be used with DrawSubset. If you want to get any benefit at all then you have to use attribute data to derive parameters for DrawIndexedPrimitive call. Another thing to have in mind is that vertex range defined in attribute is not the thing to check while computing boundaries, you should check the face range and get the vertices in attribute from the faces. If anything needs clarification (and I guess it does) just say so.

 

[FOO]

well...i know octtree building process is too slow in that class...my goal was to check DrawSubsets performace...and how easy it is to use AttributeRange...it is not a great test btw... ...just a few hours work...

and yeah...i need some clarification about something related to DrawIndexedPrimitive... ...

in OctTree...do u use an array of index and/or vertex buffers or something else?

if yes then wont the fill rate will be slow?...coz there will be lots of loops in a recursive call...

if no then could u tell me the best way u know to get the highest fill rate?...

i dont know how a Mesh class stores vertex data...this is the main goal of that octtree class...to see wethere it will be faster or not...may be the whole experiment is wrong...i dont know...it sucked alot...

thanx...

EDIT:
forgot to say thanx for this tip...i will think how to use it...i never used index buffers...

Another thing to have in mind is that vertex range defined in attribute is not the thing to check while computing boundaries, you should check the face range and get the vertices in attribute from the faces.

 

[Kavan]

First the architecture of Mesh class. It basically has a vertex and index buffer and the attribute ranges define what is rendered in a single call to DrawSubset. The best way as I see it if you want something along this lines would be to define each node in octtree to have a unique attribute. You would probably want to group it in a way that neighbouring nodes have neighbouring attribute indices. You would do this for each original attribute in the mesh (its even better to just assume theres only one material/texture and if there are more just treat them separately). Then youd call optimize to do attribute sort. That way vertices get rearranged to minimize cache misses. Then in the rendering phase you wouldnt call DrawSubset but directly calling DrawIndexedPrimitive in a way that if more consecutive attributes are to be rendered you render them in a single call.

All this makes sense only in very big buffers and youd probably run out of buffer size before you get any benefit. Reason behind this is that this increases the number of DrawPrimitive calls which is the biggest factor determining the speed of your app. So as far as I know the way to go around this is to stream the data that should be rendered into a dynamic vertex buffer. Again, this makes sense only if you have huge scene graphs where vertex fill rate is of real concern. In most cases when geometry is not that intensive its best to do simple frustrum tests and just brute force the whole mesh.

 

[FOO]

ok...thanx keven...

i read some other articles/posts/discussions about octtrees...lots of things i learned today...

this makes sense only if you have huge scene graphs where vertex fill rate is of real concern.

yeah...i am rendering a ripped level from a game with ~167000+ vertices...in/out door...

thanx again..