Bouncing or not bouncing ???
dugres
I'm new to Lepton and yet I like it already.
I have a question about the "bouncy.py" example :
Once the program is runnig if you maximize the window (but not the
"screen_domain") some balls won't eventualy bounce on the
screen_domain and will get lost. (if they get out by a side ; if they
get out by the top : gravity will bring them back)
Why is that ?
Casey Duncan
I've noticed that as well, though maximizing the example window
certainly makes it plain as day 8^). I think it's a bug in the AABox
domain intersect code which is missing the intersection in a certain
edge case. I'll take a look at that and fix it.
Thanks for trying out lepton and thanks for the report!
-Casey
Casey Duncan
Fixed in r120. It turned out to be a bug in the bounce controller, not
the domain. In some cases a single bounce (especially near a corner)
would result in the particle "escaping" from the domain because the
bounce would send it out. The bounce controller now checks to make
sure that the bounce does not intersect the domain again, and if it
does it deflects the particle again until it winds up in the correct
place. There are cases where this may not be possible, such as very
fast moving particles in a very small domain, so it only bounces each
particle a fixed number of time before giving up (currently 4). So it
is still possible to have particles escape, especially if each bounce
accelerates the particles. But I think that's better than an infinite
loop 8^)
This is solvable for "container" domains by putting extremely fast
moving particles in a random position in the domain each frame if they
exceed the bounce limit, but I wasn't sure how to handle bouncing off
the outside of domains so I didn't implement that yet. I'm open to
opinions on this. Particles inside the domain could be special-cased
to ensure they always stay in their containers, but I'd like to avoid
special cases where possible and I wasn't convinced that the random
placement solution was useful.
-Casey
-Casey
Casey Duncan
Note it is still possible for particles to "escape" on corners created
where separate domains intersect. For example, along the sides of the
bouncy example where the bumper Spheres intersects the screen AABox.
This is not as easily fixed because they use separate bounce
controllers entirely. Luckily it seems to happen very rarely, but I
thought I'd throw it out there.
-Casey
Ian Mallett
I'm new to this group.
Bouncing issues? Suggestion: calculate the position of a particle after it has bounced, even if there are many bounces:
1. Every particle has a vector.
2. If the particle will collide with an edge:
3. Find where the particle collides, and subtract the distance to this point from the particle's vector.
4. Reflect this vector to get the new direction. I think it's something like 2(N dot L)N - L.
5. Continue 1-4 ad infinitum until 2.0 is not fulfilled.
pseudocode (for every particle):
particle.tomove_vector = particle.speed #3D vector
while lengthof(particle.tomove_vector) > 0:
for edge in edges:
if edge.particlecollideswith(particle.tomove_vector):
distancetocollide = edge.pos - particle.pos
particle.tomove_vector -= distancetocollide
particle.pos += particle.tomove_vector #vec3 addition...
particle.tomove_vector = VecSubt( VecScale( 2*(dot(edge.normal,particle.tomove_vector)), edge.Normal), particle.tomove_vector)
else:
particle.pos += particle.tomove_vector #vec3 addition...
Ian
Casey Duncan
Hi Ian,
That's pretty much exactly what it does now (before it naively just
calculated a single deflection and hoped for the best). The
flexibility of the architecture throws some curve balls though as you
can have many surfaces (described by domains) each with there own
bouncy-ness. Currently this is handled by each domain having a
separate bounce controller implementing the deflection algorithm. This
is flawed because each bounce controller only gets one crack at the
deflection per frame so bouncing between domains isn't perfect when
the particle velocity exceeds the distance between the domains.
The problem is actually worse than that because there are basically an
infinite number of ways a particle's position or velocity can be
perturbed by various controllers along the way and how they interact
is mostly only dependent on the order they execute. Note that
particles have a "last_position" attribute which is set automatically
at the beginning of the frame so that the various controllers all have
a stable frame of reference no matter what other controllers may have
done to the particle before they get to it.
Of course in a perfect world all the controllers would act
simultaneously, which I suppose could be simulated by allowing all
controllers to work on an independent copy of the particle and then
somehow reconcile the result. But that is making my head hurt 8^)
At least for the bouncy example, a workaround is to make sure that the
screen boundary bounce controller is the last bounce controller. There
seems to be a bug though that makes that impossible at startup,
something I need to look into. Better yet would be to have only one
bounce controller that somehow let you specify the bounciness
independently for each domain. I think I may be able to cook up a
transparent solution to that problem with a bit of class-level
trickery. We'll see.
Anyway Ian, thanks for the input. This seemingly simple problem is
rife with subtle complexities, which is what makes this sort of thing
fun anyways 8^)
-Casey
Casey Duncan
[..]
> At least for the bouncy example, a workaround is to make sure that the
> screen boundary bounce controller is the last bounce controller. There
> seems to be a bug though that makes that impossible at startup,
> something I need to look into.
I fixed this particular bug in r122, so at least now there is a decent
workaround for ensuring that particles stay inside the desired outer
boundary.
-Casey