 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just the beginnings of a little particle system, although nowhere near as
advanced as some of the great ones out there already. I hope the checkered
Post a reply to this message
Attachments:
Download 'bounce.mpg' (205 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nice one. Bowling ball as reflective sphere, good
idea!
How does you system work? How long are parsing
times for lots of particles, etc? And what will it later
be capable of (once its finished and all planned features
implemented)?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de
> Just the beginnings of a little particle system, although nowhere near as
> advanced as some of the great ones out there already. I hope the checkered
>
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for the comments. Each particle has an initial angle/velocity and the
path is calculated using general projectile motion equations. For every
1000th of a frame trace() is used to see whether there is a collision with
the ground and if so a new angle/velocity is calculated. I've only really
played with a few particles at once, but parse times were around a second
per frame (on athlon 1800+). No doubt if you reduced the number of calls to
trace to 100 per frame, things would be much faster. Hopefuly when I get the
thing finished it'll be able to model the motion of spheres bouncing off any
object types with proper friction/air resistence. If I am really keen maybe
not just spheres...then again maybe not :)
From
Michael B.
"Tim Nikias v2.0" <no_lights (@) digitaltwilight.de> wrote in message
news:3f605e80@news.povray.org...
> Nice one. Bowling ball as reflective sphere, good
> idea!
>
> How does you system work? How long are parsing
> times for lots of particles, etc? And what will it later
> be capable of (once its finished and all planned features
> implemented)?
>
> --
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
> Email: no_lights (@) digitaltwilight.de
>
>
> > Just the beginnings of a little particle system, although nowhere near
as
> > advanced as some of the great ones out there already. I hope the
checkered
> >
> >
> >
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hm. So you're actually using just a single point
for your particles, right? Not full fledged object
collision? (I'd guess so for a particle system, its
not intended as a pun).
Still, 1000 traces is a bit much, don't you think?
What I'm planning to do for my next system with
collision detection is to calculate the traces based
on distance travelled: every 0.1 POV-Units or such.
Slow moving particles don't require that many tests,
as long as I've got some variables to keep control
that a particle is lying on the floor and just won't
drop any further.
Faster particles do require more traces, because they
might easily pass through a wall from one frame to
the next. Speed-Based traces will do just that. On
my next particle system, I won't be doing loopable
animations, but the system should still be able to
reparse the simulation in case the render begins at
some frame in the middle of an animation.
Oh, and does your system handle particle-particle
interaction?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de
> Thanks for the comments. Each particle has an initial angle/velocity and
the
> path is calculated using general projectile motion equations. For every
> 1000th of a frame trace() is used to see whether there is a collision with
> the ground and if so a new angle/velocity is calculated. I've only really
> played with a few particles at once, but parse times were around a second
> per frame (on athlon 1800+). No doubt if you reduced the number of calls
to
> trace to 100 per frame, things would be much faster. Hopefuly when I get
the
> thing finished it'll be able to model the motion of spheres bouncing off
any
> object types with proper friction/air resistence. If I am really keen
maybe
> not just spheres...then again maybe not :)
>
> From
> Michael B.
>
> "Tim Nikias v2.0" <no_lights (@) digitaltwilight.de> wrote in message
> news:3f605e80@news.povray.org...
> > Nice one. Bowling ball as reflective sphere, good
> > idea!
> >
> > How does you system work? How long are parsing
> > times for lots of particles, etc? And what will it later
> > be capable of (once its finished and all planned features
> > implemented)?
> >
> > --
> > Tim Nikias v2.0
> > Homepage: http://www.digitaltwilight.de/no_lights
> > Email: no_lights (@) digitaltwilight.de
> >
> >
> > > Just the beginnings of a little particle system, although nowhere near
> as
> > > advanced as some of the great ones out there already. I hope the
> checkered
> > >
> > >
> > >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003
> >
> >
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I only started this little test a few days ago so I haven't quite decided on
the final method of collisions, but it won't be a single point. I initially
pre determined the distance the particle would travel, which assumed it
would always land at the same height it launched from. As you can tell this
was a silly way to go about it, but I just wanted to see the ball bounce
damn it! I'll probably end up tracing perhaps 6 rays from the sphere's
surface, one in each direction, then getting the shortest ray and tracing
another set of rays from the half of the sphere of the previous ray. This
would continue until there is either the ray length is 0 (or very small) or
some threshold for the number of rays is reached. Kind of a divide and
conquer thing to help reduce parse time. As for particle particle collision,
I'd like to implement it but haven't thought of any efficient methods for it
yet.
Speed based traces sounds like a good idea. How do you plan on being able to
render from a frame starting from the middle of an animation?
Michael B.
"Tim Nikias v2.0" <no_lights (@) digitaltwilight.de> wrote in message
news:3f606a90@news.povray.org...
> Hm. So you're actually using just a single point
> for your particles, right? Not full fledged object
> collision? (I'd guess so for a particle system, its
> not intended as a pun).
>
> Still, 1000 traces is a bit much, don't you think?
> What I'm planning to do for my next system with
> collision detection is to calculate the traces based
> on distance travelled: every 0.1 POV-Units or such.
> Slow moving particles don't require that many tests,
> as long as I've got some variables to keep control
> that a particle is lying on the floor and just won't
> drop any further.
> Faster particles do require more traces, because they
> might easily pass through a wall from one frame to
> the next. Speed-Based traces will do just that. On
> my next particle system, I won't be doing loopable
> animations, but the system should still be able to
> reparse the simulation in case the render begins at
> some frame in the middle of an animation.
>
> Oh, and does your system handle particle-particle
> interaction?
>
> --
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
> Email: no_lights (@) digitaltwilight.de
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Speed based traces sounds like a good idea. How do you plan on being able
to
> render from a frame starting from the middle of an animation?
The idea is simple: the random streams of POV-Ray rand() are
pseudo-random, or, so to speak, predictable. If I generate
times when a particle is born, with which speed etc with the
same random-stream, the initial startup for all particles will
always be the same. From then on, the speed-based algorithm
will take hold, generating as many trace()-calculations as required
to parse the entire path. Moving objects etc will be handled
with their own macros, probably the same way as my LSSM do
it. Aside of other macros, of which the effect can be calculated
for each required moment of time "on the fly", the resulting
animation should be the same, no matter if I begin from frame
1 or 500. This is the same reason why the LSSM can calculate
from any given frame onwards.
Regards,
Tim
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de
> I only started this little test a few days ago so I haven't quite decided
on
> the final method of collisions, but it won't be a single point. I
initially
> pre determined the distance the particle would travel, which assumed it
> would always land at the same height it launched from. As you can tell
this
> was a silly way to go about it, but I just wanted to see the ball bounce
> damn it! I'll probably end up tracing perhaps 6 rays from the sphere's
> surface, one in each direction, then getting the shortest ray and tracing
> another set of rays from the half of the sphere of the previous ray. This
> would continue until there is either the ray length is 0 (or very small)
or
> some threshold for the number of rays is reached. Kind of a divide and
> conquer thing to help reduce parse time. As for particle particle
collision,
> I'd like to implement it but haven't thought of any efficient methods for
it
> yet.
>
> Speed based traces sounds like a good idea. How do you plan on being able
to
> render from a frame starting from the middle of an animation?
>
> Michael B.
>
> "Tim Nikias v2.0" <no_lights (@) digitaltwilight.de> wrote in message
> news:3f606a90@news.povray.org...
> > Hm. So you're actually using just a single point
> > for your particles, right? Not full fledged object
> > collision? (I'd guess so for a particle system, its
> > not intended as a pun).
> >
> > Still, 1000 traces is a bit much, don't you think?
> > What I'm planning to do for my next system with
> > collision detection is to calculate the traces based
> > on distance travelled: every 0.1 POV-Units or such.
> > Slow moving particles don't require that many tests,
> > as long as I've got some variables to keep control
> > that a particle is lying on the floor and just won't
> > drop any further.
> > Faster particles do require more traces, because they
> > might easily pass through a wall from one frame to
> > the next. Speed-Based traces will do just that. On
> > my next particle system, I won't be doing loopable
> > animations, but the system should still be able to
> > reparse the simulation in case the render begins at
> > some frame in the middle of an animation.
> >
> > Oh, and does your system handle particle-particle
> > interaction?
> >
> > --
> > Tim Nikias v2.0
> > Homepage: http://www.digitaltwilight.de/no_lights
> > Email: no_lights (@) digitaltwilight.de
> >
> >
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Michael B." <fra### [at] hotmail com> wrote in message
news:3f618fdf@news.povray.org...
|
| As for particle particle collision,
| I'd like to implement it but haven't thought of any efficient
| methods for it yet.
I have seen a few particle systems posted on here, and the posters all
say, "no particle interaction.......yet." However, I don't think that
it's possible with these methods without being unreasonably slow. I
think that with 1000 steps per frame just to calculate intersections
with the floor, you are already approaching the limits of these move and
check or trace macro methods.
There is, of course, a lot of utility from these methods even without
particle interaction.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
