Looks like I have another bug.  I threw in 60 balls into the box (note: 
front panel is invisible) but my physics system couldn't handle the 
pressure.  Sudden burst of (accumulated?) energy are released.  I have a 
few ideas why and I think I can address the problem.  Not permitting 
slippage doesn't help.  I'm also thinking that having to write out all of 
the float values to a text file between frames sure doesn't help data 
precision either (I've increased the output length).  Still the results 
are kind of funny.

Stats for Tim ;-):

Simulation time: 10 seconds
Rendered 2400 frames averaged down to 240 for motion blur...
On an Athlon 1.2Ghz

Time For Parse/Frame:    0 hours  0 minutes   3.9 seconds (3 seconds)
Time For Parse Total:    2 hours 34 minutes  28.0 seconds (9268 seconds)
Time For Trace/Frame:    0 hours  0 minutes   0.5 seconds (0 seconds)
Time For Trace Total:    0 hours 19 minutes   5.0 seconds (1145 seconds)
          Total Time:    2 hours 53 minutes  33.0 seconds (10413 seconds)
-------------------------------------------------------------------------
CPU time used: kernel 2579.92 seconds, user 10753.82 seconds, total 
13333.74 seconds
Render averaged 1.44 PPS over 19200 pixels

Post a reply to this message

Attachments:
Download 'BB60Tiny.mpg' (592 KB)

I don't know how your simulation works, but when one uses explicit methods
for solving differential equations, sometimes this behaviour can show up.
Implicit methods are generally more difficult to code, but they are
inherently stable, so you shouldn't observe any jumps, blow ups or
instabilites.

Fernando

Post a reply to this message

"Fernando Gonzalez del Cueto" <fgd### [at] hotmailcom> wrote in
news:3f6cae03$1@news.povray.org: 

> I don't know how your simulation works, but when one uses explicit
> [...]

No, actually it's just a build-up of energy that my code wasn't letting go.  
My code didn't allow for rotational slippage and it only allowed for energy 
loss due to friction when a ball was rolling/bouncing.  So, when a whole 
bunch of balls are stuck together and against the walls and floor and 
another ball comes along with horizontal rotational energy and gets stuck 
against the wall and is being pulled down by gravity, all of the built-up 
rotational energy just circulates through the system with nowhere to go.  
Eventually it starts to creep up in the small rounding errors of the many 
vector transformations, starts to show up in a tiny sideways rotation 
somewhere, then with a little time, POP!, the energy is released by 
launching a ball upwards.

Post a reply to this message

Looks kinda nice, even with that strange
energy-thing going on...

And thanks for the stats. In effect, giving
that you rendered 10 times as many frames
as needed, one could say the parsing per
actual frame of animation is 40 seconds.
For 60 balls in a box, and with just that energy
problem, but no balls falling out, I'd say
thats kinda good coding. OTOH, as soon
as trace() is brought in, I'll expect it to
go higher, as you'll need more than just one
trace per ball.
Once you do have object interaction, try
something new: instead of using balls, use
blobs, and try to simulate water with,
don't know, 300 to 500 spheres. Have it
poured out of a bucket or such.
You'd have to switch off rotations for that,
although that might still be a nice special
effect for the water...

Oh, and do your particles support different
sized particles, or do they have to be the
same size?

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de


> Looks like I have another bug.  I threw in 60 balls into the box (note:
> front panel is invisible) but my physics system couldn't handle the
> pressure.  Sudden burst of (accumulated?) energy are released.  I have a
> few ideas why and I think I can address the problem.  Not permitting
> slippage doesn't help.  I'm also thinking that having to write out all of
> the float values to a text file between frames sure doesn't help data
> precision either (I've increased the output length).  Still the results
> are kind of funny.
>
> Stats for Tim ;-):
>
> Simulation time: 10 seconds
> Rendered 2400 frames averaged down to 240 for motion blur...
> On an Athlon 1.2Ghz
>
> Time For Parse/Frame:    0 hours  0 minutes   3.9 seconds (3 seconds)
> Time For Parse Total:    2 hours 34 minutes  28.0 seconds (9268 seconds)
> Time For Trace/Frame:    0 hours  0 minutes   0.5 seconds (0 seconds)
> Time For Trace Total:    0 hours 19 minutes   5.0 seconds (1145 seconds)
>           Total Time:    2 hours 53 minutes  33.0 seconds (10413 seconds)
> -------------------------------------------------------------------------
> CPU time used: kernel 2579.92 seconds, user 10753.82 seconds, total
> 13333.74 seconds
> Render averaged 1.44 PPS over 19200 pixels
>
>

Post a reply to this message

"Tim Nikias v2.0" <no_lights (@) digitaltwilight.de> wrote in 
news:3f6cfdd0$1@news.povray.org:

> [...]
> thats kinda good coding. OTOH, as soon
> as trace() is brought in, I'll expect it to
> go higher, as you'll need more than just one
> trace per ball.

Yes, you're probably right, times will probably go way up with trace().  
Simulations will be limited to night time renderings only.

> Once you do have object interaction, try
> something new: instead of using balls, use
> blobs, and try to simulate water with,
> don't know, 300 to 500 spheres. Have it
> poured out of a bucket or such.

Good idea, actually I was thinking of implementing magnetism (or gravity 
if I make the masses huge, hmmm, solar system? ;-) and though this would 
apply well to water or mercury since their particles have an attraction 
to each other.

> [...]
> Oh, and do your particles support different
> sized particles, or do they have to be the
> same size?

It does support balls with different radii ("radiuses"?), but all balls 
have the same mass right now, so collisions between a big ball and a 
little ball with the same mass looks really weird.  Need to add support 
for that.

Post a reply to this message