Ripple Water Surface Animator

powerpop · Post by **powerpop** » Wed Jan 14, 2004 9:49 pm

Here is my first attempt at a water surface that ripples as if rain were falling on it. In the demo I have a high poly water surface so it may be slow if you have an older card. On mine I get about 70fps. I have packed up the demo (based on my ping code) so you can see it in action. Separately I packed up the source and samplecode for you to insert this in your project.

The SceneNodeAnimatorRipple takes a mesh to work on. It makes two arrays of floats to handle the ripple height (previous and current) - this is a bit memory intensive - i am wondering if i could get away with shorts instead or smaller ripple arrays that could overlap (almost like a surface particle system). The cool thing about having the whole surface as an array is that i could add waves and other perturbations of the water surface and they would all work out over time.

right now the animator paces itself to update every 80 milliseconds - its hardcoded in - i could expose it in the constructor but i would rather wait until the next irrlicht release and do something better with time management of animators overall - i think it would be good to have a timeslice manager that triggered these at set intervals rather than each animator doing a time test internally and being called every frame

well, here is the screenshot that sucks - only one ripple in the lower right - it looks MUCH better in action (if you take a better screenshot post it - ripples are hard to catch in action)

the runtime app can be found here:
http://www.ping.net/snapshots/ripple1.zip

and the sourcecode for the ripple animator is at
http://www.ping.net/snapshots/ripplecode1.zip

Cleves · Post by **Cleves** » Wed Jan 14, 2004 10:17 pm

Hey,

Wow, this is really nice, the ripples like good.It reduces my FPS by 20, so i'm left with 140.It's quite a lot 20 for such an effect, don't you think?

P.S. The reflecion on water isn't adjusted to the real view.

powerpop · Post by **powerpop** » Thu Jan 15, 2004 1:16 am

its a first version - i need to look at it now and figure out how to speed it up - i am sure there are things i am doing that could be faster - so hopefully i can squeeze back some of those frames per second! - one thing i want to look at is going to ints or short int for the ripple height arrays - and i am not sure how many polys are actually being displayed with the water surface - there is no doubt that manipulating vertices in large numbers is going to be expensive - its using CPU time rather than GPU - this might be one of those nice things to put in a cg script once that is added to irrlicht - hint hint

keless · Post by **keless** » Thu Jan 15, 2004 1:54 am

you should definately use shorts-- you should only be modifying a 'shift' vertex (the vert's height shifted up/down) which means you dont realistically need to worry about your shift vectors being in the range of 64 bytes.

Furthermore, if you dont mind limiting your animator to the axis, you only need to store one shift scalar (not a vert), which will only be applied to the appropriate axis.

Also, using the 'shift' method, you can check to see if the shift is below a certain threshold, and if so, dont apply the shift. This way when most of the verts are not in motion, you will spend only one check on them instead of an addition.

powerpop · Post by **powerpop** » Thu Jan 15, 2004 2:35 am

keless - you mean use a shift operation instead of an addition - its been a long while since i did bitwise operations - can you give me an example - if i have a short int that has a 5 in it and a vertex where i want to shift the y axis up - how would that look?

and in my code currently i am not using arrays of verts, just f32 - so its not as bad as if i had three f32s per point (eek!)

keless · Post by **keless** » Thu Jan 15, 2004 2:41 am

ah, no i didnt mean a binary shift. I meant simply a variable that would be added to shift the current vertex, as opposed to modifying them directly, or having a second vertex (yes, yikes).

so, yes, use f16, (or even f8 if you can be sure your algorithm will only push the verts by at max +/- 127 units ).

powerpop · Post by **powerpop** » Thu Jan 15, 2004 6:36 pm

irrlicht doesnt have f8's or f16 so i had to use f32 still

but i made some other changes to the code that sped things up considerably - like storing the pointer to the vertices - and the vertex count - so it runs about twice as fast!! - i updated the downloads to the new code and runtime

keless · Post by **keless** » Fri Jan 16, 2004 2:43 am