Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 04:00:32 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsAaron's Particle Space - a physics sandbox based on particles
Pages: [1] 2 3 4
Print
Author Topic: Aaron's Particle Space - a physics sandbox based on particles  (Read 13290 times)
AaronB
Level 2
**



View Profile WWW
« on: January 02, 2017, 11:07:45 PM »



The blurb:

“Aaron's Particle Space is a sandbox world that revolves around each individual particle.  If you enjoy building objects with real physical properties, solving puzzles, learning more about physical interactions, exploring immense and microscopic worlds, creating dynamic art or even just shooting or blowing things up, then Aaron's Particle Space is for you.”


DOWNLOAD ALPHA v0.20.01










There is a physics engine demonstration called OE-cake https://www.reddit.com/r/oeCake/ that held a great amount of fascination for me - I love physics simulations Smiley One of the things I noticed about this software was how rapidly it would slow down once it reached a certain number of particles.  A bit of thought made me realize that this was due the nature of having to check each particle against every other particle, this being a classical O(x^ 2 )  relationship (10 particles = 10x10 = 100 calculations, a 100 particles = 100x100 = 10000 calculations. Obviously not linear.  So I got to thinking wouldn't it be neat to implement something like OE-cake on modern graphics hardware, where the immense parallel processing power would help reduce this computational bottle neck.  Was it possible to have a stable physics simulator with all particles interacting simultaneously?  Maybe the answer has been found elsewhere, but I always like to work things out for myself, so I have spent a good part of 2016 developing such an engine.  Which is why I am writing this introduction.  Over the next week or so I will be asking for feedback on the engine – which I hope will be of interest to the TIGSource community.

How it works (geeky stuff)

The particle / physics engine runs entirely on the GPU using compute shaders.  This allows each particle to be processed simultaneously using the massive parallel processing capabilities of the GPU. The upshot of this is we can get closer to mimicking real life by treating physical objects not as a whole, but by concentrating on the behavior of each individual component (particle) that make up the object. In other words, the rubbery, brittle, stretchy, rigid etc, characteristics of an object can be defined entirely by how each particle interacts with it's neighbor.

So what are the particle interactions we need to focus on?  Well it turns out to be relatively simple.  There are two fundamental interactions, how the particles collide with each other, and how they are attracted to each other.  The entire physics engine can be derived from two formulas, one that defines the forces resulting from a collision, and one that defines the forces of attraction (or repulsion).

For the collision formula there are many web resources, discussions, etc that cover particle collisions, particularly if those particles are round.  I chose to use a formula that calculates an impulse collision force using not only mass and velocity, but also using friction and rotation.

For the forces of attraction I reasoned as follows:
What exactly is happening when I hold a solid object in my hand ?  My fingers are pressing against the sides of the object, coming into direct contact with the surface atoms/molecules. When I rotate that object, my fingers are applying a force to those surface atoms, which in turn causes those atoms to move.  This movement will naturally mean that the underlying atoms, the ones just below the surface, will also have to move.  So the force from my fingers is being transmitted through all the particles, causing an overall net movement of the object.

This force is traveling as a wave through the object, with each particle momentarily pushing against it's neighbor. The wave continues until all the particles come back to a state of equilibrium that represents the shape of the object.



If we define the position of each particle in terms of distance and orientation to it's neighbors, then if a particle moves, we need only to calculate the force required to re-position the neighbors back into the correct distance and orientation.  By changing the behavior of the restoring force we can define the properties of the object. A weak force will result in a rubbery or stretchy material, a strong force will give a rigid or solid material.

Rigid Body Rotation
APC takes a unique approach when it comes to rotation.  Most physics engines will determine the torque based on center of mass and body topology.  In APC the total mass and the center of mass remain unknown.  There is in fact only one aggregate value used, the total torque of all interacting particles.  The torque is averaged and applied to a global angular velocity for the body.  This angular velocity is then applied to all join vectors in the next frame, resulting in stable rotation of the body.

All the weird and wonderful things you can do in APC are derived from these principles.
« Last Edit: June 09, 2018, 06:54:43 PM by AaronB » Logged

AaronB
Level 2
**



View Profile WWW
« Reply #1 on: January 04, 2017, 10:11:09 PM »

When developing APC one of the first things I experimented with was dynamically varying the size of particles.  This allowed for some interesting physical properties using just the collision formula.  Of course then I needed a zoom function to investigate the smaller particle interactions, which now meant the simulation was not confined to the size of your monitor.  Mathematically you can view the world of APC within the boundaries of a single precision floating point number.  I really want it to be double precision but I have not yet figured out how to do efficient gpu atomic operations on double floats (hint to gpu manufacturers  Beg )



« Last Edit: June 09, 2018, 06:55:24 PM by AaronB » Logged

AaronB
Level 2
**



View Profile WWW
« Reply #2 on: January 06, 2017, 04:13:53 PM »

This example shows how particle properties can be changed not only via the gui but also programmatically.  APC supports live coding for all particle properties.  This includes the geometry and fragment shaders for the appearance and lighting plus two compute shaders for particle interactions and forces.



« Last Edit: June 09, 2018, 06:56:21 PM by AaronB » Logged

a-k-
Level 2
**


View Profile
« Reply #3 on: January 07, 2017, 04:05:59 AM »

Extremely cool! Would love to hear something about the tech you're using to implement all of that...
Logged

AaronB
Level 2
**



View Profile WWW
« Reply #4 on: January 07, 2017, 05:42:02 PM »

Extremely cool! Would love to hear something about the tech you're using to implement all of that...

CodeLite (c++), OpenGL, FreeGlut, GLSL, TinySound and my brain...

The editor framework and gpu physics engine is homegrown.

The particle collision response began with this discussion:
https://www.gamedev.net/topic/212672-ball-collision-with-spin/

The rigid body behavior is from many hours of experimentation.

(I've updated the first post with a bit more detail on rigid body rotation)
« Last Edit: January 07, 2017, 06:48:03 PM by AaronB » Logged

AaronB
Level 2
**



View Profile WWW
« Reply #5 on: January 09, 2017, 01:58:25 AM »

I've been developing APC on my somewhat aging ASUS G73 laptop which has a GeForce GTX 460M gpu.  Under this configuration I can get 30fps for up to 8000 particles which is probably on par with a cpu only implementation.  My other test platform has an AMD R9 270 which can push 65,000 particles at 30fps:





I am getting close to releasing a demo version. It will be very interesting to get feedback on the frame rates for more recent video cards Smiley
« Last Edit: June 09, 2018, 06:57:40 PM by AaronB » Logged

Smerik
Level 1
*



View Profile
« Reply #6 on: January 25, 2017, 02:27:46 AM »

Would love to see this running on my Intel Hd Graphics 520!
The colors that we see is that the surface tension?
Logged

AaronB
Level 2
**



View Profile WWW
« Reply #7 on: January 25, 2017, 03:19:08 AM »

Would love to see this running on my Intel Hd Graphics 520!
Yes, that would be interesting...

The colors that we see is that the surface tension?
The color represents the sum of the forces (magnitude only) from collisions.  Probably more representative of compression than surface tension.
Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #8 on: January 25, 2017, 06:32:55 AM »

SHUT UP AND TAKE MY MONEY  Hand Money Left Angry Hand Money Right

I like it.
Logged

AaronB
Level 2
**



View Profile WWW
« Reply #9 on: January 25, 2017, 12:18:11 PM »

SHUT UP AND TAKE MY MONEY  Hand Money Left Angry Hand Money Right

I like memes.
Logged

AaronB
Level 2
**



View Profile WWW
« Reply #10 on: February 03, 2017, 01:49:08 AM »

Inspired by standardcombo's cool ascii art in Stone Story RPG

I now present APC ASCII particles (tada)!!!





This bit of retro was done by modifying the particle geometry shader to draw the particle at discrete intervals (using modulo particle size).  The underlying particle position still remains unchanged.

I also abuse the fact that the pipe, dash, forward slash and backslash are just a straight line rotated through 45 degrees.  The weird +450 is to prevent modulo of negative angles.

Code:
// display particle at  discrete intervals
position.x = int (position.x + particles[p].size) - int(position.x) % int(2*particles[p].size);
position.y = int (position.y + particles[p].size) - int(position.y) % int(2*particles[p].size);

int ang = int (particles[p].orientation / PI * 180.0 + 22.5 + 450); // convert to integer degrees
ang = ang - (ang % 45);                                             // find nearest multiple of 45 degrees
float ori = float(ang) / 180.0 * PI;                                // back to radians
    
// draw the line – the invocation is overkill here but keeping for consistency
for (int i = gl_InvocationID; i <= gl_InvocationID + 1; i++)
{
    vec2 point = position + (particles[p].size * 0.8) * vec2 (cos(PI * i + ori), sin(PI * i + ori));
    gl_Position = world_transform (p, point);
    EmitVertex();
}
« Last Edit: June 09, 2018, 06:58:29 PM by AaronB » Logged

AaronB
Level 2
**



View Profile WWW
« Reply #11 on: February 12, 2017, 09:25:19 PM »

Visualizing forces on bodies with different rigidity:

Logged

AaronB
Level 2
**



View Profile WWW
« Reply #12 on: February 14, 2017, 10:08:29 PM »

Testing collision response for different particle masses (size).



Logged

qMopey
Level 6
*


View Profile WWW
« Reply #13 on: February 17, 2017, 08:50:07 PM »

Posting for follow! Great particles Smiley
Logged
AaronB
Level 2
**



View Profile WWW
« Reply #14 on: February 19, 2017, 06:58:00 PM »

Having fun testing multiply joined rigid bodies and their collision response:



-----------------------------------------------

Modeling a world on particles has proven to be challenging.  The physics algorithm needs to accurately balance all the forces between hundreds (or thousands) of particles.  Rounding errors in the arithmetic can lead to instability of the simulation.  In the following video the smaller particles have become unstable, creating a definite hazard for the other objects in the scene:

Logged

AaronB
Level 2
**



View Profile WWW
« Reply #15 on: February 21, 2017, 02:23:01 AM »

Today is a good day Smiley

Finally happy with the core physics engine.  I introduced a new global variable that defines the base unit of mass; and this had a profound affect on stability.  The global mass constant affects ONLY mass and NOT gravity.

I wonder if our reality would behave in a similar way if the carbon-12 atom should suddenly get 'heavier' ?
https://en.wikipedia.org/wiki/Atomic_mass_constant

mass constant of 1:



mass constant of 15:

Logged

AaronB
Level 2
**



View Profile WWW
« Reply #16 on: February 22, 2017, 11:45:33 AM »

Placing the core physics engine entirely on the GPU has met my first goal – to see a non exponential decrease in frame rate with an increasing number of particles.  However something quite unexpected also occurred...

The collision calculation on each particle is processed in parallel, however this presents a problem for particles undergoing multiple collisions in a single time frame. In a single threaded environment you would process each collision response in turn, updating the instantaneous velocity and position for each particle before processing the next.  In a parallel environment the collision response between each particle can happen in any order. The instantaneous velocities and positions are not guaranteed to be identical when particles A and B calculate their response against each other.  Initially I thought this would be a big problem, particularly since atomic operations cannot resolve this type of timing issue without a significant performance cost.  Of course I was curious to see what would happen, so I went ahead using unprotected reads and writes for the velocity and position.

The result was not complete mayhem, but a truly random progression of the simulation.  The following gifs show the same particle configuration copied and pasted.  Each copy has exactly the same starting conditions in terms of relative position and velocity.  However, as you can see, the outcome varies greatly for each copy.  A pseudo random number generator is NOT used unless two particles have the exact same position, which certainly isn't the case for the early stages of the simulation shown.

322 particles:


1308 particles:


5232 particles:


20928 particles:



So there you have it – a parallel simulation based on particles with a chaotic progression.  From a gaming point of view I can honestly say that no two games will ever play alike Smiley
Logged

diegzumillo
Level 10
*****


This avatar is so old I still have a some hair


View Profile WWW
« Reply #17 on: February 22, 2017, 12:10:12 PM »

Very interesting! The order of operations is *clears throat* noncommutative  Gentleman
Logged

qMopey
Level 6
*


View Profile WWW
« Reply #18 on: February 22, 2017, 12:38:38 PM »

A very interesting way to make a *ahem, clears throat* bloody mess  Gentleman
Logged
AaronB
Level 2
**



View Profile WWW
« Reply #19 on: February 22, 2017, 03:13:17 PM »

Very interesting! The order of operations is *clears throat* noncommutative  Gentleman

All I need now is a quantum based GPU... Tongue

A very interesting way to make a *ahem, clears throat* bloody mess  Gentleman


Logged

Pages: [1] 2 3 4
Print
Jump to:  

Theme orange-lt created by panic