• Advertisement

Archived

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

Optimisation crisis with terrain meshes

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

Hi, My terrain is rendered using static VB's, which is all fine and well. The problem is that I use meshes to add detail to the terrain (trees, rocks, demonically possessed yet strangely paralysed rabbits, etc.), and this is becoming seriously slow. I am keeping the mesh detail as low as possible (trees in under 12 polys, grass in 3, and so on), but all those calls to DrawSubset and settransform are pulling the frame rate down. Without going through each detail mesh and manually copying the mesh into a static VB is there another way to optimise this? [edited by - SoaringTortoise on August 18, 2003 4:40:00 PM]

Share this post


Link to post
Share on other sites
Advertisement
Ensure you''re grouping things into like shaders, then textures, (basically minimising state changes, i.e. do all the trees at once, etc.). But, the biggest optimization will be to batch everything into one VB. All those Draw calls are likely your biggest pitfall.

I like pie.

Share this post


Link to post
Share on other sites
Avoid using DrawSubset, because it´s slow.

you´d better user a state manager (or better effect manager) and locking / rendering each of the vb of the d3dx mesh corresponding to that material / effect.

Because even if you have the same renderstates for 2 xmeshes, drawsubset will "remake" the states "properly".

Share this post


Link to post
Share on other sites
Yah, I get that, but even so you still end up with multiple render commands. With the really low-poly meshes (like 2 poly grass), I can end up drawing 100 pieces of grass with 100 drawsubsets. This is only 200 polys, but it''s 100 drawsubsets. Even batched by texture it''s still a lot.

I''m pretty sure that the internal workings of the Drawprim and the drawsubset are pretty much identical, and we are advised to never user drawprim with less than a few thousand polys so...

The best way to optimise this would be to get all of the similar mesh subsets and render them in a single call, but I don''t see a way to do this.

At present I am breaking my terrain up into VB batches of quads occupying around 100x100 meters. If there was some way to transform, scale and attach the meshes to the same VB then I could render the whole lot in a few drawprim calls (just batching by texture) even if there were 1,000 grass meshes.

But how?

Share this post


Link to post
Share on other sites
You''d probably benefit from batching the micro-objects together (either at exporting stage, or caching them into larger objects as you go along).

So you''d not have "a blade of grass", but rather a "grass section of 1000 blades"... Helps for doing stuff like billboarding it later anyways.

If you do it realtime, what you''d basically do is cache the nearest X objects every couple of frames into one dynamic VB, duplicating the vertices (because they''ll all be pre-transformed, right), and then submitting the entire 3000+ poly batch to the hardware..

Feels a bit like a hack, but...


"what the eagle doesn''t understand, is that it''s participating in natural selection. One day, the Tortoise will learn how to fly"

Share this post


Link to post
Share on other sites
OK, so at load time (not at save, because I''ll need to edit the map later), I''d say something like

For every MeshInScene Of Type Grass/Tree/etc.
GetMeshVertexBuffer
TransformVerts
AppendVertsTo GrassVB


Yes? OK, last question then really is how do I transform the Mesh vertices before appending them to the GrassVB (or TreeVB or whatever).


-And the great God Om spoketh unto Brother, "PSST! Hey, You!" -

Share this post


Link to post
Share on other sites

  • Advertisement