state changes

Hello,

my terrain engine is going to be quite flexible. The terrain consists of severl 10,000 or even 100,000 or more triangles, some of which are lit with standard OpenGL lighting, without any bump mapping/ppl, but with the possibility of using all four (gf 4 ti) texture units for color textures (my client wants to have this possibility), while others will be drawn in one pass with bump mapping/ppl with NV_register_combiners, while other parts are draw in two passes with ARB_texture_env_combine, and what is used can change quite often.

So it seems that a lot state changes will occur, enabling and disabling NV_register_combiners and ARB_texture_env_combine again and again.

Will this take up so many time that the idea is completely pointless or is it going to be OK? what do you think?

thanks,
Jan

Originally posted by JanHH:
[b]Hello,

my terrain engine is going to be quite flexible. The terrain consists of severl 10,000 or even 100,000 or more triangles, some of which are lit with standard OpenGL lighting, without any bump mapping/ppl, but with the possibility of using all four (gf 4 ti) texture units for color textures (my client wants to have this possibility), while others will be drawn in one pass with bump mapping/ppl with NV_register_combiners, while other parts are draw in two passes with ARB_texture_env_combine, and what is used can change quite often.

So it seems that a lot state changes will occur, enabling and disabling NV_register_combiners and ARB_texture_env_combine again and again.

Will this take up so many time that the idea is completely pointless or is it going to be OK? what do you think?

thanks,
Jan[/b]

My sense from your description is that you may have a handful of terrain states, despite the large # of triangles. If you can sort the different parts of the terrain into state bins and draw those bins coherently, it shouldn’t be a problem state-wise. For the multipass states, once you bind a bin, draw it multple times, for example. This way, the number of state changes is almost completely independent of the amount of geometry.

Other than that, there may be issues with the # of triangles needed to simulate a good terrain. 100,000 drawn into a 800x600 window, for example, would be overkill. But you’ll have to deal with your geometry issues separately.

Avi

I already thought of sorting the triangles by states. I can’t do anything about the number of triangles, of course it was just an example, there are not 100,000 of them drawn at the same time, the whole terrain consists of several 100,000, which are split into segments (tiled), each of which is put into one display lists.

Jan

imho, the best and fastest method would be to prerender your blended texturetiles into one big texture, and then render your terrain using this texture (or a few of them) ideally in a single pass. Depending on how much different tiles you have and how much you move inside this terrain, it would be also accepatable to implement some kind of caching system, to prerender the needed tiles into a pbuffer on the fly. assuming you render this terrain state-sorted this method should reduce the state chaanges a lot.