Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1410890 Posts in 69591 Topics- by 58581 Members - Latest Member: elpoeprod

October 09, 2024, 05:52:13 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 14194 times)
Xonatron
Level 4
****


Be yourself.


View Profile WWW
« Reply #40 on: June 17, 2017, 06:51:16 AM »

This is awesome. I love exploring physics like this. I have done this a bit with my own title, God Particle: http://xona.com/godparticle/

Following to see what becomes of your game!
Logged

Matthew Doucette, Xona Games
- devlogs: xona.com/tigsource
Xonatron
Level 4
****


Be yourself.


View Profile WWW
« Reply #41 on: June 17, 2017, 07:14:40 AM »

I must have a GPU that is out-of-date. I got some errors when running the .exe:

Quote
Aaron's Particle Space
Copyright 2017 - Aaron Balint
version 0.16.00

Advanced World Entity Shader Objects for Mathematical Enrichment

Compiling AWESOME shaders. This may take a minute...

Shader initialize begin
glewInit...OK
test_program...geometry_template.cs:
ERROR::SHADER::COMPILATION_FAILED
Geometry shader failed to compile with the following errors:
ERROR: 0:656: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:676: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:681: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS

fragment_template.cs:
ERROR::SHADER::COMPILATION_FAILED
Fragment shader failed to compile with the following errors:
ERROR: 0:656: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:676: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:681: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS

light_geometry_template.cs:
ERROR::SHADER::COMPILATION_FAILED
Geometry shader failed to compile with the following errors:
ERROR: 0:656: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:676: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:681: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS

light_fragment_template.cs:
ERROR::SHADER::COMPILATION_FAILED
Fragment shader failed to compile with the following errors:
ERROR: 0:656: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:676: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:681: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS


APC terminated

I am running:
- Intel Core i7 2600 CPU @ 3.40GHz
- AMD Radeon HD 6800 Series
Logged

Matthew Doucette, Xona Games
- devlogs: xona.com/tigsource
qMopey
Level 6
*


View Profile WWW
« Reply #42 on: June 17, 2017, 08:58:08 AM »

Did you ever put any time into optimizing the pitch shifting code? Just wanted to ask since I'm working on that today. If you have anything let me know so I can try to incorporate that into next tinysound update!
Logged
AaronB
Level 2
**



View Profile WWW
« Reply #43 on: June 18, 2017, 03:44:23 AM »

I must have a GPU that is out-of-date. I got some errors when running the .exe:

The physics engine resides entirely on the GPU and has the ability to track trajectory, collisions, reactions, rigid body connections etc for tens of thousands of particles.  To prevent a CPU - GPU memory bottleneck, APC uses quite a few shader storage buffers (currently 16) to store all this information.  From the error message it is almost certain that your graphics card does not support this many buffers Sad

This is awesome. I love exploring physics like this. I have done this a bit with my own title, God Particle: http://xona.com/godparticle/

The emergent behavior from a simple kernel applied to each particle is awe inspiring.

Logged

AaronB
Level 2
**



View Profile WWW
« Reply #44 on: June 18, 2017, 03:49:44 AM »

Did you ever put any time into optimizing the pitch shifting code? Just wanted to ask since I'm working on that today. If you have anything let me know so I can try to incorporate that into next tinysound update!

I've limited the number of concurrent sound effects from particle reactions to eight, as the human brain can't really differentiate beyond this - at least mine can't anyways Smiley

Sound optimization has not been a priority at this stage.
Logged

helloya2
TIGBaby
*


View Profile
« Reply #45 on: June 18, 2017, 08:31:58 AM »

"Aaron's Particle Space
Copyright 2017 - Aaron Balint
version 0.16.00

Advanced World Entity Shader Objects for Mathematical Enrichment

Compiling AWESOME shaders. This may take a minute...

Shader initialize begin
glewInit...OK
test_program...geometry_template.cs:
ERROR::SHADER::COMPILATION_FAILED
Geometry shader failed to compile with the following errors:
ERROR: 0:656: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:676: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:681: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS

fragment_template.cs:
ERROR::SHADER::COMPILATION_FAILED
Fragment shader failed to compile with the following errors:
ERROR: 0:656: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:676: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:681: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS

light_geometry_template.cs:
ERROR::SHADER::COMPILATION_FAILED
Geometry shader failed to compile with the following errors:
ERROR: 0:656: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:676: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:681: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS

light_fragment_template.cs:
ERROR::SHADER::COMPILATION_FAILED
Fragment shader failed to compile with the following errors:
ERROR: 0:656: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:676: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS
ERROR: 0:681: error(#385) Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS


APC terminated"

This problem can be solved only by changing the video card?
Really want to play it.
Logged
qMopey
Level 6
*


View Profile WWW
« Reply #46 on: June 18, 2017, 01:45:49 PM »

Did you ever put any time into optimizing the pitch shifting code? Just wanted to ask since I'm working on that today. If you have anything let me know so I can try to incorporate that into next tinysound update!

I've limited the number of concurrent sound effects from particle reactions to eight, as the human brain can't really differentiate beyond this - at least mine can't anyways Smiley

Sound optimization has not been a priority at this stage.

Gotcha. Updated tinysound with my optimizations. Pitch shifting uses an order of magnitude less memory. I didn't do any definitive profiling, but it is definitely running much faster. As far as I can tell, setting TS_PITCH_QUALITY to 8 runs about as fast as the old 4, which suggests around an order of magnitude speed difference. But I'm not exactly sure. Anyways, just letting you know since you're the only one I know that makes use of the pitch shifting (besides myself) right now!
Logged
AaronB
Level 2
**



View Profile WWW
« Reply #47 on: June 19, 2017, 02:36:41 AM »

Binding point for: buffer block must be equal or greater than 0 and less than: GL_MAX_SHADER_STORAGE_BUFFER_OBJECT_BINDINGS

This problem can be solved only by changing the video card?
Really want to play it.

From the output it appears the test_program shader compiled OK, so chances are the buffer limitation is the only issue.  From a quick analysis it looks like I might be able to halve the number of buffers required.  I'll see what I can do.
Logged

AaronB
Level 2
**



View Profile WWW
« Reply #48 on: June 19, 2017, 02:54:46 AM »

Did you ever put any time into optimizing the pitch shifting code? Just wanted to ask since I'm working on that today. If you have anything let me know so I can try to incorporate that into next tinysound update!

I've limited the number of concurrent sound effects from particle reactions to eight, as the human brain can't really differentiate beyond this - at least mine can't anyways Smiley

Sound optimization has not been a priority at this stage.

Gotcha. Updated tinysound with my optimizations. Pitch shifting uses an order of magnitude less memory. I didn't do any definitive profiling, but it is definitely running much faster. As far as I can tell, setting TS_PITCH_QUALITY to 8 runs about as fast as the old 4, which suggests around an order of magnitude speed difference. But I'm not exactly sure. Anyways, just letting you know since you're the only one I know that makes use of the pitch shifting (besides myself) right now!

Sweet.  I'll check it out when I get a chance.
Logged

Bluebutton
Level 0
***



View Profile WWW
« Reply #49 on: June 19, 2017, 04:01:52 AM »

The technical ability in this project is just unbelievable. I wouldn't even know where to start.
Logged

Xonatron
Level 4
****


Be yourself.


View Profile WWW
« Reply #50 on: June 19, 2017, 10:19:17 AM »

Thanks for the breakdown. How can I determine the number of storage buffers a given GPU has?
Logged

Matthew Doucette, Xona Games
- devlogs: xona.com/tigsource
AaronB
Level 2
**



View Profile WWW
« Reply #51 on: June 19, 2017, 07:59:57 PM »

The technical ability in this project is just unbelievable. I wouldn't even know where to start.

Thanks Bluebutton Embarrassed.  My real challenge now is knowing where to finish it.  BlinkBlink
« Last Edit: June 19, 2017, 08:33:03 PM by AaronB » Logged

AaronB
Level 2
**



View Profile WWW
« Reply #52 on: June 19, 2017, 08:31:49 PM »

Thanks for the breakdown. How can I determine the number of storage buffers a given GPU has?

Download and run the following:
http://netplay.com.au/particle-space/utils/GLpeek.exe

It will report the maximum number of compute shader buffers allowed for your card.  Please let me know if the answer is 16 or more as this implies the problem lies elsewhere.

For those wondering why I have so many buffers it is because APC makes heavy use of variable sized arrays. Unfortunately you can only have one variable sized array per buffer:
https://www.khronos.org/opengl/wiki/Shader_Storage_Buffer_Object

@Xonatron + helloya2

I'm sorry, I did try reducing the number of buffers by making some structures fixed in size, however this had terrible performance issues when compiling the shaders - the optimization stage went from 2 seconds to 15 minutes for just one shader! APC is using the GPU in a slightly unconventional manner and really does benefit from more recent GPU technology.
« Last Edit: June 09, 2018, 06:41:53 PM by AaronB » Logged

buto
Level 0
***



View Profile WWW
« Reply #53 on: June 20, 2017, 05:21:17 AM »

Really cool stuff! Those interacting particles are always so nice to watch!

Having a GPU based implementation obviously pays off regarding the number particles. Did you encounter difficulties when it comes to designing your minigames? Is the random outcome you mentioned earlier (due to parallelization issues) restricting when it comes to designing mini-games?

I'm also using particles and softbodies in my game, albeit in a much more restricted way. The main characters are modeled by a couple of particles which are interconnected by springs. Fluids are modelled using more particles with attraction/repulsion. Everything takes place in a rather static (but destructible) surrounding (vector-based). I described it a bit in this thread: https://forums.tigsource.com/index.php?topic=51779.msg1208483#msg1208483

Just in case you're interested, there's also a feedback thread on TIGS (with gifs): https://forums.tigsource.com/index.php?topic=52509.0

It would be great to hear some of the technical details of your implementation. How do you find particles which influence each other? Do you use space-partitioning on the GPU? etc...

Again: Cool stuff!

Kind regards,
Sebastian
Logged

Xonatron
Level 4
****


Be yourself.


View Profile WWW
« Reply #54 on: June 20, 2017, 02:31:56 PM »

AaronB,

GLpeek.exe reports for my system:

Quote
GLpeek - NetPlay Software 2017

4.5.13399 Compatibility Profile Context 15.201.1151.1008
Compute storage buffers allowed = 8

Logged

Matthew Doucette, Xona Games
- devlogs: xona.com/tigsource
AaronB
Level 2
**



View Profile WWW
« Reply #55 on: June 20, 2017, 05:26:24 PM »

GLpeek.exe reports for my system:
Quote
GLpeek - NetPlay Software 2017
4.5.13399 Compatibility Profile Context 15.201.1151.1008
Compute storage buffers allowed = 8


Nailed it!

Sorry Xonatron - I think your GPU is just one generation short from running APC Sad

It would be great to hear some of the technical details of your implementation. How do you find particles which influence each other? Do you use space-partitioning on the GPU? etc...

The short answer is yes.  When thinking how to word the long answer I had a sudden epiphany with regards to resolving spacial awareness in a parallel environment - I'll get back to you on this one (thanks for asking).

I had a quick look at https://forums.tigsource.com/index.php?topic=52509.0
That lava effect is awesome! Will definitely take a closer look when I get the chance.
« Last Edit: June 20, 2017, 05:36:40 PM by AaronB » Logged

AaronB
Level 2
**



View Profile WWW
« Reply #56 on: June 22, 2017, 09:04:19 PM »

Did you encounter difficulties when it comes to designing your minigames? Is the random outcome you mentioned earlier (due to parallelization issues) restricting when it comes to designing mini-games?

It still awes me to think that the engine behavior is dictated by the chaotic movement of electrons - it somehow feels you are truly connected with reality.

To answer your question - when play testing, unpredictable things do crop up, however I've taken the mind set that this is actually fun.  Take this for example:



If you are determined you can get the car to jump over the obstacle if it rebounds in a certain way - but it might take 100 or more attempts.  I watched my sons play this and they got so excited when this happened.  They also invented there own game by stretching the slingshot all the way across the screen and then balancing the balls into the upper nets.  It got really intense and I didn't plan any of it. I think this is the great thing about physics simulations - the opportunity to explore the simulated reality in your own way.

It would be great to hear some of the technical details of your implementation. How do you find particles which influence each other? Do you use space-partitioning on the GPU? etc...

The entire engine resides on the GPU and the particle array is completely isolated from the CPU (except for saving and loading).  All gui input is communicated through a small storage buffer. With regards to spatial awareness I use a quadtree for both collisions and non rigid forces.

The tricky part for particle awareness was developing a parallel approach that was fast. I eventually came up with this:
Code:
#define MAX_PARTICLES_PER_QUAD 8

struct QuadtreeStruct
{
    int   sub_quad[4];  // index to next level in quadtree
    int   count   [4];  // number of particles in each node
    int   particle[4][MAX_PARTICLES_PER_QUAD]; // particle indexes for each node
};

layout (std430, binding=1) buffer Quad_array
{
    QuadtreeStruct quad_array[];
};

void main()
{
    int particle_index = int (gl_GlobalInvocationID.x);
    
    // make sure we cover all possible contacting particles of similar size
    for (int y2 = -1; y2 <= 1; y2++)
    {
        for (int x2 = -1; x2 <= 1; x2++)
        {
            float x = particle_position.x + (particle_diameter * x2);
            float y = particle_position.y + (particle_diameter * y2);

            int quad_base = 0;
            float quad_size = g.quad_size; // global largest quad size

            for (;;)
            {
                int quad = (int (y / quad_size) % 2) * 2 + (int (x / quad_size) % 2);

                if (particle_diameter >= quad_size / 2.0)
                {
                    // check particle not already added to quad
                    int limit = min (quad_array[quad_base].count[quad], MAX_PARTICLES_PER_QUAD);
                    int j = 0; for (; j < limit; j++) if (quad_array[quad_base].particle[quad][j] == particle_index) break;
                    
                    // add to quad and exit this traversal
                    if (j == limit) quad_array[quad_base].particle[quad][atomicAdd (quad_array[quad_base].count[quad], 1) % MAX_PARTICLES_PER_QUAD] = particle_index;                  
                    break;
                }

                // go to next level - zero return implies this particle is the first to enter the quad
                int sub_quad = atomicCompSwap (quad_array[quad_base].sub_quad[quad], 0, -(particle_index+1));

                if (sub_quad == 0)
                {
                    // fetch a new quad from the global array
                    sub_quad = atomicAdd (g.quad_count, 1) + 1;

                    if (sub_quad >= MAX_QUADS) break; // oops

                    // initialize
                    for (int i=0; i<4; i++)
                    {
                        quad_array[sub_quad].count[i] = 0;
                        quad_array[sub_quad].sub_quad[i] = 0;
                    }

                    // add to quadtree
                    quad_array[quad_base].sub_quad[quad] = sub_quad;
                }

                if (sub_quad < 0) break; // safety check

                // go to next level in tree
                quad_size = quad_size / 2;
                quad_base = sub_quad;
            }
        }
    }
}

Note the use of atomicCompSwap to decide which invocation allocates the next node.  All particles of similar size sit at the same level in the tree.

To check for collisions we traverse the quadtree at the particles position:
Code:
   int particle_index = int (gl_GlobalInvocationID.x);

    int quad_base = 0;
    float quad_size = g.quad_size;

    for (;;)
    {
        int quad = (int (particle_position.y / quad_size) % 2) * 2 + (int (particle_position.x / quad_size) % 2);

        for (int i=0; i < quad_array[quad_base].count[quad] && i < MAX_PARTICLES_PER_QUAD; i++)
        {
            int p2 = quad_array[quad_base].particle[quad][i];
            if (particle_index != p2) collide (particle_index, p2);
        }

        quad_base = quad_array[quad_base].sub_quad[quad];
        if (quad_base == 0) break;
        quad_size = quad_size / 2;
    }

For forces I swap the particle diameter for the force range and build a corresponding quadtree.  The same traversal is then used to determine which particles are exerting a force - and then apply the corresponding force equation.

« Last Edit: June 22, 2017, 09:33:32 PM by AaronB » Logged

buto
Level 0
***



View Profile WWW
« Reply #57 on: June 23, 2017, 03:53:58 AM »

Thank's so much for sharing your insight! Good idea to raise you own playtesters! Smiley

Looking forward for updates.

Kind regards,
Sebastian
Logged

AaronB
Level 2
**



View Profile WWW
« Reply #58 on: July 02, 2017, 06:41:24 PM »

Testing pendulum behavior:


and some interesting visual effects:

« Last Edit: July 02, 2017, 06:47:17 PM by AaronB » Logged

AaronB
Level 2
**



View Profile WWW
« Reply #59 on: July 02, 2017, 09:28:04 PM »

One of the enjoyable things during development is coming up with ideas to test the physics engine.  The pendulums in the previous post is one such test.  Another scenario (which has proven to be quite challenging) is lifting a heavy weight with a coil of rope.  In this test the rope is made up of many small particles and at 60 updates per second acts more like a very heavy bungee cord:



« Last Edit: June 09, 2018, 06:45:38 PM by AaronB » Logged

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

Theme orange-lt created by panic