POV-Ray : Newsgroups : povray.binaries.animations : Turbulous Problems... (WIP, 362kb MPG1) : Re: Turbulous Problems... (WIP, 362kb MPG1) Server Time
19 Jul 2024 07:18:08 EDT (-0400)
  Re: Turbulous Problems... (WIP, 362kb MPG1)  
From: Tim Nikias v2 0
Date: 6 May 2003 11:47:16
Message: <3eb7d904@news.povray.org>
You're answer doesn't make much sense to me,
which I assume originates in a misunderstanding
of what the animation is supposed to show.

The System is a set of Macros which will simulate
liquid surfaces like the one presented. These are
User-Defined but refer to a rectangular shape, and
are based on nodes.
To add waves into the simulation, there are several
macros, which add either a drop, or entire wave-fronts.

"Stomp" is one of the wave-front types, it will add
a wave surrounding all objects in the water and
interacting with it.

In this case, a problem becomes apparent: in tight
corners, the step-calculations run into trouble
when there are too few neighbours for useful smoothening
of the waves. That's something I want to avoid before
releasing the system.

The scene itself is just a test-scene to check the
algorithms and if they're working properly, its not an
actual scene I'd use in an animation.


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

> Um?
>
> I'm not sure its wrong. I think you have chosen a starting point that is
> very unlikely. I think the block and the side form a sort of channel. It
> looks like you have started with water up the side of the block. This is a
> bit strange. Channels usually have waves going up and down them and not
all
> the water piled up on one bank.
>
> I think if you chose a better starting point it would be better. Perhaps
> take one of the surfaces later in the render where the problem has died
down
> and feed it back in as a starting point multiplied up a bit.
>
> You will probably get similar funny effects if you start with the water in
a
> cube shape and just "let it go".
>
>
> Ta BB.
> --------------------------------------------------------------------------
-
>  Bill Bagshaw                                     Tel +44 (0) 117 929 9733
>  SN Systems Limited                               Fax +44 (0) 117 929 9251
>  sup### [at] snsyscom                                         sal### [at] snsyscom
> --------------------------------------------------------------------------
-
> The views expressed in this message do not necessarily constitute the
views
> of SN Systems Ltd and information in this message is confidential and may
> be privileged.  It is intended solely for the person to whom it is
> addressed.  If you are not the intended recipient, please notify the
sender
> and please delete the message from your system immediately.
> --------------------------------------------------------------------------
-
> "Tim Nikias v2.0" <tim### [at] gmxde> wrote in message
> news:3eb78ed6@news.povray.org...
> > So, I had mentioned releasing the Liquid-Surface-System
> > to the WWW this weekend, but stumbled upon a little
> > unpleasing artifact which may occur in tight corners,
> > especially when the wave is created there, e.g. using
> > the Stomp-Macro, which places a wave around all objects
> > interacting with the water.
> >
> > Anyways, as you can see in the edge at the red box, there
> > is some weird jiggling going on, and I'm working on the
> > dampening and internal multiplying parts (which take
> > care of dissipation of waves and retaining the hills) to
> > work slightly different dependant on amount of neighbour-
> > nodes.
> >
> > Anyways, this animation isn't to show off any features or
> > such, its an excuse why its taking so long... :-)
> >
> > I was thinking about adding an algorithm which checks
> > if there is a checker-like pattern (all horizontal and vertical
> > neighbours are of a much different height than the one in
> > question) and adjusts the height of the center node to a
> > certain degree. This would add a whole new loop, because
> > I'd have to do this after the step has been generated completely,
> > and needs to take dead and rim nodes into account, which
> > implies that I'd have to put a larger effort into that, then a
> > next bug-testing phase... Would result in at least another two
> > or three weeks of programming. Well, I'm thinking about an
> > easier solution right now, and hope to get something useful
> > till the weekend. Sorry for the delay!
> >
> > Regards,
> > Tim
> >
> > --
> > Tim Nikias v2.0
> > Homepage: http://www.digitaltwilight.de/no_lights
> > Email: Tim### [at] gmxde
> >
> >
> >
>
>


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.