Frustum Culling with a set of Index Vertex Arrays?
Hi all.
My terrain generator/viewer is comming along quite nicely now but I have to get it going quicker. So, the next thing to implement is an Octree and Frustrum culling of the triangles in the scene. I understand the maths for this and the concept is simplicity itself BUT how to implement it with the set of Index Vertex Array that the terrain currently uses for rendering?
My Terrain uses a height map generated from a picture. I then create a vertex array containing all the vertexes in this heightmap. Then I create Y index arrays, each with X*2 elements in them. They are X*2 long because the indexes produce a very nice triangle strip when passed to glDrawArrays.
But, I dont know how to cull these triangles against the frustum. Am I gogin to have to switch to a array of triangles and render these once I have got rid of the ones that cant be seen?
How do I use VA and Frustum Culling at the same time?
Any ideas would be most appreciated.
Pete
well, I''m trying to do the same thing, I use quad_strips instead of trinagles, and I found a nice tutorial about frustum culling at www.markmorley.com . Unfortunately I was not able to test my quad_strips against the frustum, if you can do that please share your knowledge with me, thanks !
I''ll be facing the same problem shortly.
My planned fix for the problem will be to simply filter any culled polygons (since we''re talking about different types of primitives here) using the following method (pseudo code):
/* These store certain positions in the array we''re gonna need to know. */
int current_array_position = 0;
int draw_start_position;
int draw_end_position;
while(current_array_position < LENGTH_OF_THE_ARRAY)
{
draw_start_position = current_array_position;
while(ARRAY[current_array_position] passes your frustrum test)
{
current_array_position++;
}
draw_end_position = current_array_position;
/* Now draw everything inbetween draw_start_position and draw_end_position using glDrawArrays(GLenum mode, draw_start_position, draw_end_position - draw_start_position - 1)
*/
}
I hope that helps. Any questions, feel free to ask.
My planned fix for the problem will be to simply filter any culled polygons (since we''re talking about different types of primitives here) using the following method (pseudo code):
/* These store certain positions in the array we''re gonna need to know. */
int current_array_position = 0;
int draw_start_position;
int draw_end_position;
while(current_array_position < LENGTH_OF_THE_ARRAY)
{
draw_start_position = current_array_position;
while(ARRAY[current_array_position] passes your frustrum test)
{
current_array_position++;
}
draw_end_position = current_array_position;
/* Now draw everything inbetween draw_start_position and draw_end_position using glDrawArrays(GLenum mode, draw_start_position, draw_end_position - draw_start_position - 1)
*/
}
I hope that helps. Any questions, feel free to ask.
Protozone
Hi guys.
Yeah, I''ve come to the same conclusion over the weekend. I figure I will have a stl::vector holding structs something like this.
Then I will step through my index arrays, testing each triangle I come across. To do this I will have to test the triangle depicted by the current vertex and the two previous indexes in the array. While stepping through, I will store the current pointer position of the index in the array in pStart and step along until the triangle is no longer in the frustum (Or the triangle is back-faceing). Then I will store the length in iLen.
This will allow me to write this code for the drawing of the (now clipped) triangle list.
Ok. One last thing. How do I integrate this with my Octree? The vertex arrays go right accross the terrain but I want to use an octree to test for collision and visibility on a triangle level basis.
Maybe the Octree leaves should hold a set of IndexDescriptor structs themselves. That way I would know which triangle strips are in the octree node without having to compute it each time. I could then test the frustrum agains just these stored set of indexes? Maybe?
Any further ideas
Pete
Yeah, I''ve come to the same conclusion over the weekend. I figure I will have a stl::vector holding structs something like this.
typedef struct tagIndexDescriptor{ Vertex * pStart; GLuint iLen;}IndexDescriptor;typedef stl::vector IndexDecVector;
Then I will step through my index arrays, testing each triangle I come across. To do this I will have to test the triangle depicted by the current vertex and the two previous indexes in the array. While stepping through, I will store the current pointer position of the index in the array in pStart and step along until the triangle is no longer in the frustum (Or the triangle is back-faceing). Then I will store the length in iLen.
This will allow me to write this code for the drawing of the (now clipped) triangle list.
IndexDecVector::iterator iIter;for(iIter = vIndexes.begin(); iIter != vIndexes.end(); iIter++){ glDrawElements(GL_TRIANGLE_STRIP, (*iIter).iLen, GL_UNSIGNED_INT, (const GLvoid*) (*iIter).pStart);}
Ok. One last thing. How do I integrate this with my Octree? The vertex arrays go right accross the terrain but I want to use an octree to test for collision and visibility on a triangle level basis.
Maybe the Octree leaves should hold a set of IndexDescriptor structs themselves. That way I would know which triangle strips are in the octree node without having to compute it each time. I could then test the frustrum agains just these stored set of indexes? Maybe?
Any further ideas
Pete
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement