Xonatron
|
|
« 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
|
|
|
|
Xonatron
|
|
« 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: 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
|
|
|
|
qMopey
|
|
« 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
|
|
« 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 The emergent behavior from a simple kernel applied to each particle is awe inspiring.
|
|
|
Logged
|
|
|
|
AaronB
|
|
« 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 Sound optimization has not been a priority at this stage.
|
|
|
Logged
|
|
|
|
helloya2
TIGBaby
|
|
« 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
|
|
« 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 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
|
|
« 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
|
|
« 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 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
|
|
« 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
|
|
« 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
|
|
|
|
AaronB
|
|
« 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 . My real challenge now is knowing where to finish it.
|
|
« Last Edit: June 19, 2017, 08:33:03 PM by AaronB »
|
Logged
|
|
|
|
AaronB
|
|
« 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.exeIt 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
|
|
« 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#msg1208483Just in case you're interested, there's also a feedback thread on TIGS (with gifs): https://forums.tigsource.com/index.php?topic=52509.0It 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
|
|
« Reply #54 on: June 20, 2017, 02:31:56 PM » |
|
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
|
|
|
Logged
|
|
|
|
AaronB
|
|
« Reply #55 on: June 20, 2017, 05:26:24 PM » |
|
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.0That 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
|
|
« 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: #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: 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
|
|
« 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! Looking forward for updates. Kind regards, Sebastian
|
|
|
Logged
|
|
|
|
AaronB
|
|
« 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
|
|
« 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
|
|
|
|
|