Sign in to follow this  

Grid mesh optimization - whats the current state of this

This topic is 4093 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 have a simulation program that has the 'world' divided into 16x16 tile mesh (17x17 vertices) Chunks. Ive used the tri-strip weaving method before to try to increase the GPUs use of cached vertice data. Ive used the 'degenerate triangle' method to make them render as one long tri-strip (512 triang batch...). You might think that such small poly counts are rediculous, but I render terrain within the frustum of 64 such chunks continually. My question is: on the current generation of graphic cards do optimization tricks like these make any significant difference anymore??? How large have the GPU vertice caches grown and does longer IB data streams really matter any more (like going back to using simple tri-lists which make more complex cache-reusing weaving easier). Do the pipelines wait so much for pixel data(etc..) that the VB/IB fetch/process is only a minor factor..... I only have some older GPUs to test against, so just saying 'test it' wont work... What are some of the current oppinions on this ????? What are the likely trends for the 'next' generation of GPUS ???? This would also have impact on rendering more irregular objects (where previously they recommend long tri-strips when possible) and how much effort is needed to optimize them....

Share this post


Link to post
Share on other sites
It depends on what your ratio of vertex to pixel work is, but in general, vertex cache optimization is still very important if you have a lot of geometry in your scene. You do not need to build strips though, as strip-ordered triangle lists will usually be just as efficient, and index fetch bandwidth generally isn't an issue.

Share this post


Link to post
Share on other sites
Quote:
Original post by wodinoneeye
You might think that such small poly counts are rediculous, but I render terrain within the frustum of 64 such chunks continually.

I not sure what that means, but on contemporary hardware it would be theoretically much faster to draw your 64 chunks in 1 call than in 64 calls, but it depends a lot on how your data is organized. You will probably get better performance if you increase the size of your chunks by 2, 4, or possibly even 8 times in each direction.

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
Quote:
Original post by wodinoneeye
You might think that such small poly counts are rediculous, but I render terrain within the frustum of 64 such chunks continually.


I not sure what that means, but on contemporary hardware it would be theoretically much faster to draw your 64 chunks in 1 call than in 64 calls, but it depends a lot on how your data is organized. You will probably get better performance if you increase the size of your chunks by 2, 4, or possibly even 8 times in each direction.


I have a culling system that works off an array of chunks 15x15 (a window on the larger 'infinite universe' type map) that has a precanned list of chunk slots that are visible for a range of angles (a 90 degree boresite with the player in the center of the 15x15 chunk window, seeing 8x8 part of it). The chunks on the edges get added and the others shifted as you move. Each chunk can have a different texture associated with it (thus a seperate render call for each).

Possibly in future (with newer Shader abilities) some kind of splatting method might be used (texture attribute per vertice) that would allow one render call for the whole terrain grid surface. Rebuilding the IB when the view shifts and rebuilding sections of one big VB.. (I assume the extra rewriting IB overhead wont be too significant (worse if I shift to tri-list from tri-strips)).

The chunk size was picked a few years ago when GPU memory was smaller (and speed slower) and I had been considering increasing its size (for the same world space) to improve the detail some. The chunk size was also picked to match its World space (all the other objects (upto 2000) on the chunk are grouped with it for transfer from the Server 'on-the-fly' so it had to have a reasonable size -- so there would be a limit to making the grid too much larger...)


Possibly a few generations off they will have a new memory model for the GPUs (I read about this in discussions of the new PXI Express stuff) so that the cards would use main memory instead of dedicated (and eliminate slow copying).







Share this post


Link to post
Share on other sites

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