 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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 _____./\/^>_*_<^\/\.______
Post a reply to this message
Attachments:
Download 'ball_sim1a.mpg' (665 KB)
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Thats very, very nice...good work.
jim
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
the water is incredible and shows a lot of potential. whoa. that is
very impressive.
very- organic.
-p
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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] gmx de
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
James Taylor wrote:
>
> Thats very, very nice...good work.
>
Thanks!
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Dearmad wrote:
>
> the water is incredible and shows a lot of potential. whoa. that is
> very impressive.
>
> very- organic.
>
Thanks you.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Tim Nikias wrote:
>
> 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.
Yes, these are part of the algorithm although they are not unrealistic per
se, There is usually some kind of splashing after a body enters the water
because the water surfaces collide, but it's commonly not that smooth of
course.
> So, you're using no collision detection, but
> elasticities... Are you using lots of springs and
> forces for that?
You can't see this as individual springs, you simply have the potential
field of the environment and the other bodies and calculate the forces
from it.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> 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.
Interesting project you're having! Forgive my ignorance but how do you get
an output of the isosurface evaluation, for a point within the bounding
object? With the geometry in your example, is it really faster than using
primitives and individual col. testing?
Regards,
Hugo
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Very nice simulation!
However, even though the slow-motion playback often better show off the
details, I usually prefer real-time playback because it gives a much
better feel of how realistic the simulation is.
I see that you have also found the many problems with the water surface
algorithm that we're using... ;)
Anyway, keep up the good work!
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Hugo wrote:
>
> > 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.
>
> Interesting project you're having! Forgive my ignorance but how do you get
> an output of the isosurface evaluation, for a point within the bounding
> object?
I don't understand, you can evaluate an isosurface function wherever you
like.
> With the geometry in your example, is it really faster than using
> primitives and individual col. testing?
That's a difficult question.
Some arguments for the elasticity model are:
- easier to program and to extend to arbitrary geometries.
- with collision testing you can't modell soft collisions at all.
- it is surely faster for environment collisions than calculating the
distance to all planes forming the geometry by hand which would be
necessary to truly test for collisions (just tracing in direction of
movement is obviously not enough)
- edges are a serious problem with collision modelling. The movement of a
ball hitting the edge of an object is not defined since you can't
calculate the normal at the edge.
On the other hand you can use fairly large integration steps when using
collision calculation since the collision itself is not part of the
differential equation you are trying to solve. With elasticity you have
to use fairly small steps to get realistic results.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Rune wrote:
>
> Very nice simulation!
Thanks.
> However, even though the slow-motion playback often better show off the
> details, I usually prefer real-time playback because it gives a much
> better feel of how realistic the simulation is.
I will try making a real time version tonight, but you will of course see
less details there.
> I see that you have also found the many problems with the water surface
> algorithm that we're using... ;)
Yes. I found you can very well influence the size of the waves by using
different kinds of disturbances, but the speed and the sinus like shape
can't be influenced at all. Something that would be nice in that concern
is a save_file function for image maps. This would seriously speed up the
generation of the influence grid which is the only really slow part about
the water calculation. The water simulation itself i do with an external
program.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Wow! This is the first one I've seen with water too!! Nice!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
*Snip*
> You can't see this as individual springs, you simply have the potential
> field of the environment and the other bodies and calculate the forces
> from it.
Well, that's an approach similiar to some CFD-models out
there. Instead of using tons of springs, some just use a limited
area for calculation with a 3D-Grid of samples. Samples affect
each other on a neighbouring basis, which I think comes very
close to being a potential field. Its a different approach, nontheless,
its rather particle-amount-independant.
Ah well. Getting off-topic, I think. ;-)
Are you using pure POV, or some C++ "plug-in"?
...
Hm. Cancel that question. "iso_csg" was mentioned somewhere.
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmx de
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Tim Nikias wrote:
>
> [...]
>
> Well, that's an approach similiar to some CFD-models out
> there. Instead of using tons of springs, some just use a limited
> area for calculation with a 3D-Grid of samples. Samples affect
> each other on a neighbouring basis, which I think comes very
> close to being a potential field. Its a different approach, nontheless,
> its rather particle-amount-independant.
No. I don't understand completely what you are saying, but it seems very
different.
I don't discretize space for calculating the collisions (apart from
calculating the gradient to be correct, but this is not important). It's
just calculating the repulsion of the balls from the field of the
environment and the other balls.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Nice simulation! Good to see someone take a different approach to particle systems
too.
Do you have an estimate on how much faster/slower your method is compared to the usual
particle system methods?
When I saw Rune's water, I had a similar idea, but did not have the time to persue it.
The balls entering the water lack splashes. I wonder whether you could generate
'water'
particles if ball velocity entering the water exceeds a certain limit. These water
particles could then be treated like other particles, with the exception that they
would be destroyed if they re-entered the pool of water.
MJL
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Tony[B]" wrote:
>
> Wow! This is the first one I've seen with water too!! Nice!
Thanks.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Mark James Lewin wrote:
>
> Nice simulation! Good to see someone take a different approach to particle systems
too.
> Do you have an estimate on how much faster/slower your method is compared to the
usual
> particle system methods?
That difficult to say, but it's quite a bit different than a classical
particle system. It is certainly much slower than a system like Rune's,
but you can't really compare that. I do not yet simulate rotation of the
balls, but i plan to add that although i'm a bit afraid of the
mathematics... ;-)
>
> When I saw Rune's water, I had a similar idea, but did not have the time to persue
it.
> The balls entering the water lack splashes. I wonder whether you could generate
'water'
> particles if ball velocity entering the water exceeds a certain limit. These water
> particles could then be treated like other particles, with the exception that they
> would be destroyed if they re-entered the pool of water.
This is an interesting idea, but quite tricky. Where do you think the
particles should be created and with what direction of movement?
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On Mon, 13 May 2002 00:09:01 +0200, Christoph Hormann <chr### [at] gmx de>
wrote:
> geometry to an iso_rcsg function
finnally some serious application :-)
> a longer and better version
> can be found
really interesting and nice animation, but ... where are drops of the water ?
;-)
ABX
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Christoph Hormann wrote:
> That difficult to say, but it's quite a bit different than a classical
> particle system. It is certainly much slower than a system like Rune's,
> but you can't really compare that. I do not yet simulate rotation of the
> balls, but i plan to add that although i'm a bit afraid of the
> mathematics... ;-)
Rotation... yikes! Good luck!
>
>
> >
> > When I saw Rune's water, I had a similar idea, but did not have the time to persue
it.
> > The balls entering the water lack splashes. I wonder whether you could generate
'water'
> > particles if ball velocity entering the water exceeds a certain limit. These water
> > particles could then be treated like other particles, with the exception that they
> > would be destroyed if they re-entered the pool of water.
>
> This is an interesting idea, but quite tricky. Where do you think the
> particles should be created and with what direction of movement?
Point of impact to no more than the radius of the ball causing the disturbance, with
directions spread between parallel to the water surface and parallel to ball surface
influence (maybe?). This is just a guess (and I haven't tried it myself) but I agree,
it is a
tricky problem. I think that knowing whether the ball will give rise to a splash or
just a
'plop' will also be hard.
MJL
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |