Hello,
it seems that my programm once I use mipmapping, it wants mipmaps for every texture. I normally generate textures with glTexImage2D and SGIS_generate_mipmaps, but for my cloud impostor textures, I do not want mipmaps so I only use glTexImage2D without SGIS_generate_mipmaps, and voila, there are my white quads instead of clouds everywhere. Does anyone have any experiences with this, with NOT using mipmapping?
ok i got it, the problem was the filtering (doesn’t like GL_LINEAR_MIPMAP_LINEAR when there are no mipmaps). But another problem:
I render clouds as impostors (billboards). So, for every visible cloud I need a texture. These textures are 256x256 in RGBA format, making four of them taking 1 MB of RAM.
So, with 40 clouds, I alreay fill 10 MB of video memory, and I rahter would like to display about 200 clouds at one time. But when I do so, the texture swapping (I guess it is that) slows down the program to nearly a halt. Is there any workaround for this?
Thanks
Jan
Do you need to have your clouds in RGBA format? Will Luminance/Intensity-only do?
Can you generate the clouds proceduraly using ARB_fp?
[This message has been edited by al_bob (edited 08-01-2003).]
I don’t understand this. Can’t you use the same texture in memory (or the same three or so for variety) to render every one of the clouds, why there have to be multiple instances of the texture for every cloud? (say there are a 1000 clouds that would take up a lot of mem) especially if they are the same texture?
Can somebody clarify this, i thought you just load up an instance of the textures you are using and apply them wherever you want? Why the extra memory usage for every texture?
I also don’t understand this.
If you have a texture for each cloud, you mean that every texture is different? If so, you may just go for drawing the cloud directly w/o impostors!
I think the best way is to use 1 single, shared texture. If you are a little more involved, I would generate up to [n] textures, each from a different point of view (that I would have to choose carefully) and assign each texture to a cloud, depending what is more similar to the view…
200 cloud textures with 256x256 each represent 13 million pixels worth of information … overkill.
of course the textures/clouds are different, see
http://de.geocities.com/westphj2003/clouds.html
and they are rendered as impostors due to performance reasons, because drawing a cloud with several thousand particles takee some time, but the cloud is rendered to the impostor texture which is then rendered to the screen onto a quad, and the trick is that the impostor texture does not have to be updated every frame, but only if the angle or the distance to the viewer has changed a certain amount. With this technique, you can render far more clouds and achive far more fps than with rendering them directly to the framebuffer.
So, as the impostor texture of a cloud is reused for several frames, it can not be shared with other clouds.
I have already reduced the size to 128x128 and not use mipmaps and it improves a little bit, but still not enough sigh. I really guess the only possibility is to reduce the number of clouds that are visible at the same time (and of course i use a shared texure pool, at the moment 70).
Jan
but I think that intensitiy-only is a good idea, which is the texture format for this?
thx 
maybe it would be a good idea not to use several different textures, but one large (1024x1024), which is then spilt into 64 tiles of each 128x128, which would (I hope g) constantly stay in graphics memory, so the swapping does not occur?
althoug no one has answered (do you at least now understand the idea behind it?), it works (my last post, only use one texture that is splitted).
Jan