Archived

This topic is now archived and is closed to further replies.

Chaucer

octree, dyanmic index buffers, slower

Recommended Posts

Chaucer    122
I''m finally able to fill my dyanmic index buffers correctly and it''s still too slow. Here''s how it works: Loading Stage: 1. Generate vertices and put into 1 big vertex buffer 2. Create an index buffer for each texture group that is the size of all the indices for that texture group. 3. Split up into 8 nodes. Each node has an array of indices for each texture. Rendering Stage: 1. For each node, check to see if it''s visible and go to #2 2. For each texture group in node, lock index buffer and copy (if indexptr=0 discard, else append) indices from node into the index buffer for that texture group (see loading stage#2). Unlock index buffer. 3. For each texture group, render index buffer for that texture group. This is actually much slower than my previous way of just creating and index buffer for each texture group in each node and rendering one at a time. I guess memcpy calls are slower than drawindexedprimitive. Is there any other way to get this faster?

Share this post


Link to post
Share on other sites
Alload    122
If there aren''t enough vertices you won''t go faster while using an octree But think about an entire level with more than 300 000 polygons, you will definitively have to partition the space into defined sector, hence the octrees that will help you throw away from the rendering pipeline tons of polygons.

You have to reach the limit of you graphic card in order to get the best of space partitioning.

Share this post


Link to post
Share on other sites
RhoneRanger    100
Just a little expansion on what Alload said.

If your index buffers are like 20 triangles, and you have 100 of them, this will cause serious slowdown! You need to lower the calls to DrawIndexedPrimitive.

Try to keep your buffers (Geforce2 or equivalent) about 2000 triangles per buffer.

Geforce3 about 3500 triangles

GeForce4 about 5000 triangles. These are the "optimum", but you can give or take a little!

Share this post


Link to post
Share on other sites
Chaucer    122
Well I definately couldn't create a map that large. There's no way its fast enough. About the largest I can handle now is about 15k vertices. I guess I need to implement some LOD before using the octree?

edit:
So since I have 7 texture groups and 1 buffer per texture group, per node, I should only split into more nodes if I have more than 21k triangles?



[edited by - Chaucer on March 16, 2003 12:45:04 AM]

Share this post


Link to post
Share on other sites
RhoneRanger    100
you are totally missing the point!

The slowdown you are having is too many calls to DrawIndexedPrimitive!

I would think by what you are describing, is that your index buffers are just too small!

Try to keep your index buffers the size of what I showed you, even if it means enlarging your trees.

Share this post


Link to post
Share on other sites
BillPo    122
I''d just like to point out that if you are infact using memcpy to copy the indices from system memory to the index buffer then its going to be VERY slow if the index buffer is in video memory (which it should be). Not only that, but locking vertex buffers or index buffers is a slow process and the lock waits until the GPU is finished using the buffer before returning the pointer to the calling program. Calling a lock many times per frame plus memcpying from system to video memory, and finally throw in many calls to draw primitives, and you bound to get poor performance.

If its possible, try to have as many index buffers as you can and set them only once at the beginning (when loading the scene). That way you can bypass the lock and memcpy altogether

If you''re using directx check the directx 9.0 C++ doc for "performance optimizations" in the index and it gives a LOT of tips for improving performance.

Share this post


Link to post
Share on other sites
RhoneRanger    100
For dynamic index buffers, you better NOT be using memcpy!

Since you have your vertex data, if you are going to change the index buffer, do NOT memcpy! If you are, this might be causing your slowdown!

Share this post


Link to post
Share on other sites
Alload    122
I don''t understand how you can use octrees if you don''t refresh the index buffer.

For each frame you have to refresh the index buffer with currently seeable faces, haven''t you?

Share this post


Link to post
Share on other sites
Chaucer    122
quote:

you are totally missing the point!

The slowdown you are having is too many calls to DrawIndexedPrimitive!

I would think by what you are describing, is that your index buffers are just too small!

Try to keep your index buffers the size of what I showed you, even if it means enlarging your trees



That''s what I was asking. I need trees large enough so that each node is a size of 21k triangles since there are 7 texture groups and 1 buffer per texture group.


quote:

For dynamic index buffers, you better NOT be using memcpy!

Since you have your vertex data, if you are going to change the index buffer, do NOT memcpy! If you are, this might be causing your slowdown!



What is a fast way to fill a dynamic index buffer? I tried just using a for loop and, although it was faster, it didn''t make much difference.

quote:

If its possible, try to have as many index buffers as you can and set them only once at the beginning (when loading the scene). That way you can bypass the lock and memcpy altogether


I have 2 methods right now that I''m testing out. One is where I create an index buffer for each texture group in each node of the octree. When a node is visible, i loop through the texture groups, and on each one, I set the indices for that group and node and drawindexedprimitive. I can see why this is slow, having so many index buffers and calls to drawindexedprimitive.


The other method was suggested to me by people here on this forum. I have one index buffer for each texture group in the terrain and as I go through the visible nodes, I take the indices from each texture group in each node and fill it into the one large texture group buffer. Then at the end, I loop through the texture groups and drawindexedprimitive. This turned out to be slower than the previous method.


So. What should I do? At this point, I can''t create a terrain with 300,000 triangles. If I even create a terrain with 15k triangles and use the octree, I get about 5 fps.

Share this post


Link to post
Share on other sites
Chaucer    122
I was still hoping that you could confirm that it's good to create octree nodes with 21k triangles if there are 7 texture groups.

Another thing I should point out is that I'm using triangle lists. I dont see how I could use strips or fans since the texture groups are placed randomly. Do you have any ideas for that?

[edited by - Chaucer on March 18, 2003 11:14:06 AM]

Share this post


Link to post
Share on other sites
GalaxyQuest    122
Could someone elaborate on how you are ''suppose'' to copy indices if not by memcopy, I sorely hate all the ''dont do this'' without a suggestion on what to do.

Share this post


Link to post
Share on other sites