Octree, have to split tris?
Author
Hi
I need advices.. I wanna ask whether i should split my triangles in octree, if one of my triangle overlapping to other nodes???? is it necessary to split them???.. i can''t imagine how much triangles would be generated from this T_T... mayb just keep the same triangle in different nodes if it overlaps? keep things simple?? :D
thx in advance, i would greatly appreciate your reply.
If you are planning on using the octree for rendering, then splitting the triangles would reduce polygon overdraw.
If you are using it only for collision detection, then I would say splitting isn''t necessary.
If you are using it only for collision detection, then I would say splitting isn''t necessary.
1) If this is for clipping, remember that hardware is much better than you at the per polygon level. If you end up submitting twice as many polys to the H/W just because every poly is nicely bounded in the nodes of the tree you may end up with lower performance. Experiment with moving moving any poly which straddles two nodes further toward the root node - it can be faster with 3D hardware than the extra polys.
2) Take a look at Thatcher Ulrich''s "Loose Octrees" method which relaxes the node boundaries for polys which straddle.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
2) Take a look at Thatcher Ulrich''s "Loose Octrees" method which relaxes the node boundaries for polys which straddle.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Author
Hi again, thx both of you for the advices,,
Yeah I am using it for rendering
S1CA, your theory is what exactly what i was thinking at the time.. For the polygon overdrawn problem,, I think I will just have to tackle it by keeping list of triangles that have been passed into the index buffer, then for each triangle i just quickly check if it''s already in the list...
Then after I get all the triangles that are going to be displayed then just add them to the index buffer in one go..
Note: I use 1 index buffer as the dynamic buffer,, and 1 huge static vertex buffer for storing all the vertices. Then i will try to fill up the data in index buffer before clearing it...at each rendering loop. I think I would get more speed using index list.. rather than just 1 dynamic vertex buffer. But I kindda get a feeling that if the index jumps up and down through the vertex buffer would that cost my speed...??? But Im sure that it''s a minor cost
would that be efficient ?
Thanks again for advices
Yeah I am using it for rendering
S1CA, your theory is what exactly what i was thinking at the time.. For the polygon overdrawn problem,, I think I will just have to tackle it by keeping list of triangles that have been passed into the index buffer, then for each triangle i just quickly check if it''s already in the list...
Then after I get all the triangles that are going to be displayed then just add them to the index buffer in one go..
Note: I use 1 index buffer as the dynamic buffer,, and 1 huge static vertex buffer for storing all the vertices. Then i will try to fill up the data in index buffer before clearing it...at each rendering loop. I think I would get more speed using index list.. rather than just 1 dynamic vertex buffer. But I kindda get a feeling that if the index jumps up and down through the vertex buffer would that cost my speed...??? But Im sure that it''s a minor cost
would that be efficient ?
Thanks again for advices
From the SDK:
The minIndex and NumVertices parameters specify the range of vertex indices used for each DrawIndexedPrimitive call. These are used to optimize vertex processing of indexed primitives by processing a sequential range of vertices prior to indexing into these vertices. It is invalid for any indices used during this call to reference any vertices outside of this range.
This sounds like if you use 1 big vertex buffer, they will all have to be transformed even if they are not used. So it may be faster to have a dynamic Vert and Index buffer, I haven''t tried it yet so maybe someone else can clear this up.
The minIndex and NumVertices parameters specify the range of vertex indices used for each DrawIndexedPrimitive call. These are used to optimize vertex processing of indexed primitives by processing a sequential range of vertices prior to indexing into these vertices. It is invalid for any indices used during this call to reference any vertices outside of this range.
This sounds like if you use 1 big vertex buffer, they will all have to be transformed even if they are not used. So it may be faster to have a dynamic Vert and Index buffer, I haven''t tried it yet so maybe someone else can clear this up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
