James Turner a écrit :
On 17 Oct 2004, at 10:15, Erik Hofman wrote:
Before other people think "WOW, FG could run 60% faster!!!", please keep in
mind that an application like FG can't do everything just by using VBOs and DLists.
For what it's worth, experts keep telling me the display lists are always faster than VBO's anyhow. The advantage of VBO's comes when you want to use non-static data like morphing.
That and the fact that all drivers seem to support display lists at the moment make me believe we should stick to display lists a little longer.
That sounds totally incorrect as I understand it. VBOs are essentially the same ideas as vertex arrays, but with more control over which memory they are located in (system, AGP or GPU) and with how they will be updated. They can be used for 'streamed' vertex data such as skeletal animation and morphing (by specifying that they should not be GPU resident) but for FG the benefit (which should be large) would come from placing each tile (or other large data set) and mesh onto the GPU as a fixed, resident VBO.
You are wrong here as long as FG will use state changes ( read different textures ) to represent terrain property ( forrest, crop, urban ). You can't put state changes in a VBO, so you end up with multiple, small VBOs that is worst than display lists.
That could be different with another terrain engine that would drape a single, large and unique texture on a single tile made with a single geometry object.
People arguing for VBOs are always forgetting this reality.
-Fred
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
