|
|
Looks pretty neat, though the waves of the water look
kinda strange, with strange peaks when being hit
by a ball.
But that's probably due to the algorithm.
So, you're using no collision detection, but
elasticities... Are you using lots of springs and
forces for that?
Christoph Hormann wrote:
> I started working on a physically accurate mechanics simulation system,
> here is one of the first results.
>
> One feature of this simulation is that it does not use any impact
> calculations but simulates collisions with elasticities. As visible from
> the animation i choose quite high elasticity, this makes numerics much
> easier, but with small enough integration steps this can be changed.
> Using this method you can completely avoid testing a lot for possible
> collisions, even in complex environments. I just converted the scene
> geometry to an iso_rcsg function and this way can check any time how near
> the different balls are to the surface.
>
> I also tried modeling the water interaction using the same method as
> recently shown by Rune. In contrast to the other things this is not
> physically accurate of course. What's really difficult about this water
> trick is synchronization with the rest of the system, you have the
> discrete simulation steps and cannot change the speed continuously. Apart
> from that it's also quite a problem to find the right disturbance from the
> balls reaching the surface that creates an appropriate wave. A lot of
> factors have to be taken into account. Right now the disturbance only
> depends on the sign of the ball's speed and not the speed itself meaning
> fast balls have the same effect as slow ones, just the direction makes a
> difference.
>
> Some more facts about the animation, it's slow-motion 1:2 in fact, the
> balls have a density of 5 g/cm^3 and a radius of 0.15-0.45 m. Stiffness
> of the environment is 100000 N/m. Buoyancy and damping during collisions
> is simulated, damping in water is not yet accurate.
>
> For integration i used simple Euler method, i also implemented 2nd order
> (Heun) algorithm, but without calculating the influence of the other balls
> twice, this takes most of the time naturally and environment collisions
> occur much more often. For this animation i used 17 steps each 1/1000
> second for each frame, but i presume if i use twice as many steps the
> final ball arrangement will look quite a bit different... ;-)
>
> But now enough words, here is the animation, a longer and better version
> can be found on:
>
> http://www.tu-bs.de/~y0013390/files/ball_sim1.mpg
>
> Christoph
>
> --
> POV-Ray tutorials, IsoWood include,
> TransSkin and more: http://www.tu-bs.de/~y0013390/
> Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
>
> ------------------------------------------------------------------------
> Name: ball_sim1a.mpg
> ball_sim1a.mpg Type: MPEG media file (video/mpeg)
> Encoding: base64
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
Post a reply to this message
|
|