i’m using lots of vertex arrays for objects in my game.
i’ve written a vertexArray-class which can execute the vertex array it holds, it offers several bonus options etc. etc.
my idea was to replace this class by an 100% compatible one which offers the same function, but is just better and/or faster. -> i wouldn’t have to re-code my engine.
i don’t want to use vertex array ranges because there is (still) no arb-extension for them, so i want to give compiled vertex arrays or indexed vertex arrays a try…
my question is, what could i do to improve the performance or to reduce the memory that is needed ?
i know that if the array contains just quads, and there are 2 quads sharing 2 points, i could draw them one after another (instead of just drawing them in random order) and make use of the vertex cache (right ?) by sorting the array.
i’ve heard i could also save memory by re-use verticles that have already been calculated. is this true ? if yes, how is it done ?
One of the main reasons to encapsulate a vertex array like this is so that you can easily write code for VAR or VAO without having to change the interface. So, you may as well go ahead and implement VAR/VAO versions of these classes, especially considering than an ARB extension is fast approaching.
my question is, what could i do to improve the performance or to reduce the memory that is needed ?
If you’re already using indexed vertex arrays, you’ve, pretty much, achieved all you’re going to in terms of memory gains. You could, however, consider using smaller sizes for your vertex attributes (say, shorts for texture coordinates, etc).
As far as performance, CVA’s may buy you something, but they are most effective in the case of multipass rendering. Your best bet for improved performance is to go to VAR or VAO. You should be able to implement such systems without having to change your interface.
Knowing that this is for the trees… By optimizing your vertex arrays, you can get up to 100% speed increases, I think, but that’s not going to help you much if forests are what you have in mind. With decent LOD you can make far more concrete speed increases, you basically have to do it at some point. Billboards are very good to start with.
what is a billboard ?
do indexed vertex arrays (i found out how to use them ) just decrease the memory usage or can they also increase the performance ?
@shorts for texcoords : how to use the coordinate 0.1f 0.2f as shorts ?
Billboards are oreiented toward the viewpoint, they rotate as your viewpoint rotates with respect to them. You can also benefit from them by switching from using blend to alpha_test on the billboards in the distance, you can also rotate the more distance billboards on a less frequent basis than the closer ones. These LOD techniques, and others will give you a far greater performance boost with little or no degradation in visual quality than any brute force vertex pushing technique ever will.
Heath.
[This message has been edited by heath (edited 02-16-2003).]
Originally posted by JustHanging:
[b]Yep. You call it old school, I call it multiplying the amount of detail in your scene by a BIG number. If it’s far, draw it fast, and draw lots of it.
-Ilkka[/b]
i’m already doing it
So you don’t use imposters then?
Your scenes must look so empty…
? the englishpart of my brain doesn’t knoe the word “imposter”
It means someone or something trying to pretend that it’s something else.
Typically, when you generate impostors in graphics, you render the single object from the point of view of the camera into a texture, and then keep that texture around and re-use it until you camera position/view has changed “too much” at which point you re-render the thing.
Another common way of doing trees it to just create cruciform, cut-out geometry. By the time the player gets close enough, you’ve already lodded in a full-geometry instance. Usually works very well, as long as you can make lighting work right.
The cool thing I realised yesterday about impostors is, that you can actually make one from a group of trees. When the trees are relatively close to the viewer, you would have only a couple of trees in the same impostor, but in a distance you could draw dozens of trees with the same impostor. Now they finally start to make sense to me (when used with trees), they could actually beat the billboards in speed if used wisely.
You’ll want to be a bit careful when grouping multiple objects into a single impostor, though. If you have a bunch of trees on a rather steep slope, the resulting impostor might intersect the terrain causing the trees at the bottom of the slope to disappear into the ground.
You can try to avoid this by only grouping objects that are at approximately the same distance from the camera. Another trick I’ve seen (Tom Forsyth’s Game Programming Gem on impostors, iirc) is to draw the bounding box (AABB or OBB) of the geometry instead of a single billboard, and to project the impostor image onto the box.
Beware though: you may run out of texture space if you get a dense forest. Meanwhile, billboarded trees can all re-use the same sets of textures.
If you draw impostor groups at the location of the closest entity in the group, you will minimize terrain intersection problems, but you’ll have to re-generate more often (higher sensitivity to movement) to avoid parallax problems.
) just decrease the memory usage or can they also increase the performance ?