I tried the scene Tim Nikias v2.0 posted to p.b.s-f and the result looks 
quite promising. Now I shoot only two collision test rays: one is the 
speed vector and the other is gravity. It's not perfect but result looks 
good. Damping was 20%.

Severi

Post a reply to this message

Attachments:
Download 'test001.m1v.mpg' (572 KB)

> I tried the scene Tim Nikias v2.0 posted to p.b.s-f and the result looks
> quite promising. Now I shoot only two collision test rays: one is the
> speed vector and the other is gravity. It's not perfect but result looks
> good. Damping was 20%.

Looks great! So you're my competition, eh? ;-)

It seems like you've used the invisible container as object to sample
collisions on: the particles are floating above the surfaces and rebounce
too early. I've described that somewhere in the scene (at least I hope so):
when simulating just point-particles, the center of a sphere would lie on a
surface, and thus the particles would visibly intersect the environment,
though the particles themselvers aren't.

What are you planning to do with the system, how flexible is it? How easy is
it to create different kinds of particles in the same scene?

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Tim Nikias v2.0 wrote:
> Looks great! So you're my competition, eh? ;-)

I also tried out your test scene.

I compared to your posted animation which is rather different than what
the scene describes.
So instead of 18 seconds, it runs over 9 seconds, like yours. And
instead of 5 balls per frame, it uses 2, which I think is close to what
you must have used.

Total parsing time was 2 minutes and 3 seconds on my Athlon XP 1700+. I
didn't test it with the specifications in the scene file (18 seconds
long and 5 balls per frame), but I can upload the scene file if anyone
wants it. One thing that has major impact on the parsing time is that I
only used 20 calculation steps per second (less than one per frame).
Perhaps there are slight precision errors visible, but I still think the
animation shows that quite acceptable results can be obtained with very
few "samples".

A nice thing was that the parameters between the two systems seem to be
very compatible. I used:

#declare particle_bounce       = 0.75;
#declare particle_bounceturb   = 0.10;
#declare particle_friction     = 0.0;
#macro particle_gravity  (Clock,Point) <0,-9.81,0> #end

And it rendered with the attached result which is very much similar to
the one you posted. :)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Mar 7**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Attachments:
Download 'particle_scene_rune.mpg' (565 KB)

Tim Nikias v2.0 wrote:
> Looks great! So you're my competition, eh? ;-)

Thanks! And competition results evolution, doesn't it ;-) Actually a 
particle system was my intention immediately when I saw Christoph's 
animations (especially the elastic bouncing boxes) last year probably. I 
HAD to create something similar. I just find it fascinating to be able 
to create a very realistic looking simulations just by applying a few 
easy equations and some carefully chosen logic. It was such a great 
feeling to see the balls bounce the first time!

> It seems like you've used the invisible container as object to sample
> collisions on: the particles are floating above the surfaces and rebounce
> too early. I've described that somewhere in the scene (at least I hope so):
> when simulating just point-particles, the center of a sphere would lie on a
> surface, and thus the particles would visibly intersect the environment,
> though the particles themselvers aren't.

Oh yes, I didn't pay attention on which Environment to use. The second 
one seems to be the correct one. Well, maybe next time...

> What are you planning to do with the system, how flexible is it? How easy is
> it to create different kinds of particles in the same scene?

It is still very inflexible. I'm now slowly moving things to macros and 
figuring out how to arrange an easy to use, powerful and expandable UI. 
Many things will probably change but the start is promising.

I have only one kind of particles and they are created whenever a 
certain macro is called. It works, but it won't do any miracles :)

Severi

Severi

Post a reply to this message

> I compared to your posted animation which is rather different than what
> the scene describes.

Yeah, Christoph mentioned that as well. Here at home I've worked further on
that scene and the scene-file I posted was different from the animation in
just those regards: amount of particles and amount of frames (which lead to
9 seconds, not 18).

> Perhaps there are slight precision errors visible, but I still think the
> animation shows that quite acceptable results can be obtained with very
> few "samples".

If you look closely at the last particle that bounces back into the glass
funnel, you'll notice it "wiggles" visibly. I guess that's a side-effect
from using less samples than frames. Something of the sort was what I had
noticed during your beta-tests, but it seemed to have been taken care of at
that time. Well, testing is never finished, is it? ;-)

> A nice thing was that the parameters between the two systems seem to be
> very compatible. I used:
>
> #declare particle_bounce       = 0.75;
> #declare particle_bounceturb   = 0.10;
> #declare particle_friction     = 0.0;
> #macro particle_gravity  (Clock,Point) <0,-9.81,0> #end
>
> And it rendered with the attached result which is very much similar to
> the one you posted. :)

I would think that the results should all look pretty much alike with the
described things like losing velocity on impact, where particles start and
with which speed and so forth. BTW, does your particle-system take several
objects into account with different "bounce"-settings (which is a modifier
for the reversed velocity when it hits a surface, right?)? I've designed my
UI to be very modular, and you just "plug" another object in there with its
own settings. This way, you can even create Impact-Effects based on the
object getting hit, which is something I'd probably need at some point
during the work on my Long Term Project, the Short. I basically wanted to
create a highly flexible System with many possibilities for enhancements.
I'm still thinking about that subset-framing issue, so that I don't have to
run simulations from the beginning, but do it like you do: just generate the
required data that leads to the frame I'm currently rendering. So far, the
results were different due to adaptive-timesteps. I have to somehow adjust
the system to do a maximum of clock_delta-timesteps, but do those repeatedly
if I for example render frame 15 without having rendered the other 14 frames
first.

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

> It is still very inflexible. I'm now slowly moving things to macros and
> figuring out how to arrange an easy to use, powerful and expandable UI.
> Many things will probably change but the start is promising.
>
> I have only one kind of particles and they are created whenever a
> certain macro is called. It works, but it won't do any miracles :)

Well, keep us informed on your progress. I didn't post much lately because
the basic effects etc didn't change, I've been working on some details and
doing test-runs for my short (hopefully resulting in one finished shot for
the shot, 4 secs :-) and have been researching (with my mind and with
google) some stuff I don't want to add right now, but want to leave open for
future updates. And there are still some macros missing which I direly want
to implement before releasing the code to the public.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Tim Nikias v2.0 wrote:
> If you look closely at the last particle that
> bounces back into the glass funnel, you'll notice
> it "wiggles" visibly. I guess that's a side-effect
> from using less samples than frames.

Yes. Increase the number of calculation steps and it should disappear.

> Something of the sort was what I had noticed during
> your beta-tests, but it seemed to have been taken
> care of at that time. Well, testing is never
> finished, is it? ;-)

It's not a bug in the system, just precision errors which can be avoided
by using more calculation steps. This has nothing to do with testing...
:)

> BTW, does your particle-system take several objects
> into account with different "bounce"-settings

No. I didn't thought it would be worth the effort. Few scenes will
require a scenario like that by my estimate. I can't think of cases
where it's needed. Stuff made of particles, like water, sparks, fire,
dust and other things don't really bounce very differently on hard and
soft surfaces. Balls do, but balls are not particles, and thus not the
job of a particle system.

> (which is a modifier for the reversed velocity when
> it hits a surface, right?)?

Yes.

> This way, you can even create Impact-Effects based
> on the object getting hit, which is something I'd
> probably need at some point during the work on my
> Long Term Project, the Short.

What is the scenario that requires this object based impact-effect? I'm
just curious.

> I'm still thinking about that subset-framing issue,
> so that I don't have to run simulations from the
> beginning, but do it like you do: just generate the
> required data that leads to the frame I'm currently
> rendering.

Hehe, it's definitely the feature in my system that caused me the most
trouble. Just a simple thing like randomness suddenly need to be
carefully considerated, and even the rand()-function is not of any
use... :)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Mar 7**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> What is the scenario that requires this object based impact-effect? I'm
> just curious.

The short is about a worm trying not to end as fish-bait. The reason why the
adventure starts is because it's raining, and that's when worms surface in
order no to drown in the water-soaked earth (which is a fact). So I'm using
particles for all kinds of water effects in this part of the short. In some
scenes there'll be rain, and I can more easily just attach different effects
to different objects. For example, when the rain hits the worm, it'll
splash, when it hits the floor, it just dies. When hitting a stone it might
splash into fewer but larger particles, cause they're not in focus like the
worm is.

> Hehe, it's definitely the feature in my system that caused me the most
> trouble. Just a simple thing like randomness suddenly need to be
> carefully considerated, and even the rand()-function is not of any
> use... :)

Well, my non-IO-System made use of rand() extensively. All you need to take
care of is that you use the same amount of calls to it all the time.
Whenever I made calls to the rand-stream, I *always* made them, even if I
didn't require it for the setup.

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Oh, and another thing: the modularity of the system allows that I can later
add rotational-effects upon impact, sort of like a
"small-objects-physics-simulation". I won't need that for the water or most
of the particles, but I wanted to design a system that I can enhance and
build upon. E.g. for small rock-slides or such, it'll be useful to have
objects bounce differently off of rubber-tires or brick-walls.

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Tim Nikias v2.0 wrote:
>> What is the scenario that requires this object
>> based impact-effect? I'm just curious.
>
> For example, when the rain hits the worm, it'll
> splash, when it hits the floor, it just dies.

Yes, I can see the point. I didn't aim for that level of sophistication,
and it would have made the subset-framing (and looping animations, which
use practically the same technique) practically impossible.

> Well, my non-IO-System made use of rand() extensively.
> All you need to take care of is that you use the same
> amount of calls to it all the time. Whenever I made
> calls to the rand-stream, I *always* made them, even
> if I didn't require it for the setup.

I can see how that might not be so bad for a non-IO-system, but for a
IO-system it sounds pretty inefficient and cumbersome. I used custom
hash-functions based on the insignificant digits of some
sinus-functions. They always return the same output number given the
same input number, yet the output numbers for consecutive input numbers
are completely random (almost).

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Mar 7**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message