Sign in to follow this  

octree and vertex array

This topic is 4764 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 am incorporating octree into my terrain now. From articles and tutorials on the Internet, it seems that I have to move the drawing routine down into my Octree class, because I'll be doing the frustum culling. Previously, I sent my all vertex data by calling glVertexPointer, and enabling the GL_VERTEX_ARRAY client state once during the initialization. Then I had one call to glDrawElements in the main loop to render the terrain. Now that I have partition my terrained into "segments," it seems to me that now I must have multiple vertex arrays, and render each segment separately. I am not sure exactly how you handle multiple vertex arrays. Should I enable (glEnableClientState), send vertices (glVertexPointer), render (glDrawElements), then disable (glDisableClientState), for each cube, for each iteration? That sounds slow to me. Compared to the regular glBegin()-glEnd() pair with display lists for each segment, how much faster is vertex array?

Share this post


Link to post
Share on other sites
I'm using vertex arrays with octrees, myself, but rather than use multiple vertex arrays, I simply keep an 'offset position' for each octree node. Thus, when I start to draw the octree, I enable my client state(s) and set the pointer(s). Then I loop through my nodes, doing the frustum cull check. If it passes, I simply call

glDrawArrays(GL_TRIANGLES, BufferPos, TriangleCount * 3);

where BufferPos is the offset in the one, big array that contains the vertices this node contains.

I hope that helps.

Regards,

Hew T.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hew T
I'm using vertex arrays with octrees, myself, but rather than use multiple vertex arrays, I simply keep an 'offset position' for each octree node. Thus, when I start to draw the octree, I enable my client state(s) and set the pointer(s). Then I loop through my nodes, doing the frustum cull check. If it passes, I simply call

glDrawArrays(GL_TRIANGLES, BufferPos, TriangleCount * 3);

where BufferPos is the offset in the one, big array that contains the vertices this node contains.

How do you store the array? I stored my array in one big single-dimension-row-major array. I can't just pass an offset because OpenGL would render it as one line. Like this.

+---+---+---+--- - +

. . . .
| | | |
+---+---+---+--- - +
| | | | |
+---+---+---+--- - +
| | | | |
? +---+---+---+--- - +
| | | | |
+---+---+---+--- - +
1 2 3 4 n

Imagine this 3x3 (or 4v4 vertex-wise) is one segment. If I just simply pass an offset (#1 in this case), and pass 16 as the size of this patch I want to render, I will end up with one long straight line instead of one nice patch. If I want to render a nice patch, I have to know in what index the next row starts (the one marked with '?').

Share this post


Link to post
Share on other sites
Your array creation will have to be tied to the fact that you're now going to use an octree structure. In my implementation, I fill my buffer as I walk through the octree structure creation. Thus, each end node's vertex / texcoord / colour information is contained within a discrete chunk in my array, and all I need to know to use it is the offset in the chunk, and how many verts are in the node.

Regards,

Hew T.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hew T
Your array creation will have to be tied to the fact that you're now going to use an octree structure. In my implementation, I fill my buffer as I walk through the octree structure creation. Thus, each end node's vertex / texcoord / colour information is contained within a discrete chunk in my array, and all I need to know to use it is the offset in the chunk, and how many verts are in the node.

Regards,

Hew T.

Hey, that's cheating [grin]. That means you brute force the order of your vertices? What if the octree goes deeper than you expected?

Share this post


Link to post
Share on other sites
Quote:

Hey, that's cheating . That means you brute force the order of your vertices? What if the octree goes deeper than you expected?


Cheating? How so?

Octree creation :

1) Find center / bounds of bounding cube (top-level octree 'node')
2) Associate all polys in the object with the top-level node
3) If over the maximum desired polycount per node, subdivide,
otherwise create a single VBO.

Subdivision :

1) For each poly in the node : Calculate what subnode the poly belongs to
2) If over maximum desired polycount per node, subdivide again, otherwise append the poly data to the VBO buffer, and noting the current buffer position for the node, and how many polys are associated with the node.

Seems simple enough to me...

If there's something I'm doing that is wrong / doesn't allow a particular implementation, please, let me know...

Regards,

Hew T.

Share this post


Link to post
Share on other sites
Ah, I see what you are saying. You treat each triangle as a separate triangle, then create a list of triangles in each node and render the triangles one by one. You just need the list of triangles and how many you have. I used triangle strips and the only solution I can think of is to reconstruct the indices every time I subdivide a node. I was like, "what the hell, that's nasty!"

So people don't use triangle strips when using octrees, then?

Share this post


Link to post
Share on other sites

This topic is 4764 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this