you're literally still procrastinating

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

Thanks for sharing your experience! I checked out your Sand Games and really liked the plant growing mechanics. Up to this point in development I didn't encounter much issue with adding new classes but I could definitely see the effort exponentiate as you add more unique features that each new element must account for.

There are also way too many megamorphic virtual calls everywhere

simulation without physics is not a simulation, ad physic without math is not physic. but the bigest problem is not the physic but the code optimisation.

@@skymanclaw441well… that’s not exactly true. I simulate math problems with random variables occasionally and that doesn’t have any physics involved. For example: what is the average length of two random points selected within a 1x1 square assuming equal distribution? You can solve this problem by integrating the distance formula over a 1x1 square, or you can just simulate 10k pairs of random points selected in a 1x1 square, take the distance for each pair then take the average.

​@@blablabla7796 They said physics without math it's not physics, they didn't said maths without physics is not math

@@secrom36 no, they said simulation without physics is not a simulation. That’s literally the first line in their message.

Hey! I'm so glad you found the information useful and hope you're able to solve those problems you were stuck on before. Thanks for letting me know the video helped you.

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!

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.

L

This one made it through! I'm glad that this information was useful.

Thanks! Gasses and fluids do not have pressure in my simulation. So in your example with the U bend, one side would stay higher than the other and would not balance out. This is the same in Noita, it would definitely be possible to add fluid pressure to the simulation but that would probably be pretty expensive. Just depends on what you are trying to accomplish. With the line algorithm, if I am understanding your question correctly, yes a fluid could passes "between" two solid elements if they are diagonal from each other. You could adjust the algorithm to not allow that, but it just depends on what you want to do.

exactly the same. although i'll just stick to making my own engine in C++, as always. Unity is an engine far too large for a sand simulation. and super inefficient for that too; with my computer, i can't sacrifice even the smallest bit of performance. Also, you get striketrough with minus signs in youtube comments, not tildes.

Hey thanks! The way I implemented fire is that certain elements are flammable (as opposed to fire being its own element). If I want a material to not be flammable I override "receiveHeat()" with a blank definition. Each element has a flammability resistance. When an element receives heat from a neighboring element or explosion, the value passed to receiveHeat() reduces its 'flammability resistance'. Once the resistance reaches 0 the element becomes ignited. It performs all the same element logic it did before except now it also calls the receiveHeat() method on neighboring elements causing the fire to spread. Also the ignited element checks if it is completely surrounded by other elements, this suffocates the fire and if it is surrounded for long enough the element will no longer be ignited and its flammability resistance will be reset. I like this method because it gives more life to the simulation and also it seems more along the lines of what Noita does. If you choose to just convert an element to a "fire" element then you lose any state that was associated with the element and it can't be extinguished. However, this does requires a lot more processing power to apply heat to neighboring elements and also check if it is surrounded, thats a lot of "get" calls to the matrix just for one ignited element.

@SCREAMINGSNAKE Thanks for the explanation. It seems like a very good idea. I'm currently finishing a sand game which just updates numbers on the array ( eg. if(grid[x][y] == 3) { update_sand(x, y) } ) which takes only the very basic things into account (since I store all info about a cell in one uint8). The way I implemented fire is that, after it moves, it also check for the neighboring flammable elements and has a random chance to change them into fire. After I finish this up, I want to rewrite it into full OOP (every cell is an object) like you did in the video. Once again thanks for the explanation, and have a nice day.

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

Bresenham's algorithm seems exactly along the line of what I'm looking for. Thanks for the suggestion. I have each cell at whole number coordinates. If an element has a velocity on the x or y axis less than 1, then each frame it accumulates the velocity in another variable until it is greater than 1 at which point it will move one cell in that direction. So if an element has an x velocity of 0.4 then it will move 1 cell over on the x axis 3 frames later. Not sure why I did it that way, and I completely forgot I implemented that until looked it up just now but it seems like a different way of accomplishing the same thing.

@@marf1610 On the efficiency of Bresenham's algorithm, I have found your approach to be marginally better in my case. I'm guessing it's due to having a small bit of branching logic in Bresenham's, instead of a mostly mathematical approach from yours. I was working on a FSG several months ago and cant remember the exact details but I was fairly surprised at the outcome of my tests. Mine is coded in C and compiled with gcc with optimizations on max during my tests so I'm not sure if that would have a different outcome in Java. Also I was calling the line drawing way too much as I was taking a different approach to velocity. I was attempting a data-oriented system and was hoping to have liquids, solids and gasses be emergent from how I was simulating. Long story short, the change in efficiency is likely trivial and your approach is surprisingly effective for this.

Hmmmm...interesting. Thanks for sharing your findings! I will consider this as I port the simulation over to C++. Maybe I'll try comparing the two approaches and see what I find.

What I have done in this simulation is update from the bottom row to the top and the update order within each row is random. Another adjustment I made after I implemented velocity was if a piece of sand is falling down and encounters another element that is also currently falling then it will stay above that element and match its velocity. That prevents clumps of falling elements from breaking apart mid-air.

@@marf1610 Thanks for the answer!

Tracking velocity is a way to expand the rules of the simulation. So if a particle has an X velocity of positive 2 then it will attempt to move 2 cells to the right that frame (checking the contents of each cell along the way). This is different than the basic rules mentioned at the beginning.

Each chunk has shouldStepNextFrame set to false at start of the entire update cycle (before any elements have been updated). As elements update, if they perform any action that would require the chunk to be updated next frame (such as changing position or being on fire) then they set shouldStepNextFrame to true on the chunk. At the start of the next frame shouldStepThisFrame inherits the value of shouldStepNextFrame and shouldStepNextFrame becomes false again. So to directly answer your question, each element knows already if it should update this frame due to the value of shouldStepThisFrame on the chunk it belongs to. It does not know if it should step next frame and that is determined this frame.

After implementing velocity in the simulation the elements no longer check both right and left for a place to go. If the x velocity is positive it only looks to the right and down-right. If it hits a Solid element then the x velocity is multiplied by -1. So next frame it would only look to the left and down-left. This isn't explicitly mentioned in the video. The same logic is applied for solids and gasses. This reduces the amount of cell checking required each frame once liquid begins looking further than one cell away. For liquids the velocity usually indicates just direction. And the maximum is taken between dispersionRate (usually around 5) and velocity for how many cells away to look for an open spot. This ensures it is always looking at least 5 cells away. Also, if a liquid is falling downward for lets say 4 cells and hits a solid then it will launch another function to search right or left (based on velocity direction) another 5 cells. This helped liquid spread out further once it hits the ground when falling.

@@marf1610 Thanks for the very helpful answer. So do you just decide randomly when first creating water what x velocity it should have?

hmm I am not sure what I am missing. my attempt at implementing the spreading as you said has just resulted in water sometimes not falling to the left when it should, and long perfectly straight lines shooting out to the right...

so upon a lot of pain I'm beginning to think this is out of my current scope of possibilities 😅 I'm hitting road block after road block. Hopefully i can come back to this in the future when I'm a better programmer :p

Yes when liquid is created it randomly generates a positive or negative x velocity (Very small so it just indicates direction). Lots of pain is exactly right haha. I spent many hours on this project trying to solve challenges that I was never able to figure out and had to choose a new direction. But all of that work (which sometimes feels wasted) contributes to becoming a better programmer. Good luck!

The step stair problem arose from processing the elements in columns where the columns start and end positions did not change across frames. To fix this I added random offset to the columns start and end positions each frame. The chunk bounds remain the same across all frames and the chunk bounds have no meaningful correlation to the processing threads' column start and end positions. This is different from Noita where the chunks both keep track of if the elements contained need to be processed, and the bounds in which each thread processes elements. In Noita when there is a large body of liquid that begins moving all at once I have consistently seen the step stair effect as the elements fall. It seems unavoidable if your chunks are also the bounds of a processing thread. Moving the bounds of chunks across frames would defeat the purpose of a chunk since it will not have knowledge of the new elements within its bounds after it moves.

@@marf1610 Thanks for the reply! My chunks don't keep track of the elements within, merely a bottomleft position for the chunk and a flag to update the chunk next frame (and a numChangesMade integer). I give a random x and y offset to all chunks apart from the ones at x=0 or y=0 at the start of each physics update. This has totally eliminated the step stair problem although it has broken the code that alerts neighboring chunks to update.

How are you determining the order of processing the elements? Just left to right, bottom to top? Any multithreading? I also update update the elements within each row subsection in a column in a random order.

@@marf1610 I'm processing the chunks left to right, bottom to top in separate threads. For the cells, I create a MoveCell struct for each necessary movement and shuffle those instructions and execute them after all threads are finished. How are you alerting neighboring chunks to wake up if the elements get processed in a random order? Are you passing chunk bounds information whenever you update a cell? I'm using bool onChunkEdgeX = (x%chunkWidth == 0 | (x+1)%chunkWidth == 0)

​@@prodevus Ah yeah so if you are using chunk boundaries to define the regions where threads update then you will always have this stair step looking issue. It makes the most sense to update cells that way. The Noita devs do the chunk checkerboard multithreaded update pattern which allows them to simulate such a large world (similar to what you're doing), but the downside is that you will have those visual artifacts since the bounds of the threads update range always start and end on the same indices across frames. You could try creating a new "chunk" class that only defines the thread update boundaries and references your original chunk logic for if a cell should update or not. You can add offset to these new thread boundaries each frame which would eliminate that stair visual effect but this would require you to check every single coordinate in the simulation and then reference your original chunk logic if that coordinate needs to be updated. To answer your other question, whenever a cell performs some action which would require itself and its chunk to be processed next frame it sends its coordinates the matrix class which determines the appropriate chunk to update and the logic there determines if it is on a chunk boundary.

I would hesitate to say that it could be better due to its added complexity and increased processing requirement to calculate it on the ever changing simulation. The chunk method is very simple to understand and implement. I would be curious to see it implemented that way if you ever do it.

@@marf1610 ohh ... Yeah I got it ... I'm at very basic level and learning rn but I'll surely let you know if I ever could implement the same! Thank you for reply and keep uploading... I'm a huge fan! Keep the good work 🙌🏼

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.

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.

This is something I started working on but didn't complete. My plan was to treat a player character like an element which takes up multiple spaces. Take into account velocity, calculate next position, and iterate to that position checking for blocking elements along the way. It would get tricky for things like how a moving/falling solid shouldn't block a players movement, etc.

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

The issue with falling sand games is that you need pretty low level control over each element in your 2D matrix. And also you need to control the order in which the elements update. If you used Unity and represented each element as a GameObject this would be a huge waste of space and you wouldn't have control over the order of updates (among other limitations). This is why most of the sand simulations you see are not made with a game engine. Because game engines abstract away a lot of the fine control to speed up your development. This is also why the Noita devs created their own custom game engine. When creating the 2D matrix and all the logic for updating elements you are essentially creating a building block of making a game engine. To get started on this I think a very good place would be to use JavaScript and the HTML5 canvas. There are lots of tutorials out there on setting the canvas up and interacting with it. It will not be as performant but it would be a much easier starting place. Also, I think Sandspiel is made with JS and HTML5 canvas.

@@marf1610 thank you so much that was a very detailed answer I appreciate that

I did mention at the end of the video there are likely better ways to accomplish what I had created. I created this over the years while I was learning to code and not until recently did I start to learn about memory management and efficiency. So thanks for your ideas. However, your suggestions depend on what it is you want to accomplish. Sure you could have each particle type represented by a single struct and use that to only define how particles should react to each other. But that gives less control over individual cells. How would you go about staining the color of a cell while it remains of the same element type? Or how would you set an element on fire and then extinguish it and have it retain its original properties? If you wanted a tech demo just for performance purposes you could go with your approach. But the title of the video states how to create a falling sand simulation like Noita, and the methods I describe is more along the lines of what the Noita devs did. The actOnOther method is only for special effects of a specific element subtype. The movement and interaction logic is consistent and inherited from the Liquid, Gas, and Solid types. If I did not use the 'actOnOther' method then I would fill the movement logic at the Liquid class level with innumerable 'if else' statements specifying subtype interactions between Acid and every other element type. The 'actOnOther' method scales with any amount of element types. Since I do not use a double buffer and the matrix is modified in place, then regardless the simulation would need to be split into separate chunks and processed independently to avoid concurrent modification. Check the 'Exploring the Tech and Design of Noita' video linked in the description and they describe their reasons for their design choices.

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.

There is another comment thread on this video where I discuss this with someone else. You can look through that for more details. But the short answer is yes you could get something to work. And I think you can find some Falling Sand in Unity videos on KZfaq. But if you wanted to implement all the things I talk about in this video, you would be fighting against the design of Unity to make it work, you wouldn't be able to make use of the many development tools Unity offers, and this is why the Noita devs built their own engine. Because you need to have specific control over the update loop which Unity takes care of for you normally but would cause issues with something like this.

Generally you would want to use some sort of framework or engine that allows you to create a window and use the provided hooks for update and draw in that window. For this particular project I used LIBGDX since it was lightweight and made for Java. It eventually became a pain to work with since it was so barebones, has a small community, and is primarily for mobile development. There aren't many Java based game engines out there. So you could use LIBGDX. Or if you used C++ you could use SFML. Or for something lightweight and browser based you could use JavaScript with the HTML5 canvas

@@marf1610 hey buddy, nice one for the reply! Have you or are you planning on doing any tutorials for a JavaScript/HTML tutorial for a sand fall game, or any sort of clicking game? I'd be interested to see how you'd go about creating a "game window" and interaction in html/JavaScript.

@@AquaDragon6629 I have thought about doing a follow along tutorial for a very simple HTML/JavaScript falling sand game but I haven't really explored it yet.

@@marf1610 Well, i've subbed, so if you do, i'll be there. I'd love to see it!

@@AquaDragon6629Awesome, thanks for the feedback!

I think you may have tried to compile the C++ falling sand github repo that I had started working on. You want to use the FallingSandJava repo linked in the description. If you are using the Java version then you will need to run the installation process on the gradle file included in the repo to download and install the necessary dependencies.

@@marf1610 oh, so the c++ version is still unfinished? That is the one I wanted to check out

@@gez_4515 Correct. I didn't know any C++ when I started it so I got stuck and got sidetracked doing other C++ projects since then to learn. I am unsure if I will revisit it.

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

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!

The matrix is still processed row by row bottom to top but the update order within each row is random.

@@marf1610 I decided to use random sampling in order to get rid of floodfill jitteriness, but it probably won't cope well with multithreading.

I think there are some videos of sand simulations people have made with Unity. I think you will run into technical limitations if you really try to expand on this down the road. And you wouldn't really be utilizing all of the strengths of unity since all of your logic would be need to be custom. It wouldn't make sense for each element to be a GameObject.

@@marf1610 yeah, gameobject is not a good way to have millions of objects on screen. I hope ECS be ready soon.

​@@TeppuTeppu I see your other replies in my notifications but they aren't appearing here. With Unity you would probably have one GameObject which has the 2D matrix and the element objects (which would not inherit from Monobehavior) and each frame you just update your one GameObject that handles updating all the elements in the matrix. At that point though you're not really using any of the benefits of Unity. And then you'll have to come up with some custom drawing logic, a way to generate a texture based on the matrix. Also, I don't think Tilemap would work well for this.

@@marf1610 I realize tilemap wouldn't work well so I deleted my comment. SetTile is not very good for performance.

I realized that I didn't know enough about c++ to really make it work. So I worked on some other easier projects in c++ and ended up creating the pixel sorting app I talk about in another video. I also realized that I do not like c++. So this is still on my mind but trying to find a good language + game engine/framework without having to completely build my own.