Greetings / n-body controllers
ac
I'd like to contribute. Specifically in the area of n-body
controllers: collisions, gravitation, and more exotic, density
dependent forces (e.g. Smooth Particle fluid modelling).
Which of the above is of most interest? I had in mind to hack together
a simple gravitational force controller and see how it flies. My
experience is in scientific n-body modelling, so the focus is
different from graphics (less speed, more precision), but it would be
neat to contribute to a project like this, and hopefully learn a thing
or two about writing high performance Python.
Cheers,
Andrew Charles
Casey Duncan
>
> Hi Lepton-people,
Hello, welcome!
> I'd like to contribute. Specifically in the area of n-body
> controllers: collisions, gravitation, and more exotic, density
> dependent forces (e.g. Smooth Particle fluid modelling).
Excellent, would be happy to have some more developers contributing.
> Which of the above is of most interest? I had in mind to hack together
> a simple gravitational force controller and see how it flies. My
> experience is in scientific n-body modelling, so the focus is
> different from graphics (less speed, more precision), but it would be
> neat to contribute to a project like this, and hopefully learn a thing
> or two about writing high performance Python.
A gravitational controller could mean two things to me:
- A domain that attracts (or repulses) particles with a force that
falls off over distance. Ideally the falloff could be controlled by a
parameterized exponent and magnitude for various effects. I was
thinking of calling such a controller an "Attractor".
- A simulation of mutual attraction/repulsion between particles. This
could be used for a variety of effects as well. I would probably call
this one a "MutualGravitation" controller, to help differentiate it
from the existing Gravity controller which is significantly simpler.
This one would not be difficult to implement naively, but getting
something performant would probably require some spacial hashing
scheme, something we'll likely need for particle-particle collision as
well.
The Attractor controller is probably a good place to start because it
will be pretty straightforward. To make it more useful there should
probably be a "point" domain class, though as a workaround a
zero-radius sphere domain could be used. Probably would also be useful
to add an api for determining the distance between an arbitrary point
and the "surface" of a domain.
Note you should work against the code in svn rather than the last
release. In fact I'd like to cut a new alpha release soon after
porting some more controllers to C.
Feel free to prototype the controllers in python, we can migrate them
to C once we think the controllers are "complete" and the
implementation is sound.
Feel free to submit patches to the list against the svn trunk with
unit tests to this list. Once we get comfortable working together I'll
grant you direct commit access.
Thanks!
-Casey
Andrew Charles
attractor. A patch for controller.py (r112) is attached, along with an
example cobbled together from the fireworks and bounce examples (the
example uses a bounce controller to prevent attracted particles from
becoming stuck). I couldn't decide whether the example should be
comets circling a star, electrons orbiting a proton, or sperm swimming
towards an egg, so it has features of all 3.
I should mention, putting the example together was not only fun but
easy - you've done well at making everything modular, pluggable and
straightforward to orchestrate.
The Attractor uses an inverse square law at the moment, which will
produce elliptical paths (There's no reason the exponent can't be a
parameter as well - 1/r is better for a less rapid falloff, I know
nothing about what to expect from 1/r**3 and beyond) I didn't have a
need for determining the distance to the surface of a domain because
the attraction is simply towards the domain's centre. I did discover
that not all domains have a centre attribute when I tried to add an
attractor to the screen's AAbox domain, so perhaps either the attract
controller should test for domain type, or all domains should have a
centre by default?
No unit tests yet - do you want the tests added as patches to the
python files in /test?
Anyhow here it is: as with all code I'll submit, feel free to
add/ignore/modify as you see fit, or let me know of any changes or
suggestions.
Cheers,
Andrew C
Casey Duncan
> I had some spare time this weekend so I implemented a pure python
> attractor. A patch for controller.py (r112) is attached, along with an
> example cobbled together from the fireworks and bounce examples (the
> example uses a bounce controller to prevent attracted particles from
> becoming stuck). I couldn't decide whether the example should be
> comets circling a star, electrons orbiting a proton, or sperm swimming
> towards an egg, so it has features of all 3.
Heh, cool. I actually played with not drawing the proton and electron
circles, only the trails and it looked pretty cool as well. With it
ported to C it should be able to handle lots more particles at high
performance, and when it comes to particles, more is better 8^)
The protons draw a little smaller than the bounce controller's radius,
so it forms a ring of trail particles around them. Is that
intentional?
> I should mention, putting the example together was not only fun but
> easy - you've done well at making everything modular, pluggable and
> straightforward to orchestrate.
Glad to hear. I find it very fun to tweak the parameters for various effects.
> The Attractor uses an inverse square law at the moment, which will
> produce elliptical paths (There's no reason the exponent can't be a
> parameter as well - 1/r is better for a less rapid falloff, I know
> nothing about what to expect from 1/r**3 and beyond) I didn't have a
> need for determining the distance to the surface of a domain because
> the attraction is simply towards the domain's centre. I did discover
> that not all domains have a centre attribute when I tried to add an
> attractor to the screen's AAbox domain, so perhaps either the attract
> controller should test for domain type, or all domains should have a
> centre by default?
I think determining the distance by the distance to the particle
surface would be better for certain types of effects. For instance, a
line segment domain and a plane. However it is not correct for
gravitation effects around a sphere, so maybe it should be optional.
Adding an api to determine the distance from a point to the domain
would be easy given the existing intersect() method, although it will
be slightly more involved for "linear" domains.
That said, I'm not opposed to adding an attribute to domains that
contains the center point.
I do think parameterizing the exponent would be useful. I suppose to
make the attractor a repulser, you can just use a negative mass. Dark
energy, woo!
Another thought, maybe you should make the example 3d? You can look at
the flyby and fireworks examples, which are 3d.
Also, believe it of not, points are quite a bit slower to draw than
billboard quads, the fireworks example in particular might be good to
crib from here.
> No unit tests yet - do you want the tests added as patches to the
> python files in /test?
Yes, that sounds good.
-Casey