-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 E. Wing wrote:
> So I am not doing geometry deformation. I am displaying a continuous > live stream of data as it comes in so I cannot programmatically > transform the data as far as I know so I don't think there is anything > useful I can do with shaders here. (If there is, I would be interested > in hearing more about it.) A common idiom is to upload a static vertex lattice to the VBO (e.g. a character body mesh in a default pose) and then on each frame to only change/upload textures containing displacement for the vertices or something that the displacement is calculated from by a vertex shader (e.g. the skinning matrices). This is also commonly used for terrain rendering from height fields - you do not generate and upload the changing terrain mesh as the camera is moving over it but you displace vertices of a static mesh by the shader instead, using the height map as a vertex texture. > The information I'm getting on VBOs is that > is essentially like DMA to the video card and it was intended for the > very kind of thing I am trying to do (hence the DYNAMIC and STREAM > values). The main advantage of VBOs is that you can store the data directly on the graphic card, no need to copy them from an application buffer to the GPU each time. However, this works best if the data are not really changing "much", e.g. you are only moving the vertices but not adding new ones and such - i.e. the GPU can reuse most of the data. If you need to upload a fresh buffer of new vertices on every frame and the vertices cannot be reused, the VBO will not get you a lot of benefit over straight vertex arrays and cause the application to break on older GPUs which do not support them. The "DMA" comparison is misleading - it gives an impression as if the data transfer for VBOs was somehow faster than other things. It is not - VBO data, vertex arrays and display lists are transferred in the same way. The speedup is in how the data are actually used. My former colleague did a benchmark for character rendering and he discovered that: a) Display lists are by far the fastest if your data are not changing (everything is pre-computed and stored on GPU). b) Vertex arrays work best for streaming data uploaded to the GPU on each frame. Display lists offer no benefit here, because the pre-computed information would be thrown away on next frame. c) VBOs are faster than vertex arrays and compare to display lists if you can mostly reuse the data and do only partial updates. This is because you map the VBO into your process memory as a regular array and can modify e.g. 2-3 vertices only. With a vertex array this would be expensive to do (whole array needs to be transferred every time). However, if you need to replace all the data on every frame, the performance drops and is comparable or even a bit slower than vertex arrays due to higher overhead with managing the VBO. d) The direct mode (glBegin(), glEnd()) should be avoided at all costs - it is by far the slowest because each command is transferred as a separate block to the GPU - the overhead will kill the performance. You need to carefully benchmark your application on the target hardware - - the VBOs may only add complexity and not bring any performance improvements. In the above benchmark, the conclusion was to stay with straight vertex arrays because our animation and skinning code was on CPU at the time and VBOs didn't really bring any benefit. However, this was on GeForce 6 class of hardware, the newer GeForce 7/8 could be different - again, benchmark, benchmark, benchmark ... Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGhbbWn11XseNj94gRArCaAJ0eKJeoH28m34Ej65aIUNHUcNR20gCbB6ZN ZkQHTiiJGP5/nfGg7f65yc8= =kkly -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
