Multibody dynamics 2
N-bodies
Last updated
N-bodies
Last updated
Let’s now create a multi-body simulation using a number of randomly positioned particles. The animation below shows an example of using four particles and their trajectories. The way they entangle with one another is remarkable.
The setup for this kind of simulation is relatively simple: We generate a random set of points within a bounding volume using the “populate 3d” component. Note that the number of particles created is exposed as an input parameter. Particle velocities are initially all set to zero, by just multiplying their positions with zero and interpreting the result as vectors. Masses are also randomly sampled within a preset range.
Practice
Experiment with different sizes of particles systems. You may adjust the random sampling ranges and/or include initial velocities.
Observe how the simulation slows down significantly with the increase of the number of particles. How can we express or measure this relationship?
One problem with the setup is that particles attract one another and once they come too close with one another, the forces excreted are so large, because of the inverse square relationship, that they tend to explode. To convert from an open universe to a bounded version thereof we will develop a new constraints system.
The approach is based on multiple cluster components that organize the logic quite succinctly. We will import the state of the particle system, namely positions, velocities and masses, as well as an “enable” parameter for toggling between open and closed universe types.
We will constraint particles within a bounding box with +/- “limit” size dimensions. Particles will bounce off the virtual world boundaries. We will implement an internal cluster such that when the world is bounded, the bounding box will be conditionally visualized on screen.
The “bounds” cluster component contains the conditional display logic. When enable is set, we construct and display a transparent bounding box such that we can visually observe where the particles are supposed to bounce against. We use the “stream gate” component’s “1” i.e. activated output for this construction and leave the “0” i.e. deactivated completely blank.
The “world” cluster component contains the bounding box bouncing logic. Here we use “stream filter” components to select either the original particle positions and velocities or the constrained versions thereof coming from the “bounce” cluster.
The “bounce” component implements the “ground plane” constraint we used in the projectile experiment only three times; once for each point coordinate and velocity direction. In summary, we deconstruct the particles’ positions and velocities, perform clamping and bounding and reassemble the points and vectors.
The “clamp” component is merely a python script using the code below. We use the “if” expression twice to clamp the point’s coordinate in +/- a limiting value sense. For a vector, we invert its component only if the position has exceeded the limiting value.
The degree of nesting cluster components may seem excessive. It has nothing to do with making the logic faster or modular but primarily to keep the concepts clear. This approach is highly recommended as it simplifies the legibility of the constructs. What may seem self-evident now, may not so much some months or years down the line; or a person who has not developed this logic at all.
Practice
Since we can detect the presence of collisions, we may implement an energy dissipation constraint, where the particle’s velocity is reduced by a percent of its original value i.e. instead of +/- 1.0 use +/- 0.9 for the new component multiplier.
Experiment with other positional constraints such as you may constraint particles’ positions on a surface using the “surface closest point” component or a sphere by just normalizing their positions.
In this session we looked at creating relationships between particles expressed using forces. If we step back from the direct physics analogy and forget about molecules and planets, this is actually quite a powerful way of creating associations between entities in general! This is because forces may casually contradict, as in oppose, one another. The sum of forces expresses the aggregate compromise or feasible direction among all different requirements; and time is the mechanisms that allows those to find an eventual balance. In this sense, forces express “desires” rather than “laws” set in stone or uncompromising arithmetic / geometric rules.
The definition of those relationship establish here were however implicit. We applied the same force to all entities; or equivalently there were no explicit information for which pairs to apply them. In order to explore more interesting scenarios we need to expand the scope of force definitions a bit more in the next session.
For those interested in exploring Python programming, you may refer to Projectile Physics and N-bodies to see how we can combine visual and text programming to recreate these examples.
As an advanced challenge try to implement a Brownian motion [] inter-particle collision constraint using the Cartesian product ideas used for force analysis. Hint: Use the idea of sphere-sphere intersection to determine particle bounces.
