 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I've been animating pov for a while, done moving the camera, objects,
walking etc. But now I want to move to the next level. I'd like to try
animating the sand falling in an hourglass. I envision lots of "sand-grain"
objects. The question I have is how would you guys recommend starting this.
Should I write extensive SDL or model the scene in a C# app' that outputs
the scenes? Anyone got any suggestions?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It depends really on how complex the animation is, or rather, how long a
computer takes to calculate the required coordinates for the animation. SDL
has the advantage that its automatically evaluated for you at parse time, so
theres no need to worry about fiddling around with external programs, but on
the other hand, its slow. For any difficult calculation, i.e. one which
takes the computer some time to calculate, an external program is often the
only way to get things done in a reasonable time. However, I tend to use C++
programs for things which I could probably do in SDK, just because I'm more
familiar with C++ than SDL.
Moving to your specific case, simulating grains of sand in an hour glass
accurately is very difficult indeed. To do it properly, one would have to
use a rigid body dynamics simulator to model every grain, but for a large
number of grains, simulators like this are likely to become very slow and
possibly unstable.
The way I'd probably go about doing sand is to look at an hourglass and
observe the various things that are happening:
A conical pile of sand grows at the bottom
The cone of sand at the top shrinks, gaining a dent on its surface above the
hole
Sand falls vertically (more or less) from the hole until it hits the cone of
sand at the bottom
and simulate these individually without accurate consideration of the actual
physics of the problem. Obviously there are things that still need to be
considered to make it seem physically real (the volume of the bottom pile of
sand increases at the same rate as the decrease in volume of the top pile,
for example), but the simulation is based primarily on what looks good,
rather than what is physically correct.
You might be able to use isosurfaces for the two piles of sand and a simple
particle system for the falling grains - in this case, the SDL is probably
suitable, since there isn't that much calculation to be done.
-Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh wrote:
> Hi,
>
> I've been animating pov for a while, done moving the camera, objects,
> walking etc. But now I want to move to the next level. I'd like to
> try animating the sand falling in an hourglass. I envision lots of
> "sand-grain" objects. The question I have is how would you guys
> recommend starting this. Should I write extensive SDL or model the
> scene in a C# app' that outputs the scenes? Anyone got any
> suggestions?
As someone has already posted, your best bet is to probably just write some
code to make it "look right". However, if you want to do it accurately...
Doing it in a fast language is an absolute must, these sims will take a long
time. You will need a trade off between number of grains (ie simulation
time) and how realistic it is going to look.
You also need some decent code to model the physics of the grains fast. The
simplest way is to just compare the position of each grain with every other
and the container and then apply some sort of replusion force when they get
too close. This however will take *forever* with more than few hundred
grains and will need a lot of tweaking to keep it stable and realistic.
There are ways to speed it up, like keeping a record of which grains are in
similar "regions" to other grains, then you don't have to compare every
single grain with every other one.
It would look absolutely stunning if you could do this well, but I suspect
the simulation times would be massive. Even a very small amount of sand
would probably contain millions of grains.
A nice little project though if you like that sort of thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There are ways to speed it up, like keeping a record of which grains are
in
> similar "regions" to other grains, then you don't have to compare every
> single grain with every other one.
Cool. Theres a good head start for me.
>
> It would look absolutely stunning if you could do this well, but I suspect
> the simulation times would be massive. Even a very small amount of sand
> would probably contain millions of grains.
Well, if I'm going to do this, I'm going to create a "generic" system of
some sort that could model sand, rocks or water (blobs) I guess.
Hopefully the algorythm will be simple, but the processing heavy ( all the
fun jobs are like that )
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh wrote:
> > There are ways to speed it up, like keeping a record of which
> > grains are in similar "regions" to other grains, then you don't
> > have to compare every single grain with every other one.
>
> Cool. Theres a good head start for me.
I did a simple system in 2D where it divided the screen into a number of
sections. There was a list for each section that stored which particles
were in that section. Then for each particle I only had to check the other
ones in that section and the 8 neighbouring sections. Experiment with
different sizes of section to see what gives the best results.
> > It would look absolutely stunning if you could do this well, but I
> > suspect the simulation times would be massive. Even a very small
> > amount of sand would probably contain millions of grains.
>
> Well, if I'm going to do this, I'm going to create a "generic" system
> of some sort that could model sand, rocks or water (blobs) I guess.
>
> Hopefully the algorythm will be simple, but the processing heavy (
> all the fun jobs are like that )
The way I did it was to make each particle produce a force on every other
particle proportional to 1/(r^n), where r is the distance between the two
particles and n is some number to play about with. You might also want to
replace r with (r-x) where x is some fraction of the particle size to ensure
the particles don't get too close together. IIRC 4 and 8 worked quite well
for n.
Also bear in mind this system can easily become unstable if your time step
is too big or your forces too big. Just imagine if in 1 frame a particle
moved to be almost on top of another, this would create a *huge* force for
the next frame, sending the particle off into space. If you really want the
speed in your sim then look at better numerical integration methods rather
than just doing position+=velocity*dt each frame. Runge-kutta is a good
one, and there are adaptive methods too.
I find the fun part is to make the code run faster by using clever tricks...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I find the fun part is to make the code run faster by using clever
tricks...
>
I started the basics this weekend. Ive got a particles collection sorted
and scripting engine so that I can script animations. So far all I've
produced is one sphere dropping under force of gravity. Not very intresting
to watch. Thinking in terms of collision checking, I set a "Collision
Accuray" parameter into the scripting language. If I set this to 5, the
system will make 5 collision checks as its applies the motion vectors to all
particles in the scene in five segments. I'm thinking that this is getting
really "processor heavy".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh wrote:
>> I find the fun part is to make the code run faster by using clever
>> tricks...
>>
>
> I started the basics this weekend. Ive got a particles collection
> sorted and scripting engine so that I can script animations. So far
> all I've produced is one sphere dropping under force of gravity. Not
> very intresting to watch. Thinking in terms of collision checking,
> I set a "Collision Accuray" parameter into the scripting language.
> If I set this to 5, the system will make 5 collision checks as its
> applies the motion vectors to all particles in the scene in five
> segments. I'm thinking that this is getting really "processor heavy".
What do you mean "in five segments"? Do you mean 5 segments in space or 5
in time?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott nous apporta ses lumieres ainsi en ce 28/06/2004 07:12... :
>Josh wrote:
>
>
>>>I find the fun part is to make the code run faster by using clever
>>>tricks...
>>>
>>>
>>>
>>I started the basics this weekend. Ive got a particles collection
>>sorted and scripting engine so that I can script animations. So far
>>all I've produced is one sphere dropping under force of gravity. Not
>>very intresting to watch. Thinking in terms of collision checking,
>>I set a "Collision Accuray" parameter into the scripting language.
>>If I set this to 5, the system will make 5 collision checks as its
>>applies the motion vectors to all particles in the scene in five
>>segments. I'm thinking that this is getting really "processor heavy".
>>
>>
>
>What do you mean "in five segments"? Do you mean 5 segments in space or 5
>in time?
>
>
>
>
Looks like 5 test between 2 positions, both in time and space. You take
start position and end position, then you interpolate 5 steps to see if
there is any colision in that interval. I think that it's possible to
find that in one step, but I can't replace the mathematics to do that. I
think that you need some integral or diferential function.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Josh wrote:
> Hi,
>
> I've been animating pov for a while, done moving the camera, objects,
> walking etc. But now I want to move to the next level. I'd like to try
> animating the sand falling in an hourglass. I envision lots of "sand-grain"
> objects. The question I have is how would you guys recommend starting this.
> Should I write extensive SDL or model the scene in a C# app' that outputs
> the scenes? Anyone got any suggestions?
>
>
I've modeled an hourglass with falling sandgrains for the IMP (internet
movie project) - it has been used in our "the end of..." entry for the
IRTC, see http://www.irtc.org/anims/2004-01-15/view.html
(the sourcecode can be downloaded there too).
see scenes/hourglass/hourglass.inc and scenes/sand/sand.inc
The falling sand-grains are set up by a simple SDL particle system, the
rest is CSG. As there are only a few (e.g. 100) grains visible per
frame, SDL is fast enough, so there's no need to precompute anything
(however, I'd write an external app for more complex simulations,
C[++/#], Java, even perl is faster than pov SDL...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Looks like 5 test between 2 positions, both in time and space. You take
> start position and end position, then you interpolate 5 steps to see if
> there is any colision in that interval. I think that it's possible to
> find that in one step, but I can't replace the mathematics to do that. I
> think that you need some integral or diferential function.
Yes thats what I meant. If its possible to do it any other way, I dont
know. I'm substituting processor power for mathematical ability.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
