If you''re using vertex shaders then you have other options:
Store a set of about 20-25 trees in a vertex buffer. For each vertex, set an matrix index (like skinning).
Setup your renderstates for Material1
for (each each tree group)
{
LoadMtxPalette() //This is all 20-25 unique matrices
SetVB/IB
Render()
}
This way you can have about 20-25 trees in a group, thus cutting your number of batches from 300 to about 15 while still allowing each tree to have its own unique orientation.
So your treating this as a 1 bone skinning problem.
Primitive batching
Author
Ok thanks for the answers, now I do some tests and post the results here so you can make use of them.
If there are other ideas simply post here.
If there are other ideas simply post here.
Hmmm. My problem is slightly more complex. I am using the same routines for rendering all scenery objects (trees, rocks, enemies, buildings...). The problem is that some of these are static, some are mobile, some have rendering restrictions (such as transparent textures that need to be depth-sorted), and some that don''t, and some have multiple materials (the tree/bark)while others have only one.
I''ve experimented with material batching, transform matrix batching, VB caching and I got the following:
On my dev machine (2ghz, GeForce4 Ti), the fastest method was to just do several transforms, ignoring the materials, and depth-sorting only those items that contained transparent textures (this required a little more memory, because I had to tag the textures as opaque/not opaque).
On my test machine (750mhz, GeForce2 MX), VB caching with texture batching was the fastest.
My guess is that if you''ve got a slow card, you need to do more work on the CPU. If you''ve got a fast card, it''s better to leave the CPU idle. So... nothing too revalatory there.
I''ve experimented with material batching, transform matrix batching, VB caching and I got the following:
On my dev machine (2ghz, GeForce4 Ti), the fastest method was to just do several transforms, ignoring the materials, and depth-sorting only those items that contained transparent textures (this required a little more memory, because I had to tag the textures as opaque/not opaque).
On my test machine (750mhz, GeForce2 MX), VB caching with texture batching was the fastest.
My guess is that if you''ve got a slow card, you need to do more work on the CPU. If you''ve got a fast card, it''s better to leave the CPU idle. So... nothing too revalatory there.
Author
quote:Original post by SoaringTortoise
My guess is that if you''ve got a slow card, you need to do more work on the CPU. If you''ve got a fast card, it''s better to leave the CPU idle. So... nothing too revalatory there.
The main problem is to found the right balance.
In my engine I use a VB pool for static and dynamic data, it seems to be the right choice but this solution not permit the batching.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
