วีดีโอ

Bottom up. See the section on optimizations for more enhancements. Liquids are only processed once, during their processing you can check multiple potential cells and choose the farthest/most appropriate one.

It is possible to run a falling sand sim on the GPU but it would be much more challenging to achieve the same level of functionality as I have in this simulation.

Yes mine is CPU based. I think to implement all the functionality I have in this simulation on a GPU would be more difficult. But a GPU would be much faster and able to handle more particles overall. There is a game called "Jelly In The Sky" which is entirely run on the GPU which might be interesting to look into.

@@marf1610 yeah I don't think I'll go as deep as you, I'll try to get a few things working and submit it lol. I'll check that game, thanks a bunch

Are you trying to use the mac version? I was never able to get it to work for mac. I just redownloaded the windows version (on a windows machine) and it works as expected.

@@marf1610 no, I tried to run the windows version, it appears in the task manager for half a second and immediately disappears every time I tried to run

Agreed. Really cool seeing everyone else's approaches on this subject. Your simulation looks incredible so far. You already have the rigidbodies working really cleanly. Do you know yet how you plan to network the sand simulation? I imagine that would be very challenging.

Thanks, I'm glad you like it. The current plan for networking is to ensure the simulation is deterministic in such a way that it can also be multi threaded. Both the server and clients run the same simulation. Each chunk is responsible for it's own RNG with the seed being set based on the chunk coordinates in the world. Each chunk also keeps a hash that loosely represents the state of itself as modifications occur within the chunk. Every n ticks, the server and clients will add together each chunk state hash and compare. If there is a discrepancy, the simulation is paused and they will identify what chunks are different based on the chunk hash, the server will then send the chunk data to the client to be overwritten, resuming the simulation when completed. As for synchronising rigidbodies, the current idea I have is to find all rigidbodies that overlap chunks that need to be overwritten (by querying the Box2D world) and also overwrite them. The network data is compressed using LZ4 and send over a reliable UDP connection. No visual information about a pixel is sent (like colour) which helps with compression (with the exception of rigidbodies). Things things like darkened explosion marks won't be sent but the client knows what colour a pixel should be by default anyway. Now you might run into a problem that a client simulation falls behind when there's a lot to process due to variability in processing power. And how do you queue up actions so that they occur on the same simulation tick across all clients? In these cases, I'm looking into how games like Factorio synchronises things (mainly a technique called deterministic lockstep) as there's some overlap between that solution and these problems. Part of the first problem requires the ability to step the simulation forward n amount of ticks so that all clients can catch up to each other, which is not really an issue when the simulation is deterministic. If there are too many chunk discrepancies per second or a client is running on a literal potato and can never catch up, the connection can be terminated in that case. There's still a lot to solve and I'm not sure what the optimal approaches are, however that's the plan so far and I've at least laid some of the foundation for this approach to work. If you're still interested in pursuing falling sand simulations, I'd be more than happy to give you access to the repo and I'm always free to chat about it/explain my approach towards any and all features. Discord: @exzilorate Thanks for reading this long mess of an explanation lol

@@exzilorate Thanks for the detailed write up. Conceptually, that all make sense. And if you begin working on the simulation with the deterministic 'physics' behavior in mind that can help a lot. I'll reach out on discord!

Check out Sebastian Lague's video titled 'Coding Adventure: Ant and Slime Simulations' He goes into great detail on how make this.

I did this project as a way to get more experience with Java since I was using it at work (web dev). This is why many of my approaches are not as well suited for game dev. Also, this was the first time I ever worked with multi-threading. So it was simply an oversight and lack of knowledge on my part. Good catch.

@@marf1610 no worries! i was just curious if there was a reason behind it is all. the project is really awesome, just when i heard it that was one thing that i was like "hold on every frame? that wouldnt be very fast" and i had come across a similar issue in the past working on a project. so was just throwing it out there. thank you for sharing your journey on it

It is possible to code a falling sand sim via shaders but overall you have much less control over state and processing (like what you were mentioning). Most of the things described in this video could not be done on the GPU. Look into "Jelly In The Sky" for a game made on the GPU.

Oh yeah I see a lot of similarities between our simulations haha. I love what you did with the lighting too.

@@marf1610 Thanks! I think the lighting turned out really well too. I spent way too much time fiddling with it to get the right specularity, diffuse, ambient behaviour. I also like your concrete setting idea, I didn't think of taking it to that level. I got bogged down in fleshing out too many features and as you can see started turning it into a 2D spaceship game lol. Would love to work on it again, but don't reallly have time to focus.

Note: that last part (gasses) would likely require a pressure gradient over the vertical axis to solve with.

you're literally still procrastinating

@@lOmaine777, it has been 3 weeks. How did I know that I'm still procrastinating?

Yes that is a side effect. Some cells could be processed multiple times and some could be skipped. Randomizing the order of processing within each row seems to mitigate most of the visual effects from that. And 60 fps also makes it difficult to tell that is happening. But as you've described that can happen. I didn't realize it was happening until after I made the video actually.

I believe in the case of Noita, each cell knows what tick it was updated. The simulation has a "tick" counter that increases by 1 each simulation step. When it's time to process a cell, you check if it has been updated this tick, if not, process the cell and set that cell's tick number to match the simulation tick counter.

I gave each element instance a velocity value which was updated each frame by gravity and can be affected by other things such as explosions. Each element also had two sets of coordinates. Integer coordinates which are its placement in the grid. And floating point coordinates which are updated by the velocity. So if a single element is in free fall for a long uninterrupted time, its velocity will increase as the force of gravity accumulates each frame. If Y velocity is greater than 1 it will move one cell, if velocity it greater than 2 it will move 2 cells. Then the floating point coordinates are rounded down and that's the new placement in the matrix for that element

​@@marf1610Thanks, nice vid👍

Basically, yes. At the start of every frame each chunk has shouldStepThisFrame set to the value of shouldStepNextFrame. And then shouldStepNextFrame is set to false for all chunks. Throughout the current frame shouldStepNextFrame is set to true for chunks which have activity in them.

@@marf1610 Thanks for the quick reply. Fortunately I figured it out 15 minutes after posting my comment. Your video has been very helpful! Wish you well.

I don't have much experience with Python but looks like you could try using Pygame as a starting point.

For this project I iterated through the matrix and drew squares (or rectangles if there were multiple sequential cells with the same color) with the debug tool. This was extremely inefficient and inflexible. I have tried on two other platforms to code a better way to generate a texture that is more flexible and quicker to generate. But I think it requires more lower level knowledge of graphics programming than I currently have. Most game engines aren't well suited for this type of project which makes it require a lot of custom solutions once you get past initial implementations.

@@marf1610 thank you so much. I ended up using shaders for this, passing in the grid size and sprite position. I’m currently trying to implement multi threading but struggling. Can you give me any pointers? I’m using godot 4, and can call Thread.new(callable) and have an update_position that I was using to move the sprites in my grid. How might I go about doing this? I’m able to split the grid up into columns. Thanks for your reply!

Yeah thats a great thought. I know other older sand simulations implemented some sort of pressure system but integrating it with the inertial resistance could provide some interesting results.