Jump to content
  • Advertisement

Archived

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

Fald

Octree question (Multiple VBs?)

This topic is 5419 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

Hello Let''s assume I got one huge vertex buffer that contains all static world data and that I want to use an octree/quadtree. What would be "better" or maybe the "proper" way? Having a copy of the index buffer in system memory and divide that into trees and then tell it what polygons to render using DrawIndexedPrimitive or Taking that huge VB and split it up in as many vertex buffers as I have to (one vb = one node), then switch vertex streams when I render, and render them using DrawSubset ? Any suggestions are welcome

Share this post


Link to post
Share on other sites
Advertisement
Well, having a whole bunch of tiny vertex buffers and swapping between them would probably kill your performance. System memory index buffers would work a little better, but since they''re in system memory, you would loose all parallelism between CPU and GPU.

A third option would be to use dynamic vertex buffers. As you traverse your tree, you would fill up this vertex buffer (and associated index buffer if you want to) with only the geometry needed to render the current view. There are some tutorials on this on the web. A google search on D3D + octree would probably give you some good links. There''s probably one here on GameDev as well.

neneboricua

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
i''ve never tried this but it could be possible, have all the
data in one big vertexbuffer, then you have a dynamic indexbuffer that you fill in with the data to draw.

Share this post


Link to post
Share on other sites
One big vertex buffer may be a little large, you may need to have several, but definately not one per node. Use a dynamic index buffers that you fill as you traverse the tree, that should work very good. Don''t use dynamic vertex buffers, that is a killer, especially if you fill them a lot and use big vertices, you will have a problem with AGP transfer rate. I''ve tried that and it''s slooow.

neneboricua19:
Why would he loose parallelism between CPU and GPU when using index buffers but not with vertex buffers? That just seems wrong. As long as you don''t read data back from a vertex/index buffer and lock them properly, everything should work smoothly.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
May be wrong..but how about:

using 1 big vertex buffer and 1 big index buffer...it''s static and if they all fit, no need for dynamic anything.

divide the buffers into blocks for each node...
may need to duplicate verts for polys that cross the dividing plane..

must use blocks because...lets say a node contains a tri at the start and 1 at the end of the vert buffer..it would transform all the verts...even if only drawing those 2 tri

using blocks would transform only the verts in that node..

so each node contains info for indexing into the buffers..

Share this post


Link to post
Share on other sites
I also have a question regarding octrees, that is sort of related to the performance issue. when dividing vertices into different nodes, what is computationally more efficient, comparing the vertices to see if they are contained within a bounding volume, or just creating planes then testing to see if the object is in front of or behind those planes? also, is it better to divide the vertices by themselves, or divide up each triangle?

[edited by - tri-thanatos on January 12, 2004 2:17:18 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Decept
neneboricua19:
Why would he loose parallelism between CPU and GPU when using index buffers but not with vertex buffers? That just seems wrong. As long as you don''t read data back from a vertex/index buffer and lock them properly, everything should work smoothly.



Well, if this were true, then there really wouldn''t be a need to specify whether a vertex/index buffer should be created in video memory or in system memory. If you don''t read anything from the buffer, then it wouldn''t matter where the buffer was created, since reading would be the only slow operation.

Unfortunately, reading from video memory isn''t the only thing that messes with parallelism. If you have large amounts of data in system memory that need to be transfered to video memory each and every frame, there will be a slow down in performance. Now granted, it won''t be as large as it would if you were actually reading data, but the slow down is still there.

neneboricua

Share this post


Link to post
Share on other sites
neneboricua19:
It does matter where you put it, if you have it all in system memory, then you have to transfer it to the card every frame and that will hog up the agp bus. But because you are moving in the game you must upload something to the gfx card. That''s why you should have the vertices in a static VB on the card and only transfer indices over the bus, because they are much smaller.

Share this post


Link to post
Share on other sites
quote:
Original post by Decept
neneboricua19:
It does matter where you put it, if you have it all in system memory, then you have to transfer it to the card every frame and that will hog up the agp bus.


That''s exactly what I said in my previous post. What I was trying to say before was that reading data back from the card was not the only thing that could slow you down. If it was, then it wouldn''t matter if you created objects in system memory or in video memory. But as you''ve pointed out, it does matter where you put them because anything in system memory needs to be transfered to video memory so that the card can use it.
quote:
But because you are moving in the game you must upload something to the gfx card. That''s why you should have the vertices in a static VB on the card and only transfer indices over the bus, because they are much smaller.

That''s true. But notice how I said "If you have *large* amounts of data in system memory that need to be transfered to video memory each and every frame, there will be a slow down in performance." You do have to transfer small amounts of data to the card but what I was talking about was transfering large amounts of data.

I think that we''re basically saying the same thing, but in a slightly different way. I''m pretty sure this thread has solved the OP''s question. This is what GameDev is all about; devs helping each other out and discussing ideas.

neneboricua

Share this post


Link to post
Share on other sites
this was mentioned in the directx9 opimize paper of ati: "It is important to allocate vertex buffers of reasonable sizes. If buffers are too small and there too many of them, the system and video memory is wasted because of DirectX®
and driver overhead. Also extra DirectX® and driver overhead is incurred due to buffer switching. On the other hand, using buffers that are too big can limit amount of video
memory available to other resources and can affect managed resource swapping. On resource swapping big buffers can cause bad memory fragmentation and waste a lot of memory.
For static vertex buffers 1-4Mb is a good size to start with, but it might vary depending on the amount of your resources, local video and AGP memory available. If amount of
available video memory is low and a lot of resource swapping is expected, a smaller buffer size is a better choice. For dynamic buffers you should not allocate buffers bigger
than the data streamed to the card per frame. In most cases 256Kb-1Mb dynamic buffers provide a good starting point for performance tweaking. In DirectX® 9 there is a way to
specify byte offset in the vertex buffers when setting up vertex streams. This per-stream offset solves the problem of using multiple dynamic streams without wasting extra memory, which was a case in previous versions of DirectX®. Use this feature to pack multiple vertex formats into the same buffer and reduce the total number of buffers and their switches."

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!