2d fluid simulation engine? - Developers

Does anyone have a decent tutorial/essay/book/whatever on 2d fluid simulation, like the one OE-Cake uses, if you ever played that? I've tried to make a few demos on my own, needless to say I failed, it looked nothing like fluid.

OE cake uses particles for physics as far as I remember. The water is just a blurry thing drawn around them.

-snip- I didn't say anything

[QUOTE=Shammah;16690504]Wait, 2D water simulation, what the shit? You either just use animated sprites, or am I being completely dumb?[/QUOTE] completely dumb lol He means a fluid simulation that interacts with objects etc, using particles and lots of them :D OE-Cake is really good [img]http://www.nordinho.net/vbull/attachments/other-cool-games/34044d1208231600-oe-cake-fluid-simulator-physics-game-cake.jpg[/img] Phun is also a really good water simulation [img]http://www.screenshots-archive.com/files/images/Phun_beta_3.12_by_Emil_Ernerfeldt_4.preview.png[/img]

The cat's out of the bag now.

[QUOTE=Nikita;16690502]OE cake uses particles for physics as far as I remember. The water is just a blurry thing drawn around them.[/QUOTE] Well no shit, but how do I do the particles?

[QUOTE=Sporbie;16691705]Well no shit, but how do I do the particles?[/QUOTE] A simple way is to use a 'pixel' system. Although this is a grid system, it appears like particles. You just iterate through each pixel, applying rules to each one. For example, if there is open space below a water pixel, swap them. If there is a heavy piece of stone above a water pixel, swap them. It's a good idea to make it so pixels are affected only once, or that pixels only affect pixels that have being updated in the current frame, otherwise you may get inconsistencies. A good idea is to use 'update queues'. Where, if a water particle is simulated, and it lands on a dust particle, the dust particle is added to the end of a 'queue'. The queue is iterated gradually, moving each particle to the bottom of the queue as it is processed. A particle should not be removed entirely from the queue unless it is an absolute wakeless state. A water pixel that is moved downwards, due to gravity, should be moved to the bottom of the list. It should only be removed once it has settled on a surface. Hell, you can even use threads the queue system. Each worker thread is assigned a pixel of the queue to update. The other system is physical bodies, or: actual particles. This is how the real world works (with atoms, made of subatomic particles (which may be made of smaller particles)). This system is like going into GMod and filling a room with bouncy balls. The balls aren't aligned to a grid, and can float freely within the space, colliding with each other. Sphere-to-sphere accurate collision detection is not recommended in this system, due to the massive calculations. A good system is the distance one, where atoms push each other away as they get close. Although, you can use sphere-to-face collision with the 'walls' that particle editors like to have. With both of these, you can make any type of element. I wanted to make a (physical body) particle engine thing that simulated actual chemical atoms, with things such as atomic bonding. This would open up a whole world of reactions. Also, update queues can be used with both systems. I recommend the queue system. I challenge you to make the first particle engine (physical body based or pixel based) that allows for scripting of reactions and substance behaviour using a scripting language (such as Lua) ! Anyway, good luck!

[QUOTE=Deco Da Man;16692202] The other system is physical bodies, or: actual particles. This is how the real world works (with atoms, made of subatomic particles (which may be made of smaller particles)). This system is like going into GMod and filling a room with bouncy balls. The balls aren't aligned to a grid, and can float freely within the space, colliding with each other. Sphere-to-sphere accurate collision detection is not recommended in this system, due to the massive calculations. A good system is the distance one, where atoms push each other away as they get close. Although, you can use sphere-to-face collision with the 'walls' that particle editors like to have. With both of these, you can make any type of element. I wanted to make a (physical body) particle engine thing that simulated actual chemical atoms, with things such as atomic bonding. This would open up a whole world of reactions. Also, update queues can be used with both systems. I recommend the queue system. I challenge you to make the first particle engine (physical body based or pixel based) that allows for scripting of reactions and substance behaviour using a scripting language (such as Lua) ! Anyway, good luck![/QUOTE] I tried the system where particles push each other from each other, it didn't really feel like a fluid, I'm missing something probably, I really want it to feel like OE Cake. Also a falling sand game + a scripting engine sounds like fun, thanks for the idea.

[QUOTE=Sporbie;16692327]I tried the system where particles push each other from each other, it didn't really feel like a fluid, I'm missing something probably, I really want it to feel like OE Cake. Also a falling sand game + a scripting engine sounds like fun, thanks for the idea.[/QUOTE] I'm pretty sure OE Cake uses the pixel method. And I swear someone is rating me dumb just because they have something against me. If that's not the case, mind telling me why you think my post was dumb?

I love teh OEcaek :buddy:

[QUOTE=Deco Da Man;16692356]I'm pretty sure OE Cake uses the pixel method. And I swear someone is rating me dumb just because they have something against me. If that's not the case, mind telling me why you think my post was dumb?[/QUOTE] I don't think so, the simulation feels way too realistic to be a sand game.

[QUOTE=Deco Da Man;16692356]I'm pretty sure OE Cake uses the pixel method. And I swear someone is rating me dumb just because they have something against me. If that's not the case, mind telling me why you think my post was dumb?[/QUOTE] The "pixel method" is a crock of shit, which is probably why. OE cake uses full physical simulation, there is no grid.

you could try the powder toy

There's a fluid dynamics sample written in XNA here: [url]http://www.codeplex.com/XNACommunity/Wiki/View.aspx?title=Fluids&referringTitle=Home[/url]

[QUOTE=Catdaemon;16692750]The "pixel method" is a crock of shit, which is probably why. OE cake uses full physical simulation, there is no grid.[/QUOTE] Not to mention the other problems like, "Sphere-to-sphere accurate collision detection is not recommended in this system, due to the massive calculations." This is absolutely retarded, and clearly demonstrates the authors complete lack of knowledge. Accurate "Sphere-to-sphere" collision [B]IS[/B] a distance check. Not to mention it would be circle-circle collision, since we're talking about 2D. Threading a particle engine is hardly as simple as the author makes out, and he also completely ignores what I believe would be an integral part of a decent particle simulator, the broad phase collider.

[QUOTE=blankthemuffin;16703323]Threading a particle engine is hardly as simple as the author makes out[/QUOTE] What do you mean, you make one thread per pixel per frame to do the work, it'll all be calculated in an instant or even less if you have like 4 cores

[QUOTE=jA_cOp;16703832]What do you mean, you make one thread per pixel per frame to do the work, it'll all be calculated in an instant or even less if you have like 4 cores[/QUOTE] Won't work, moving one pixel can affect how other pixels behave. A synchronization nightmare.

[QUOTE=blankthemuffin;16704068]Won't work, moving one pixel can affect how other pixels behave. A synchronization nightmare.[/QUOTE] You're not creating enough threads, then

[QUOTE=jA_cOp;16704149]You're not creating enough threads, then[/QUOTE] I'm sorry not everyone here lives up to your godly programming standards.

[QUOTE=blankthemuffin;16706140]I'm sorry not everyone here lives up to your godly programming standards.[/QUOTE] It's ok, just don't come post when you obviously don't know what you're talking about, you're not helping edit: Don't get offended, I told you already, it's OK to be a noob

Wow fuck, who's offended here? It's late and i thought i might be able to help.

I hate it when people use the lateness as an excuse. You aren't suddenly dumb when you get tired. You don't suddenly think the sky is green and 2+2=potato. You know what you are saying, and you actually believe it. So just buck up and admit it when you're wrong. As for threads, it seems like an awful lot of extra work for something that seems to work pretty well as is. That is if it would even work. that would mean you'd have over 50,000 threads running at once. How do you handle all the race conditions that are going to pop up when you have that many threads all fighting for cpu time? Like what happens if a bunch of particles are all on seperate cores and decide they need to go to the same point all at once? The queue idea is probably the best way to go since you pick what particle gets the cpu's time and when. That way if a couple particles would be in the same spot, they'll just resolve it normally because they can't run at the same time.

[QUOTE=jivemasta;16707071]So just buck up and admit it when you're wrong.[/QUOTE] *Saves for future use*

[QUOTE=blankthemuffin;16703323]Not to mention the other problems like, "Sphere-to-sphere accurate collision detection is not recommended in this system, due to the massive calculations." This is absolutely retarded, and clearly demonstrates the authors complete lack of knowledge. Accurate "Sphere-to-sphere" collision [B]IS[/B] a distance check. Not to mention it would be circle-circle collision, since we're talking about 2D. Threading a particle engine is hardly as simple as the author makes out, and he also completely ignores what I believe would be an integral part of a decent particle simulator, the broad phase collider.[/QUOTE] By the sentence "Sphere-to-sphere accurate collision detection is not recommended in this system, due to the massive calculations.", I meant that calculating the actual realistic collisions between so many objects is absurd. You'd need to consider the different properties of actual collision. I don't what these actually are and what they are called, but I know they are quite complex and CPU intense. The 'distance system' I speak of is more like magnets. I don't know what this is actually called, but I do know what it does. I may not know the names of the concepts I described, but at least I described them well enough. If I were to have a 'complete lack of knowledge', I would not know anything of the subject. I do. Please disprove everything that I said before you make this claim. And yes, it would be circle-to-circle, thank you. I've never done anything with a broad phase collider system, so I am unable to make a statement regarding the idea. The threading isn't as hard as you make it out to be, either. Simply have a simple synchronisation object (i.e: mutex) on each particle. And I never said anything about a thread per pixel. I said several work threads that pick the highest entry in the queue and update it accordingly. Say 10 worker threads. Each one is assigned a particle, and as they update that particle, they push other particles to the base of the queue.

[QUOTE=jA_cOp;16706186]It's ok, just don't come post when you obviously don't know what you're talking about, you're not helping edit: Don't get offended, I told you already, it's OK to be a noob[/QUOTE] sup null # 2

Theres a bot going around and rating everyones post Dumb.

[QUOTE=Biotoxsin;16710429]Theres a bot going around and rating everyones post Dumb.[/QUOTE] Yeah, we all figured that out when no rebuttal was forthcoming in response to dumb-rated posts.

Yay, I'm an avid collector of dumb ratings. Hit me please!!!!!!111one

This thread: [QUOTE=blankthemuffin;16706140]I'm sorry not everyone here lives up to your godly programming standards.[/QUOTE] [QUOTE=jA_cOp;16706186]It's ok, just don't come post when you obviously don't know what you're talking about, you're not helping edit: Don't get offended, I told you already, it's OK to be a noob[/QUOTE] [QUOTE=blankthemuffin;16706295]Wow fuck, who's offended here? It's late and i thought i might be able to help.[/QUOTE] "Linking error with class pointer" thread: [QUOTE=Siduron;16705321]Wow fuck, who's offended here? It's late and i just thought of stuff that caused linker errors for me in the past.[/QUOTE] [QUOTE=blankthemuffin;16705350]You obviously don't understand what a linker error is, neither of the possible solutions you posted could cause linker errors. Compiler errors yes, linker errors no.[/QUOTE] [QUOTE=Siduron;16705398]I'm sorry not everyone here lives up to your godly programming standards.[/QUOTE] [QUOTE=jA_cOp;16705471]Don't worry about it, blankthemuffin is a horrible programmer and he knows it ^^v[/QUOTE] :sigh:

ITT computer programming mixes with enough teenage angst to pilot a mecha.