Edit: *Wall of Text Warning* - At 02:07, the size of the b32, gs_vec2, and color_t member variables should only be represented as "bits", not "bytes". Therefore the overall size is not the grossly exaggerated amount shown here, but 24 bytes. Thanks to @Nyzcere for pointing that out! There's always a mistake you miss! - I've gotten a concern about the memory storage for the particle data. Something else I'm regretting not going into more detail. To clarify, the texture size is not the screen's full resolution in this implementation. It's 629 x 424 for a total of ~266.7k particles. Total memory storage for this buffer is therefore ~6.4MB. I think that's acceptable for a small game world like this. The size of this particle data can definitely be lowered though! If you pack the life time and color information into 4 bytes (24 bits for the life and 8 bits for a color lookup index into a shared table), you could drastically reduce the size. However, the goal of the vid was to show off a concept and demonstrate an implementation - not to achieve extreme efficiency. - It's also been requested to explain a bit more about how the rendering occurs, since that seems to be a large concern for people who might attempt something like this. For the particles' updates, they really are that simple, naive and brute force. It seems odd, but the resolution of my world shown is roughly 260k particles, and it easily hits a 16ms frame time. However as you scale the world, this won't cut it. So you have some options. You could split it up into sizeable chunks, say 512x512 (like Noita does), and then partition those chunks into active/inactive buckets and only update the active particles. To further speed this up, you could multi-thread the simulation. Now, here's the catch: Noita and my simulations are both single-buffered and run on the CPU. So that means multi-threading is...challenging. You have to be careful at the boundaries of your chunks, since there's a large chance you'll have a lot of data-races at boundary walls. Noita handles this by splitting its update frame into 4 sections - it creates groups of chunks to update in a "checker like" pattern, so it maintains a large separation area between chunks. This works well enough in practice so that a particle has a large enough area it can travel in a single frame between neighboring chunks without having to worry about getting accessed twice in different threads. You could also move the entire sim to the GPU, but that's a different beast altogether. :) The rendering is done in a single draw call. I keep a 2d array of 32-bit rgba color data which maps directly to the pixel data. There is also a GPU texture that has the exact same dimensions as this CPU texture. As I update pixels, I change the color data as well. Then, when I'm done with the sim in the frame, I push the entire color buffer and copy its data into the GPU texture. Therefore rendering the scene is just a single draw call to present the buffer to screen. I also have 3 other calls for post processing. All in all, the entire scene is rendered in 5 calls: - one to render the simulation to an offscreen target - three for post processing (bright filter, bloom, and composite) - one for final presentation to back buffer - Salt isn't less dense than water, I misspoke. But, it looks cool. That's what matters, right? - @championchap brought up a point that I sneakily didn't address in the video (I'm starting to realize that I need to address everything much more fully than I did). The "simple" sand falling algorithm works great as a base, and adding forces, like gravity and velocity, do work to add some variation for a more "realistic" behavior set. However, if the velocity fails to move the particle in any way, the simulation falls back to this simple algorithm and it can look "out of place" with how uniformly it falls. Think about it - we specifically tell the sand to follow those rules in a fall through pattern - look down, then look down and left, then down and right. What you can do to force some variation is to alternate how to iterate through the columns of your data. Easiest way I've found is to add a frame counter and then on even frames, you iterate left-to-right. For odd frames, right-to-left. This adds enough variation to that falling pattern that it greatly helps out with this issue of unwanted uniformity. - Also, thanks for all the kind words and motivation, everyone. Subscribe and be on the lookout for the next one. I've already started working on it 😀
Keep it up! You're doing very well with your videos and they have pretty high educational value, considering how many videos are like these (not many at all). :)
This is great content! Very well thought out, in a language that doesn’t get nearly enough TH-cam love(C, that is), and is also entertaining in general. Keep up the great work
These types of sand games were how I entertained myself throughout junior high school. :D Loved these so much. It was really nice to see how they actually work!
On a loosely related note, it always amuses me when Game Of Life is said to have 4 rules. It's really just 2 rules: *1-* living cell dies if *not* next to 2 or 3 alive neighbors *2-* dead cell is revived if next to 3 alive neighbors
On a related note, since you seem to be interested, this directly feeds into most 'partisan' games, as Conway coined, and into surreal numbers in general. All choice, especially with regards to mathematics, can be thought of as moves in a game. These moves are typically bimodal that can be infinitely bisected to get beyond an infinite representation of possible states. I want to figure out more insightful and entertaining ways to introduce people who love video games to these topics - because they are immensely powerful and beautiful.
@@johnjackson9767 " All choice, especially with regards to mathematics, can be thought of as moves in a game. These moves are typically bimodal that can be infinitely bisected to get beyond an infinite representation of possible states." This intrigues me! Could you please explain more in depth what you mean by this (or maybe do a video)?
4:25 Some tips: If you notice, the ripples and interactions in the water are a bit similar so you can set the delay time for each particle and random time differently. And we have realistic water!
Really well explained, and a high production value. Hoping to see more :) P.s. at 2:07 you accidentally switched from counting in bytes to counting in bits, the total should be much smaller
Ahh, you're right! Haha, that b32 should only be 32 bits. I gotta figure out how to add some way to fix it on TH-cam. Thanks for pointing it out! What a silly mistake to make.
what happens when two particles want to move in the same place? this is something i've always had problems with when creating simulations like this, as top leftness always gets preference
@@GeneralPet Sure, you could use whatever rules you'd like. A lot of this is tweaking and adjusting parameters until you get something pleasant looking.
@@jamesmathai1138 In order to do this efficiently you would iterate in a shuffled version your array. This is something that can be used in particle or verlet physics in general
I attempted this a while back. I can't believe I didn't try to travel to each cell along a path to handle velocity. I guess I thought it would be too taxing on my computer to run smoothly but, looking at your results, it seems to work well enough. Great video, I really enjoyed it!
If you're not careful, it can certainly hurt performance, so your concerns are valid! But I keep my searches bounded to about 4 cells along the path, so it doesn't get too out of hand. Of course, that's also with no other optimizations, such as keeping track of active/inactive cells or chunks.
There is a ton of fantastic engineering as well as multiple other disciplines that goes into games, that I feel like it often gets overlooked. I want to help share some of that if I can. Already working on the next topic I'd like to discuss. Thank you for the kind words and watching.
This was phenomenal, man, thank you so much, I had a lot of fun watching. The "speed" stuff had gone totally over my head. Falling sand and simulating water was one of the first programs I ever made, it's mindblowing so many people had the same impulse to simulate something like that.
Thanks for watching! Hope I answered a few things for you and got you interested in some others as well, such as Cellular Automata, which is what all of this branches off from. I've put links in the description for more resources as well as a link "Powder Toy", which is one of the best "sand game"s I've ever messed around with.
@@johnjackson9767 It was a quite informatinve video. Now I have an idea how the different particles work. I think the only thing that remains is how to address performance. I've messed around with cellular automata a lot, and I realize the bigger the grid of cells and the more non-empty cells it contains, the more taxing it becomes. By the way, have you ever made any videos on Terraria/Starbound level of intricate water physics? I've messed around with this some time ago but had no success. They do a lot of things pretty well that I couldn't achieve, and I never found any resources about how to get there. Starbound especially, has quite more intricate water physics.
I have a rather long pinned comment up top which addresses some performance and memory concerns if you want to read through that. I haven't done videos on it, but my suspicion is that it uses some form of 'Smoothed Particle Hydrodynamics', SPH for short, or a combination of meta ball signed distance field rendering with a simple polygon mesh that moves its vertices with spring dampening and other ways to make the verts look 'wavy'. I'll add it to my list of possible topics, because the math is certainly interesting.
I actually wondered about the mechanics behind noita's particle simulation and how to produce the same effects in c++ OpenGL / Vulkan. This channel is perfect for me since I am planning to convert 3d rendered frames to video using ffmpeg and something like that. But I am really stupid around tinkering with graphics APIs. Anyway great work! you got yourself a new sub
Things like this are exactly why I wanted to get into game design in the first place. I am utterly fascinated by game physics, especially convincing fluid simulations.
This is the exact effect I have been searching for since the last four weeks. Would you consider making a C platformer tutorial that has platforms crumbling to dust upon jump, rope physics, water effects, etc. I am sure a lot of beginners would appreciate it.
I have been playing powder toy on and off for about 1 year just found this video, and was like wow this really looks similar to a mobile game I played. Loved the game and got the dlc.
Really good video! Totally underrated. I didnt even realize that those powder / pixel physics games worked like cellular automata, really inspired me to make my own! :D
Great video man. I found your channel from your Github. I have been looking at making a C game engine and this has provided plenty of inspiration to work from. Keep up with the videos, they are great!
This is a great video. Your writing is clear and practical, and your visuals assist your script well, particularly when you enter more technical descriptions. I would love to see you use this approach to explore other rogue-likes (e.g. recreating a procedural generator for levels, like in Rogue or The Binding of Isaac), or other simulations (e.g. recreating Dwarf Fortress' simulation of climates). Thanks, John.
Very well organized talk; In addition it need physical properties; statistical mechanics; and some static mechanics. I will work on when finishing i will put it in github.
Noita also have ridgid body physics, which is impressive. Even more impressive is the fact that early versions of Noita had surface tension for liquid, so, for example, water in icy biomes formed icicles. And on top of that, Noita uses multiple cores to calculate physics
Damn, just found this amazing video and subbed, i would love to see more of this stuff! From the thumbnail i thought we'd see some 3d noita like simulations, maybe that's an idea for a future video! Keep up the great work, the video was extremely enjoyable
Thanks for watching. I've played a bit with 3D sand simulations, but they have to be treated as voxel simulations which require some careful optimizations that I'm not doing here.
Add wind, rain, temperature, plants, few kinds of animals (some predatory and some herbivore) and their needs for food, thirst and warmth and let the player select any animal they want to play and see how long they've managed to survive. It's a game I'd play. At some point add human hunters with bows and some primitive tools that let them create e.g. friction fire and shelters - either as an enemy when playing an animal or as a player-selectable character. The number of scenarios one can get here is huge. Also, subscribed.
Could be an interesting building concept: sand castles that require different combinations of water and sand, different viscosities of mud. And can bake in the sun to grow rigid.
the browser and mobile game "Powder Game" by Dan Ball was my favourite example of a particle physics simulation before i played noita. to my knowledge its the originator of games like "the sandbox" on phone. the game itself has very cool interactions and particle simulation physics, relying very heavily on the showcase of wind and explosive force. its really facinating and i reccomend a mess around in it
@@geroge_i_mean_george I've thought about this before, but I don't know how you'd resolve neighbor pixel conflicts with a compute shader. The algorithm he described is very iterative.
@@odomobo that's a great point, I don't know either. You might be able to dynamically partition an affected area into blocks and assign a thread/group of threads to each block, but that would be a problem since the more areas are affected, the more threads would be required. I feel like assigning a thread to each pixel would be overkill
@John Jackson, Ugh... thank you so much for this video. I say 'ugh' because I thought I was done with OpenGL and could finally move on to Vulkan but NooOoO i gotta go back to OpenGL just for this and then move on. In a way I'm going to be stuck on this mini project just to understand how this works but you gave me more insight to add another tool under my belt so to speak. Cheers~ 👏👏👍👍
Great video! I would like you to also talk about the performance of this simulation. The rules for the elements are simple, but doing this for every single one just has to be a huge consideration.
Instead of applying special rules to each type of particle try giving them weight instead, the weight can determine which direction to look for obstacles while it's at it, so for instance water could have a weight of 1, sand/salt a weight of 2, smoke a weight of -1 etc
I remember making demos like this back in the Mode 13H days. Some effects, like blur, are done somewhat opposite from what's explained in this video. For every pixel, you set the color to the average of the eight neighbors. Fire can be implemented by setting every pixel to the average of the three lower neighbors, giving the effect of color moving up the screen. Averages tended toward the dominant color (usually black). This was done with a pre-set color palette, though. The rules were simple enough to implement with some inline asm, and very fast.
Edit:
*Wall of Text Warning*
- At 02:07, the size of the b32, gs_vec2, and color_t member variables should only be represented as "bits", not "bytes". Therefore the overall size is not the grossly exaggerated amount shown here, but 24 bytes. Thanks to @Nyzcere for pointing that out! There's always a mistake you miss!
- I've gotten a concern about the memory storage for the particle data. Something else I'm regretting not going into more detail. To clarify, the texture size is not the screen's full resolution in this implementation. It's 629 x 424 for a total of ~266.7k particles. Total memory storage for this buffer is therefore ~6.4MB. I think that's acceptable for a small game world like this. The size of this particle data can definitely be lowered though! If you pack the life time and color information into 4 bytes (24 bits for the life and 8 bits for a color lookup index into a shared table), you could drastically reduce the size. However, the goal of the vid was to show off a concept and demonstrate an implementation - not to achieve extreme efficiency.
- It's also been requested to explain a bit more about how the rendering occurs, since that seems to be a large concern for people who might attempt something like this.
For the particles' updates, they really are that simple, naive and brute force. It seems odd, but the resolution of my world shown is roughly 260k particles, and it easily hits a 16ms frame time. However as you scale the world, this won't cut it. So you have some options. You could split it up into sizeable chunks, say 512x512 (like Noita does), and then partition those chunks into active/inactive buckets and only update the active particles. To further speed this up, you could multi-thread the simulation.
Now, here's the catch: Noita and my simulations are both single-buffered and run on the CPU. So that means multi-threading is...challenging. You have to be careful at the boundaries of your chunks, since there's a large chance you'll have a lot of data-races at boundary walls.
Noita handles this by splitting its update frame into 4 sections - it creates groups of chunks to update in a "checker like" pattern, so it maintains a large separation area between chunks. This works well enough in practice so that a particle has a large enough area it can travel in a single frame between neighboring chunks without having to worry about getting accessed twice in different threads.
You could also move the entire sim to the GPU, but that's a different beast altogether. :)
The rendering is done in a single draw call. I keep a 2d array of 32-bit rgba color data which maps directly to the pixel data. There is also a GPU texture that has the exact same dimensions as this CPU texture. As I update pixels, I change the color data as well.
Then, when I'm done with the sim in the frame, I push the entire color buffer and copy its data into the GPU texture. Therefore rendering the scene is just a single draw call to present the buffer to screen. I also have 3 other calls for post processing.
All in all, the entire scene is rendered in 5 calls:
- one to render the simulation to an offscreen target
- three for post processing (bright filter, bloom, and composite)
- one for final presentation to back buffer
- Salt isn't less dense than water, I misspoke. But, it looks cool. That's what matters, right?
- @championchap brought up a point that I sneakily didn't address in the video (I'm starting to realize that I need to address everything much more fully than I did). The "simple" sand falling algorithm works great as a base, and adding forces, like gravity and velocity, do work to add some variation for a more "realistic" behavior set. However, if the velocity fails to move the particle in any way, the simulation falls back to this simple algorithm and it can look "out of place" with how uniformly it falls. Think about it - we specifically tell the sand to follow those rules in a fall through pattern - look down, then look down and left, then down and right. What you can do to force some variation is to alternate how to iterate through the columns of your data. Easiest way I've found is to add a frame counter and then on even frames, you iterate left-to-right. For odd frames, right-to-left. This adds enough variation to that falling pattern that it greatly helps out with this issue of unwanted uniformity.
- Also, thanks for all the kind words and motivation, everyone. Subscribe and be on the lookout for the next one. I've already started working on it 😀
Keep it up! You're doing very well with your videos and they have pretty high educational value, considering how many videos are like these (not many at all). :)
unity game "creator" sweaty
This is great content! Very well thought out, in a language that doesn’t get nearly enough TH-cam love(C, that is), and is also entertaining in general. Keep up the great work
You warned me, but boy, it was a big wall
These types of sand games were how I entertained myself throughout junior high school. :D Loved these so much. It was really nice to see how they actually work!
People LOVE particle physics.
I'm VERY particular about it
I see what you did there.
Bruh
Especially 2d?
@@Beunibster i see what you did there
I just found the 3blue1brown of computer graphics, and I love it.
Haha, that's probably the best compliment I've ever gotten.
I was looking for this comment. Felt heavy 3b1b vibes. This is great!
@@SLB_Labs ikkrrr me tooo
You'd love Sebastian Lague then!
@@mv2e19 already a fan
"Noita"
**POLYMORPHINE TRAUMATIC STRESS DISORDER FLASHBACKS**
Wow really high quality vid, please make more like this, subbed
Hey, man, love your vids! Thanks for the compliment and sub. I'm already working on the next one. :)
YOU?!?!?!
This is one of those videos that could last days and I would still be sad when it ended
Very kind words, glad you enjoyed it. I'll have another one up in the next few days.
On a loosely related note, it always amuses me when Game Of Life is said to have 4 rules. It's really just 2 rules:
*1-* living cell dies if *not* next to 2 or 3 alive neighbors
*2-* dead cell is revived if next to 3 alive neighbors
Absolutely good point. And the fact that it's even simpler than typically reported to be just adds more weight to Conway's genuis.
On a related note, since you seem to be interested, this directly feeds into most 'partisan' games, as Conway coined, and into surreal numbers in general. All choice, especially with regards to mathematics, can be thought of as moves in a game. These moves are typically bimodal that can be infinitely bisected to get beyond an infinite representation of possible states.
I want to figure out more insightful and entertaining ways to introduce people who love video games to these topics - because they are immensely powerful and beautiful.
@@johnjackson9767 " All choice, especially with regards to mathematics, can be thought of as moves in a game. These moves are typically bimodal that can be infinitely bisected to get beyond an infinite representation of possible states."
This intrigues me! Could you please explain more in depth what you mean by this (or maybe do a video)?
What an amazing video! I learned a lot here, thank you! I can't wait for the next one!
Thanks, man! Love your vids too 😀
I think I found my next little programming challenge for myself.
4:25 Some tips: If you notice, the ripples and interactions in the water are a bit similar so you can set the delay time for each particle and random time differently. And we have realistic water!
Okay YOU REALLY deserve more views. This is high quality content, right there
Really well explained, and a high production value. Hoping to see more :)
P.s. at 2:07 you accidentally switched from counting in bytes to counting in bits, the total should be much smaller
Ahh, you're right! Haha, that b32 should only be 32 bits. I gotta figure out how to add some way to fix it on TH-cam. Thanks for pointing it out! What a silly mistake to make.
@@johnjackson9767 also "has_been_updated" should be a boolean (according to it's name) so it's 1 byte and 8 bits
@@adsick_ua He's using 32-bit bool. Like the Casey Muratori style from Handmade Hero by the looks of the code....
@@johnjackson9767 Those are the best kinds of mistakes!
@@totheknee Yep, 32-bits for a bool so the structures are padded correctly.
This maybe one of my favorite coding videos of all time. Very precise and very informative. Good job dude
Very kind of you! I'm glad you got something out if it.
Awesome video. You’re like the Bob Ross of sand simulators. Keep it coming!
"Just paint a happy lil' acid pool here..."
Thanks for watching and the kind words! I'm starting to work on an idea for the next one now. Stay tuned.
@@johnjackson9767 here is some limestone
I really love modular systems. Being able to set up a system, iterate on it all you want, and add new things based on that system is cool.
what happens when two particles want to move in the same place? this is something i've always had problems with when creating simulations like this, as top leftness always gets preference
The first will get preference. I alternate updating left or right sides first each frame to keep this from being too noticable.
@@johnjackson9767 Can you just randomise where the particle will go? Generate some integer to represent where the particle moves to
@@GeneralPet Sure, you could use whatever rules you'd like. A lot of this is tweaking and adjusting parameters until you get something pleasant looking.
What I do (if I can afford the performance drop), is pick a random site to update. Repeat it several times and you get something that feels “fairer.”
@@jamesmathai1138 In order to do this efficiently you would iterate in a shuffled version your array. This is something that can be used in particle or verlet physics in general
I attempted this a while back. I can't believe I didn't try to travel to each cell along a path to handle velocity. I guess I thought it would be too taxing on my computer to run smoothly but, looking at your results, it seems to work well enough. Great video, I really enjoyed it!
If you're not careful, it can certainly hurt performance, so your concerns are valid! But I keep my searches bounded to about 4 cells along the path, so it doesn't get too out of hand. Of course, that's also with no other optimizations, such as keeping track of active/inactive cells or chunks.
John Jackson Cool, next time I try I will definitely keep that in mind!
Insanely informative and visually stunning. Thanks a lot for sharing!
Glad you enjoyed it!
I didn't even mean to watch a video
this video was so good it just had me glued to the screen waiting for the next piece of information
subbed!
Dude you are like the first one to call this game engineering (base on : searching in youtube) love your vid , such high quality, please make more !!!
There is a ton of fantastic engineering as well as multiple other disciplines that goes into games, that I feel like it often gets overlooked. I want to help share some of that if I can.
Already working on the next topic I'd like to discuss. Thank you for the kind words and watching.
This was phenomenal, man, thank you so much, I had a lot of fun watching. The "speed" stuff had gone totally over my head. Falling sand and simulating water was one of the first programs I ever made, it's mindblowing so many people had the same impulse to simulate something like that.
I appreciate it. Glad you enjoyed the video.
This really reminds me of Sebastian Lague's coding adventure videos, great production quality! Well done.
A _"Sand Game"_ is a really nice way to put it. :)
Thanks a lot for doing this. I've been really curious about Noita since I first heard about it.
Thanks for watching! Hope I answered a few things for you and got you interested in some others as well, such as Cellular Automata, which is what all of this branches off from.
I've put links in the description for more resources as well as a link "Powder Toy", which is one of the best "sand game"s I've ever messed around with.
@@johnjackson9767 It was a quite informatinve video. Now I have an idea how the different particles work. I think the only thing that remains is how to address performance. I've messed around with cellular automata a lot, and I realize the bigger the grid of cells and the more non-empty cells it contains, the more taxing it becomes.
By the way, have you ever made any videos on Terraria/Starbound level of intricate water physics? I've messed around with this some time ago but had no success. They do a lot of things pretty well that I couldn't achieve, and I never found any resources about how to get there. Starbound especially, has quite more intricate water physics.
I have a rather long pinned comment up top which addresses some performance and memory concerns if you want to read through that.
I haven't done videos on it, but my suspicion is that it uses some form of 'Smoothed Particle Hydrodynamics', SPH for short, or a combination of meta ball signed distance field rendering with a simple polygon mesh that moves its vertices with spring dampening and other ways to make the verts look 'wavy'. I'll add it to my list of possible topics, because the math is certainly interesting.
@@johnjackson9767 Oh, I totally overlooked the pinned comment! Thanks.
This is going to be a great series.
Here's hoping! 😀
I actually wondered about the mechanics behind noita's particle simulation and how to produce the same effects in c++ OpenGL / Vulkan. This channel is perfect for me since I am planning to convert 3d rendered frames to video using ffmpeg and something like that. But I am really stupid around tinkering with graphics APIs. Anyway great work! you got yourself a new sub
This thing accurately simulated the launch and death of Borderlands 3.
Haha
Things like this are exactly why I wanted to get into game design in the first place. I am utterly fascinated by game physics, especially convincing fluid simulations.
Wow, this is so cool man! Love it!
wow this is a super insightful video, if only youtube's bitrate wasn't crap
rad video! will be rewatching and checking out the code when i have some more time. thanks for sharing!
This is the exact effect I have been searching for since the last four weeks. Would you consider making a C platformer tutorial that has platforms crumbling to dust upon jump, rope physics, water effects, etc. I am sure a lot of beginners would appreciate it.
Amazing video! I loved it! Learnt a lot!
Appreciate it! Glad you got something out of it!
I have been playing powder toy on and off for about 1 year just found this video, and was like wow this really looks similar to a mobile game I played. Loved the game and got the dlc.
Both these forms of media are so rare and I love that you brought them together. I love Noita, and the Powder Toy I've been playing since I was a kid.
Wtf this was the best video on particles i've ever seen. Amazing job
Really good video! Totally underrated. I didnt even realize that those powder / pixel physics games worked like cellular automata, really inspired me to make my own! :D
This was so amazing and inspiring at the same time. Immediate sub.
Great video man. I found your channel from your Github. I have been looking at making a C game engine and this has provided plenty of inspiration to work from. Keep up with the videos, they are great!
after watching the devs video, it seems like you made liquids much more complicated. Still a great video!
More complicated than they need to be? Probably. Lol.
really interesting stuff, idk how I even got here but glad I did
WOW the quality is incredible. You're going to blow up with the next few vids I guarantee it
I purposefully put off watching this until completing my first computer graphics class- and boy was this worth the wait!
Your best video by far. Keep doing videos like this.
Now to go and find powder toy again.
Fantastic video, very satisfying to watch. Please make more haha. Subscribed!
Amazing stuff! Your voice very soothing as well! Really enjoyed your earlier devlogs too.
This is a great video. Your writing is clear and practical, and your visuals assist your script well, particularly when you enter more technical descriptions. I would love to see you use this approach to explore other rogue-likes (e.g. recreating a procedural generator for levels, like in Rogue or The Binding of Isaac), or other simulations (e.g. recreating Dwarf Fortress' simulation of climates). Thanks, John.
Great suggestions, Charles. Thanks for the kind words and watching. Glad you got something out of it!
Great explanation! Never heard of Elementary Cellular Automation, will look into it.
Research John Conway and Stephen Wolfram and Recreational Mathematics. You won't be disappointed.
I like how you took something completely incomprehensible and made it easy enough for me to understand.
Great video, really amazed with the quality of it and what you created.
Very well organized talk;
In addition it need physical properties; statistical mechanics; and some static mechanics. I will work on when finishing i will put it in github.
Beautiful video!
What a great video. Brilliant for people (like me) looking to get into this area of graphics programming. Great job!
Man that's absolutely stunning! Inspired me to give my first try for Cellular Automata
Great stuff! Looking forward to your next projects
Noita also have ridgid body physics, which is impressive.
Even more impressive is the fact that early versions of Noita had surface tension for liquid, so, for example, water in icy biomes formed icicles.
And on top of that, Noita uses multiple cores to calculate physics
Absolutely, it's a fantastic showcase of novel solutions to complex problems.
That's super interesting! I always wanted to do something with cellular automata, I think I gonna try what you gonna try.
Give it a shot! It's a lot easier than you'd think.
Damn, just found this amazing video and subbed, i would love to see more of this stuff!
From the thumbnail i thought we'd see some 3d noita like simulations, maybe that's an idea for a future video!
Keep up the great work, the video was extremely enjoyable
Thanks for watching. I've played a bit with 3D sand simulations, but they have to be treated as voxel simulations which require some careful optimizations that I'm not doing here.
Add wind, rain, temperature, plants, few kinds of animals (some predatory and some herbivore) and their needs for food, thirst and warmth and let the player select any animal they want to play and see how long they've managed to survive. It's a game I'd play. At some point add human hunters with bows and some primitive tools that let them create e.g. friction fire and shelters - either as an enemy when playing an animal or as a player-selectable character. The number of scenarios one can get here is huge. Also, subscribed.
Now add poison, ooze, mud, plants, balloons, pipes, converters, bombs, switches, and sliders.
Really love it. Great youtube algorithm suggestion. Now I wanna try and see if I can learn myself.
Best 10 minutes spent on youtube ever. I would love for you to do a step by step tutorial of this in c++ or something !
Could be an interesting building concept: sand castles that require different combinations of water and sand, different viscosities of mud. And can bake in the sun to grow rigid.
nice, good job on this
Very interresting experiment Mr. Jackson, thank you for the share!
The editing, pacing, and illustrations in this video are absolutely top notch.
the browser and mobile game "Powder Game" by Dan Ball was my favourite example of a particle physics simulation before i played noita. to my knowledge its the originator of games like "the sandbox" on phone. the game itself has very cool interactions and particle simulation physics, relying very heavily on the showcase of wind and explosive force. its really facinating and i reccomend a mess around in it
This is sooo cool. I made it with python and Pygame, and it works perfectly. It game me so many ideas for games.
You just earned a sub.
this was awesome dude!
Dude. Incredible. Freakin the best thing on game dev I've seen in a long time.
Wow, man, I appreciate the kind words. Working on another one now.
Pretty amazing video
Thank you! I plan on making this a series, so be sure to like and sub!
Wow ! Cool technique, discovered your channel randomly !!
I love this series, thank you for making videos.
Christ, I can feel my CPU burning up just thinking about this simulation.
great use case for a compute shader
@@geroge_i_mean_george I've thought about this before, but I don't know how you'd resolve neighbor pixel conflicts with a compute shader. The algorithm he described is very iterative.
@@odomobo that's a great point, I don't know either. You might be able to dynamically partition an affected area into blocks and assign a thread/group of threads to each block, but that would be a problem since the more areas are affected, the more threads would be required. I feel like assigning a thread to each pixel would be overkill
@@odomobo Yeah Noita is computed on the CPU with a lot of chunking optimizations
I love that you mentioned The Powder Toy
That game is my childhood
@@DLDrillNB I'm still on it. I make electronic stuff with FILT, and sometimes art on it
It's a fantastic sim.
@@johnjackson9767 How often do you check it out, still? My hope is to one day see it gain a lot of recognition, which is why I asked.
Bruuuuuh... :O
Particles are indeed the most important part of a good game
@John Jackson, Ugh... thank you so much for this video. I say 'ugh' because I thought I was done with OpenGL and could finally move on to Vulkan but NooOoO i gotta go back to OpenGL just for this and then move on. In a way I'm going to be stuck on this mini project just to understand how this works but you gave me more insight to add another tool under my belt so to speak. Cheers~ 👏👏👍👍
this is just amazing, loved it!
Great video! I would like you to also talk about the performance of this simulation. The rules for the elements are simple, but doing this for every single one just has to be a huge consideration.
for noita the game world that's actually simulated isn't really that huge, so you can run it even on fairly weak processors.
I just want to go and try coding this right now!! Got such a rush of inspiration from this! :D
You made me remember powder, which was my childhood. Ive spent the whole today playing with it. Amazing little game.
3:00 I found this algo in a science magazine maybe 25 years ago and I've enjoyed playing with them a lot since then :-)
I just want to say that as a Finn I appreciate you good pronunciation of the word noita
Haha, I'm glad I passed the test! I actually went back and scrapped a lot of takes because I wasn't happy with my Texan way of pronouncing it.
Awesome! Looks fantastic.
I’m new here, but I’m here to stay. Great vid!
Awesome stuff!
Appreciate it! Thanks for watching.
That's really cool, thanks, you got a new sub!
Instead of applying special rules to each type of particle try giving them weight instead, the weight can determine which direction to look for obstacles while it's at it, so for instance water could have a weight of 1, sand/salt a weight of 2, smoke a weight of -1 etc
I remember making demos like this back in the Mode 13H days. Some effects, like blur, are done somewhat opposite from what's explained in this video. For every pixel, you set the color to the average of the eight neighbors. Fire can be implemented by setting every pixel to the average of the three lower neighbors, giving the effect of color moving up the screen. Averages tended toward the dominant color (usually black). This was done with a pre-set color palette, though. The rules were simple enough to implement with some inline asm, and very fast.
Impressive video!
Thanks for the video. Very interesting.
Thanks for watching!
Awesome video, loved the production value and the content. Interesting!
Was very interesting,even though I'm not a programmer i understood because you explained it so well
That's my hope with these, and maybe I got you interested in it now. Thanks for watching!
wowza thank you for making something i could be this intersted in
This is really awesome 👍 makes me want to try make my own! Great vid
Good job. Well done
This is so cool. I think I want to make something similar now but in Processing
Found you through a recent game jam instant sub.
Wow.... This is just What I was looking for!!!!! Thank u sir!
Great stuff and instant sub from me. I shared your post with Reddit. You deserve more subscribers man!