next »

[Xonatron]

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!

[Xonatron]

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

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

[qMopey]

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!

[AaronB]

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

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.

[AaronB]

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

Sound optimization has not been a priority at this stage.

[helloya2]

"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.

[qMopey]

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

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!

[AaronB]

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.

[AaronB]

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

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.

[Bluebutton]

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

[Xonatron]

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

[AaronB]

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

Thanks Bluebutton .  My real challenge now is knowing where to finish it.  

[AaronB]

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.

[buto]

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

[Xonatron]

AaronB,

GLpeek.exe reports for my system:

GLpeek - NetPlay Software 2017

4.5.13399 Compatibility Profile Context 15.201.1151.1008
Compute storage buffers allowed = 8

[AaronB]

GLpeek.exe reports for my system:

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

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.

[AaronB]

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.

[buto]

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

Looking forward for updates.

Kind regards,
Sebastian

[AaronB]

Testing pendulum behavior:


and some interesting visual effects:

[AaronB]

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: