particles/vbo

  1. seems to be a good idea, the same I have done with the impostor textures, there is a pool of 64 that the clouds share (in fact, one large with 64 tiles). So I would need 64 buffers that the clouds share, each has to be of the larges clouds’ size.

a particle has 4 vertices and one color, each vertex has x, y and z, and tex cooords (point sprites are out of question).

so each vertex has 12 (x y z as float/4 byte) plus 8 (tex coords) = 20 byte, this four times = 80 byte, plus color (r g b as unsigned byte), making 83 bytes for each particle.

lets say, the largest cloud has 6000 particles, this makes 83 x 6000 = 504000 bytes for one cloud vbo (not counting the index data), roughly 512 kb. so 64 of them would take up 32 mb of graphics memory data.

so even if I trust the (linux g) drivers, I hardly doubt that this will run smooth (and there already is lot of other data in the graphics card memory. whole germany geometry data as display lists ).

So you see where my doubts come from.

well i guess vbo might really not be the right choice for this amounts of data. but at least normal vertex arrays should do the job of removing the funcion call overhead immediate calls do generate

Not related to vbo’s, but your clouds look pretty good, any chance of getting more information about it?

regards,
Stephan

thanks they are basically a very simple implementation of mark harris’ “skyworks” technique. you find it here:
http://www.cs.unc.edu/~harrism/SkyWorks/

and the clouds itself are particle clusters, generated with a 3d perlin noise function, modulated with a distance attenuation function to make it more “round”. it’s really not very complicated work.