Procedural Texture Problem

Hi everybody,
I'm starting coding with OpenGL and I would like to map a fire texture ( this texture would be generated in real time ) on a cube.
The problem is: how to do this ?? since it seems that using glGenTextures, glBindTexture
and glTexImage2D primitives dump the texture data to the video memory.
I think that calling those functions would be a loss of time. So is there a way to make the
video card point to the RAM or is there a buffer inside the video card which I could use to generate my fire effect.

I hope someone would help me. I didn't find this question on any forum so ...

Thx in advance

-Greg

[dmy]

had the same problem some time ago.

there's no way to obtain a pointer to some buffer allocated by opengl, almost up to now.
this is due to design restriction for decoupling hardware from upper layers.

the specs states glTexSubImage is the preferred way to update texture data:
by various tests i made, it's true.

you have to:
-create a texture the common way, with a call to glTexImage2D, glTexParams and so on
at application startup
-update the texture with glTexSubImage2D every time you need.

glTexSubImage is faster since it rely on the fact that opengl has allocated it's buffers yet, so it have to only transfer data (mainly)

glTexImage, allocates (or reallocates) the buffers everytime it is invoked, and then sends data.

rule of thumb, keep the size of your procedural texture as small as you can !

i have a fire demo i can send you to see how it works, if you need...

Dolo/\/\ightY


[This message has been edited by dmy (edited 02-21-2000).]

[Eric]

Bad news, you can not do that without specifying the new texture.....

You should use glTexImage2D (or glTexSubImage2D if only a portion of the texture changes) on each frame...

If your texture follows a cycle, you can try to specify all the textures at once (but then you will probably run out of video memory if the texture is big and the cycle is long !). You can also try to fit all your textures in one big texture (same problem !) and then modify our uvw coordinates.

I think there is no way to avoid a call to glTexImage2D on each frame....

Sorry.

Eric

[Eric]

Hey dmy, it's the second time we answer at the same time (do you wanna fight ?!?!?!?!?).

Anyway, your answer is better than mine (didn't think about those buffer-allocation things !).

See ya !

Eric

First, thanks a lot
I find it a good idea to share your knowledge


Well, I'll try to do it the way you both said
I've already implemanted a 2D fire effect ( thanks to HTK for his sample code, he provides a great way to generate a very realistic palette) but thx for the proposal

So it's ok for the texture ( half of the work is done !! ). I'm going to work more, I just hope that it will be fast enough to make it realistic. Finally, I tried to make the difference between 2 texture frames: there are too much differences -> so I'll have to update the whole texture each time.

See ya , Greg
(Keep fighting for answering as fast & as well as you can !!! )

[Marc]

I wanted to do an animated fire-texture, too, but I didn't want to map it onto a cube...
I load the new texture whith glTexImage2D every new frame. And here comes the point: yesterday I replaced the glTexImage2D with glTexSubImage2D because it should be faster (dmy). BUT it got a drop in framerate from 77fps to 65fps!!! (PIII500, RivaTNT (Viper550), Detonator 3.68 drivers, WinNT) So I will continue to use glTexImage2D (no other 3D-accelerators available).