Although one can observe a little bit of how
it looks, the rotation is far too much (and as you
noted about the wrong point), and perhaps even
the resolution of the image is a little too small.
Perhaps one or two larger still images in
binaries.images would be sufficient.

Another thing of interest is the resolution of the
water-mesh and the parsing time.

Aside of that, it does look promising, but you
could showcase it better.

As for saving the mesh to disk: I don't know
how you're saving the data, but you could easily
use my I/O Scripts to save an array to disk
and load it for every frame.
Additionally, if the nodes of mesh are structured
in a 2D-Array, you may even use my Mesh-Modifying-
Macros to save the mesh to disk and load that
for every frame...

Regards,
Tim

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

> Here's a different method of simulating fluid flow in rivers, inspired by
> Tim Nikias' videos. The algorithm I'm using here is the one described in
my
> reply to his most recent post.
>
> The algorithm is a simulation of fluid movements that go through the whole
> depth of the fluid, as opposed to surface ripples. Perhaps for this
reason,
> the waves in this simulation are quite large, and my experiments with
> putting ripples from rain here didn't work - the ripples didn't propagate
> properly.
>
> I suspect the best results may be achieved by combining the large-scale
> waves around objects of this simulation with the results of another
> simulation of small ripples, caused by rain/splashing etc. I haven't yet
> tried this, and I'm not sure how well the two simulations could be
layered:
> ideally the ripples could be distorted by the velocity field of the
> large-scale simulation, which should avoid the wave stacking problem that
> Tim had.
>
> As the large-scale flow quickly settles down into a fairly stable state,
it
> might be possible to render one large-scale height-field computation and
> only animate the small scale details. Currently, the fluid dynamics is
> implemented in C++: if only one of the complex fluid dynamics calculations
> is needed for a whole animation, it may be possible to implement this in
> Pov-Ray to calculate once before the start of the whole animation render
and
> save the height-field for use in every frame.
>
> Please excuse the fact that the camera obviously rotates around the wrong
> point (:  Also, for the eagle-eyed, there is a slight discontinuity at the
> joins between the copies of the water height-field - I think this is a bug
> in the boundary conditions of my simulation which should be quite easy to
> fix.
>
>
>
>

Post a reply to this message