I am working on a landscape engine at the moment and the idea to win speed was following:
-all fields stored on board (video memory)
-only fields which appear are updated, using
the memory region of the fields, which now
got invisible (through changing
position/viewangle)
The problem all in all is now of course, that the indexbuffer looks like following (psuedo):
138,20000,42000,3000,55000…
That it’s of course far better if I had them in an order like 0,1,2… I know too, but how I don’t know how the memory management of the GPUs work… so… is this the absolute overkill or something still surviveable? The reason why I’m managing it this way is not, because I smoked something wrong too much, but simply because the memory transfer and the field calculation cost so much in the last engine, that I didn’t want to do the same mistake again. On the other hand the T&L memory is of course heavily limited, so I want to save as much as possible through vertex sharing. I know that the post T&L cache can’t make any use of this in my case, but I can this way save 75% memory space.
But all in all this results of course in this hopping… so… doable this way, insane this way… and if insane, does someone have a better idea how to manage a case like this one?
Michael