 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmxde>
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
|
|
| |
| |
|
|
|
|
| |
