View Full Version : Rain simulation
03-05-2007, 01:42 AM
I am planning to enhance my particle system, and I saw in some demo, that they have an image transition-animation that depicts images of drops splashing on the floor so that rain splashes are faked.
I am planning on trying to do the same thing, mapping my flat floor with the "animated texture",however my question is:
How do I make an "animated texture" in opengl?
The only idea that occurs to me is to have a single texture that measures for example (16)x(16 * NumberOfFrames) and to move the texture coords in every frame by 16 and then loop.
Any better suggestion? Or any other way to do it so that performance stays at it's best?!
Thanks so much!
03-05-2007, 03:14 AM
Why won't you use a 3D texture? The depth part can be used as frame stack... But won't it be better to use point sprites for drops? I can imagine that a texture would look blurry and/or too regular.
03-05-2007, 06:30 AM
yes i am using point sprites for drops, I want the textures to draw the "water splashes" on the floor.
So 3D texture is faster? Never used that before....
Is it widely supported?
03-05-2007, 11:43 AM
3D texture is part of GL1.2, so I gues it is supported :) It may be a bit slower then 2D textures.
> yes i am using point sprites for drops, I want the > textures to draw the "water splashes" on the
I mean you can draw the splashes with point sprites too. If you use a single texture for the whole floor, it may look blurry (if it is not large) and regular (if it is repeating). Point sprites can be animated independently.
03-05-2007, 04:40 PM
you say to use point sprites for the splashes?!
But point sprites don't support texture transforms, so how could I move the texture coords to obtain the other images?
I would have to use several BindTexture calls, and that would be too slow...
Is the 3D solution proposed faster than translating the texture coords and having a 16x (16*NumberOfframes) texture?
03-06-2007, 06:12 AM
Who said that glBindTexture ist slow? Don't confuse it with glTexImage2D. The latter has to transfer the image data to the memory on the graphics board, so it is slow. The former, on the other hand simply sets the current texture of the active texture unit to another object. Blazingly fast. If that was slow, Doom 3 would be in trouble. ;)
Back to topic:
Animated textures in OpenGL can be done in the following way:
1) generate texture id's for all the frames in the animation
2) call glTexImage2D for each animation frame (with its own id, of course)
These two steps should be performed during the setup phase. The next three steps need to be done during the render loop:
3) choose a texture object according to the frame's current animation phase
4) bind that texture object
5) render the quad or point sprite or whatever
If you cannot determine the number of frames in the animation (e.g. when you are displaying streaming video), use only one texture object and update the image each time a new animation frame arrives using glTexSubImage2D. This is faster because the geometry of the texture object does not change, so the driver needn't bother changing it.
03-06-2007, 07:00 AM
glBindTexture IS slow and should be minimized. It has similar overload to switching shaders or framebuffers etc. Switching the texture for each particle is of course not acceptable (well, you could render similar textured sprites in groups). Hovewer, it was new to me that ARB removed the POINT_SPRITE_R_MODE_NV part... Vertex shader won't help either, because the coordinates will be replaced anyhow. You could use a fragment shader to offset the r part, but I am not sure if it is acceptable for you.
03-06-2007, 12:43 PM
Originally posted by Zengar:
You could use a fragment shader to offset the r part, but I am not sure if it is acceptable for you. You are talking about changing the 3d texture coords with a fragment shader?
I am trying to avoid for now, the use of shaders: is there any solution without shaders that approaches to more or less the same performance obtained by your method?
Thank you so much!
I am thinking... I DO have to call glBindTexture at least once per frame before I render the particle system. So if I apply the same call changing the ID in every frame that would be a good solution and better than using a 3D texture and changing the coords, wouldn´t it be?
I don´t understand the need of a 3D texture, as glBindTexture NEEDS to be called at least once per frame. Or is it that having less Texure Objcets is better?
I saw in an example where they had 1 Texture object with all the frames drawn, and they would apply gltranslate texture transformations to get to the next frame.
What is the best approach?
Thanks so much everyone!
Powered by vBulletin® Version 4.2.2 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.