[QUOTE=Deco Da Man;16692202]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.
[/QUOTE]
Yeah now you can create falling pixels, what about horizontal movement? How does that work with your queue system?
Also creating a thread per pixel is a horribly inefficient idea. And wait, how do multiple pixels update at the same time anyway when only one thread can modify the pixel data at a time? How would that be any faster than processing all of them in one thread?
[QUOTE=Spoco;16722459]Yeah now you can create falling pixels, what about horizontal movement? How does that work with your queue system?
Also creating a thread per pixel is a horribly inefficient idea. And wait, how do multiple pixels update at the same time anyway when only one thread can modify the pixel data at a time? How would that be any faster than processing all of them in one thread?[/QUOTE]
You could put a cond var to make sure that each iteration only ever executes each thead's loop once, but yeah. That's going to make anyone's system cry.
[QUOTE=Spoco;16722459]Yeah now you can create falling pixels, what about horizontal movement? How does that work with your queue system?
Also creating a thread per pixel is a horribly inefficient idea. And wait, how do multiple pixels update at the same time anyway when only one thread can modify the pixel data at a time? How would that be any faster than processing all of them in one thread?[/QUOTE]
Horizontal movement can be created by just adjusting the update function. Make it so that if one side consists of nothing, or something lighter than the current particle, maybe randomly swap with it. It's up to the create on how he does his update function.
The queue system has nothing to do with the behaviour of the particles.
I never said anything about creating a thread per pixel. That [b][i]is[/i][/b] a horrible bad idea.
And only threads that are affecting pixels close to each other at the same time will cause one to wait for the other. You could have one thread doing pixels in the top left corner, while another thread does one in the bottom right corner. It's only when they both affect the same pixel, either directly on that pixel or as one of it's neighbours, does it become inefficient.
"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."
That's just as fucking retarded. The locking overhead alone will destroy any hopes of a speed up.
Nice idea with the random function, that's a great way to make a particle engine. Actually, why not just make all the particles move based on a random function, gets rid of those complex collision response formulas.
Really, all your ideas are bad, badly researched and stupid.
[QUOTE=blankthemuffin;16732365]"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."
That's just as fucking retarded. The locking overhead alone will destroy any hopes of a speed up.
Nice idea with the random function, that's a great way to make a particle engine. Actually, why not just make all the particles move based on a random function, gets rid of those complex collision response formulas.
Really, all your ideas are bad, badly researched and stupid.[/QUOTE]
I'm pretty sure you misunderstood what he meant about the random thing.
Imagine this: We have a layer of light particles. Now we put a layer of heavy particles on top.
If they just switch places immediately, the heavy particles would fall just as fast through the light particles as they would have done through air. This is obviously unrealistic.
Now, if we instead have a certain chance, let's say 1/10, of the heavy particle switching places with the light particle beneath it, the heavy particles would fall slower towards the bottom.
Reading your replies I figured real fluid simulation is way over my head, so I decided to go with making a sand game, sort of like the the powder game from Dan-Ball, but with the modding capabilities of wxSand or Burning Sand.
I would very much like to implement lua as a language for defining elements and how they interact with each other.
Now I need help actually implementing the lua part in the application. I would like the lua file defining a "world" like this:
[lua]Fire = Element(/*stuff like color, density, and type go here*/)
Water = Element(/*same*/)
Steam = Element(/*durf*/)
function Water::Move()
//if you want to code custom movement instead of using the default one
end
//ReactingPixel is of type Water currently
function Water::OnTouch(Fire)
ReactingPixel = Steam
end
[/lua]
I know this seems pretty vague, I haven't actually designed the system myself, but yeah that's how I would like scripting to look.
Now I have no idea how I would achieve this since it would be the first time using lua for me. How should I structure my program? I'm guessing I should be using luabind. Can anyone direct me to a good book or tutorial?
Maybe off topic: What the fuck does the "extern" keyword do?
[QUOTE=blankthemuffin;16732365]"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."
That's just as fucking retarded. The locking overhead alone will destroy any hopes of a speed up.
Nice idea with the random function, that's a great way to make a particle engine. Actually, why not just make all the particles move based on a random function, gets rid of those complex collision response formulas.
Really, all your ideas are bad, badly researched and stupid.[/QUOTE]
If you have ten threads working a 1000 by 1000 simulation area, they are rarely going to collide.
I hear most operating systems have very fast locking functionality. I'd like evidence to disprove this please.
If you have a look a [url=http://dan-ball.jp/en/javagame/dust/]Powder Game[/url], you'll see that when you place a single water particle on a flat surface with nothing around it, the particle will move randomly side to side.
That is what I meant.
Although, what noctune9 said is also a good idea.
And why the hell would you have 'complex collision response formulas' for a pixel-based system?
The 'ideas' that you call mine, aren't mine. I've seen them on many different coding forums. I'm simply relaying the information. [url=www.google.com]Go find[/url] the source of my information and have fun ranting at them.
In falling sand, when particle wants to move vertically but is blocked by another particle, it will use rand() to choose if it should go right or left.
[QUOTE=Sporbie;16692504]I don't think so, the simulation feels way too realistic to be a sand game.[/QUOTE]
It is still technically a sand game.
Someone from FP needs to make a really fricking awesome fluids/sand game with input from Facepunch.
Personally I always wanted fixed joints like in phun combined with the physics and electricity of powder toy and heat creation and absorbtion by metal caused by things like fire, cooling with water and air. Heat would degrade the metal over time, causing problems if you're making something like an engine.
This would allow creation of fixed engines with pistons (always cool).
I'm working through the intrinsics of a zero-g falling water simulation in 3d so I can make very convincing looking fountains and stuff, using particles of individual volume and cohesion. I am just getting into geometry shaders, and this seems like something that requires the use of one in order to be fast enough and look good.
[QUOTE=SCopE5000;16736250]Someone from FP needs to make a really fricking awesome fluids/sand game with input from Facepunch.
Personally I always wanted fixed joints like in phun combined with the physics and electricity of powder toy and heat creation and absorbtion by metal caused by things like fire, cooling with water and air. Heat would degrade the metal over time, causing problems if you're making something like an engine.
This would allow creation of fixed engines with pistons (always cool).[/QUOTE]
This :v:
Sorry, you need to Log In to post a reply to this thread.
