I'm not sure what you're after with "energy" and
"log curve"... Care to explain?

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>     Stunning!  If you get your energy to follow a log curve instead, it
will
> dampen and stay there instead of growing out of control.
>
> Cheers!
>
> Chip Shults
> My robotics, space and CGI web page - http://home.cfl.rr.com/aichip
>
>

Post a reply to this message

Behold! Ulmo is rising!


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

I haven't seen the code you use to produce the waves, but wave height is
equivalent to energy.  And since the waves continue to grow behind obstacles
rather unrealistically, it means that your "bookkeeping" of the height has an
error somewhere.  Real waves become broader rather than taller, and in some
cases they will spray droplets.
    My thought is that if there is too much involved in getting the energy math
right, it may be easier to use logarithms for the height rather than completely
redoing it all, and then the peaks will be severely curtailed instead of growing
so large.

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

Post a reply to this message

:-)
So, are you another one of those
LOTR-Fans?

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

> Behold! Ulmo is rising!
>
>
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] vipbg
> TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

The algorithm I use is pretty simple: I store
the heights, smoothen these outward onto neighbouring
nodes. To save parsing time, I leave out nodes which
are inside objects, which seems to produce the
error in this case: since the blocked nodes aren't
processed correctly (and thus aren't set to 0), they
add up and spill over later. Need to check more thoroughly
on that.
If you want, you can have a look at the source-code,
just head on to my homepage, in the downloads-
section.

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>     I haven't seen the code you use to produce the waves, but wave height
is
> equivalent to energy.  And since the waves continue to grow behind
obstacles
> rather unrealistically, it means that your "bookkeeping" of the height has
an
> error somewhere.  Real waves become broader rather than taller, and in
some
> cases they will spray droplets.
>     My thought is that if there is too much involved in getting the energy
math
> right, it may be easier to use logarithms for the height rather than
completely
> redoing it all, and then the peaks will be severely curtailed instead of
growing
> so large.
>
> Cheers!
>
> Chip Shults
> My robotics, space and CGI web page - http://home.cfl.rr.com/aichip
>
>

Post a reply to this message

Great work, Tim! This may be a misuse of your macros, but it seems like it
could work.

> Would probably be better to use a similiar approach
> (node-based calculations for a mesh) and generate some
> basic flow data and then superimpose some random waves
> onto that to get a similiar look.

Interesting comment. Where can I read about this? I only have a vague
understanding. I think it's possible to precalculate data (one normal vector
for each node) with reference for the wave direction. This means, there will
be an overall direction (the wind) for the waves, and there will be a
sublayer where the waves go in all the directions that is specified by the
precalculated data... But how to push these subwaves around, within a
reasonable time, I don't know...?

Best regards,
Hugo

Post a reply to this message

Okay, without looking at the algorithm directly (which I will do shortly),
here is my take from a physics standpoint.  Then I can see what you have and
whether this is useful or not to you.
    Imagine the body of undisturbed water as a set of blocks.  Each block will
have a height.  Now, no matter what is done (without adding or removing water),
we know that the average height of all blocks must remain constant at all times.
    Now, let's look at waves and ripples.  You can model them as an array of
scalars, and each location of the array is applied to the array of blocks to
alter their heights.  This array describes how the water surface will change
from moment to moment.
    But now, we see that a third array, one that modifies the scalars, is
needed.  It controls the viscosity (as a single parameter for the whole body of
water at once) and the damping factor and it stores the modifiers for the
scalars.  This second derivative is where the action would be.
    But when we turn it on its head, this array is really the "water" so to
speak, and the scalars are its first derivative, and the water surface is the
second derivative, and it is completely dictated by it.  If you make fixed
points in this third array, it will automatically "fix" the overflows, I would
think.
    I am going to continue to consider this and see if I can make a useful
"wireframe" animation in realtime first.  Then it should be written in C or
something and done on the computer screen directly.  Then the addition of water
becomes a volume added to a point and its velocity or energy, and the rest will
follow from there.
    Or maybe I am a complete loon...

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

Post a reply to this message

The technique you describe assumes a volume-preserving
attempt at modelling the water. This isn't done in this
algorithm. All it does is raise some nodes of the mesh,
aka the wave-height. This height is spread out using a
smoothening step. In order to not just smooth it out, but
create wave-fronts, I subtract the waves of one step
ago. Thus, only the newly smoothened heights, passed onto
neighbouring nodes, stay unaffected of the following
subtraction, as they have nothing to subtract. This technique
is then done once per frame, and thus I get waves travelling
from some origin onward until the smoothening and
dampening process has taken care of removing the wave.

The problem that seems to appear here is that although
waves are moved downstream by moving the data of the
nodes "downstream" (remember, I'm not moving the nodes
themselves, just the data contained therein), waves do
spread out in all directions. It seems that behind the boxes,
I add no height from former waves (as waves have zero
height inside the blocking objects), but spreading waves
will still move there. But I'm actually not too sure about
the origin of the side-effect. Could be this, or some
other thing, like waves adding up inside the blocked nodes,
and finally emerging behind them... I have an idea how
to check that though, but otherwise, it seems a pretty
difficult thing to achieve with this algorithm...

But I'm interested in what you get cooked up, so
please keep me (and others) updated! :-)

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>     Okay, without looking at the algorithm directly (which I will do
shortly),
> here is my take from a physics standpoint.  Then I can see what you have
and
> whether this is useful or not to you.
>     Imagine the body of undisturbed water as a set of blocks.  Each block
will
> have a height.  Now, no matter what is done (without adding or removing
water),
> we know that the average height of all blocks must remain constant at all
times.
>     Now, let's look at waves and ripples.  You can model them as an array
of
> scalars, and each location of the array is applied to the array of blocks
to
> alter their heights.  This array describes how the water surface will
change
> from moment to moment.
>     But now, we see that a third array, one that modifies the scalars, is
> needed.  It controls the viscosity (as a single parameter for the whole
body of
> water at once) and the damping factor and it stores the modifiers for the
> scalars.  This second derivative is where the action would be.
>     But when we turn it on its head, this array is really the "water" so
to
> speak, and the scalars are its first derivative, and the water surface is
the
> second derivative, and it is completely dictated by it.  If you make fixed
> points in this third array, it will automatically "fix" the overflows, I
would
> think.
>     I am going to continue to consider this and see if I can make a useful
> "wireframe" animation in realtime first.  Then it should be written in C
or
> something and done on the computer screen directly.  Then the addition of
water
> becomes a volume added to a point and its velocity or energy, and the rest
will
> follow from there.
>     Or maybe I am a complete loon...
>
> Cheers!
>
> Chip Shults
> My robotics, space and CGI web page - http://home.cfl.rr.com/aichip
>
>

Post a reply to this message

> Great work, Tim! This may be a misuse of your macros, but it seems like it
> could work.

Thanks, but no, its no misuse. Its using the system for something it
wasn't originally designed for, and thus requires more testing and
fiddling. And since the Pre-Processing-Macro is an "inbuilt" part
of the LSSM, its more like an unstable first attempt, than a misuse... :-)

> Interesting comment. Where can I read about this? I only have a vague
> understanding. I think it's possible to precalculate data (one normal
vector
> for each node) with reference for the wave direction. This means, there
will
> be an overall direction (the wind) for the waves, and there will be a
> sublayer where the waves go in all the directions that is specified by the
> precalculated data... But how to push these subwaves around, within a
> reasonable time, I don't know...?

I actually have no idea where you could information on this. I tend to
cook some stuff up myself most of the time. In this case, I'd say I'd
go create the nodes, check which ones are blocked, and then decide
which ones are the "front blocking nodes", meaning the nodes into
which the moving water crashes head-on. Then I'd find the contour,
and try to create some surrounding waves based on the
info I have on stream-direction, blocking nodes, etc. With this
approach, one could also easily try to reproduce those waves which
appear in shallow regions, where the masses move on top of some
boulder and cause a peak on the surface...
Anyways, once the basic flow (which would actually be more like a still
frame from a river) has been generated, I just take some height-data
(probably generated using a function-image of a pattern or such) and
add it onto the nodes' heights. This added height-data may be translated
along some direction and thus add a moving effect onto the base-waves,
and when slightly modifying the function-slice itself, the waves would
also seem to change and move on...

Parsing-Wise, the first generation of the base-flow would be time-consuming
I guess, after that, you just need to generate the mesh for each frame by
parsing through each node and adding the appropriate function-value...
-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message

On Thu, 29 May 2003 18:41:43 +0200, "Tim Nikias v2.0"
<tim### [at] gmxde> wrote:

>:-)
>So, are you another one of those
>LOTR-Fans?




Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message