A brief summary of the progress over the last couple of weeks:
- Particles don’t have a fixed acceleration anymore, they respond to forces acting on them due to external factors which are updated each frame.
- Implemented force generators for particles. Force generators may apply forces to particles registered to them each frame.
- Added force generators for gravity, springs, anchored springs and bungees.
- Implemented interface to demonstrate the force generators using SFML-2.4.2 in a Testbed project.
- Visualized the interaction of particles in case of all the above force generators in the Testbed project.
Unlike in previous iteration, each particle now estimates its acceleration based on the forces accumulated in the integration step (using D’Alembert’s Principle). At the end of the integration step the accumulator is cleared. See code for Particle class. Thus, at the end of each integration step there is no force acting on the particle and all the continuously applied forces (such as gravity) need to be reapplied each frame.
Force generators are an automated mechanism programmed to apply forces over an extended period of time to particles. Moreover, they apply forces to the particles registered to them based on specific logic which can be programmed for each specialized force generator. I have implemented force generators for gravity, basic spring forces, anchored springs and bungees. Similarly, force generators for drag forces, buoyancy and harmonic motion can be implemented.
Each of these specialized force generators can be constructed by the user of the engine and they will automatically register to a static manager contained in the ParticleForceGenerator class. When the World calls the UpdateForces method contained in the static manager, the static manager iterates over the list of force generators contained in it and calls the UpdateForce method on each particle associated with each and every one of them.
Springs and particles can produce a range of effects such as ropes, water ripples, bridges, etc. Rather, in nature almost everything acts as springs. Collisions between solids are supposed to compress them and act as they act as if they are extremely stiff springs which try to push away each other. This approach to modeling collisions is called the penalty method.
However, if we model everything as springs, the interactions would look extremely spongy for low value of spring constants. At the same time, if we try to implement collision between solids with high spring constants, they spring constants would be really high. This is not feasible since for high spring constants, the forces acting on the particles would be enormous enough to create ever increasing oscillations which would end up sending the particles to infinity. This would also be affected by the frame rate. The worse the frame rate, the worse the oscillations would be.
Visualizing In Testbed Project
Any demo can be created by extending the Demo class in the Testbed project. The user can override the initialize, update and draw methods in the derived class and use it in the main program for demoing. Beware, the version of SFML used in the Testbed project only supports x86 platform.
Apart from this interface to demo different features of the engine, I have implemented three demos which are as follows:
- The ParticleSpringDemo demonstrates forces acting between two particles connected by a spring.
- The ParticleAnchoredSpringDemo demonstrates a particle anchored by a spring to the center of the screen and being influenced by gravity at the same time.
- The ParticleBungeeDemo shows a particle connect to another through a bungee while only one of them is being influenced by gravity.