Stateless particle systems?
Blitz3D Forums/Blitz3D Programming/Stateless particle systems?
| ||
| Hi, Just reading the new article on Gamasutra.com called "Building a Million Particle System". As a non-programmer most of it went over my head but I am intrigued by the mention of something called a "stateless particle system" wherin there are no stats tracked for the particles (velocity, x_position, y_position, etc.) and thus freeing up processor overhead. I'm assuming everything is precalculated but I can't wrap my brain around it. Does anyone have a simple code example for a stateless particle system or where I might be able to find more info. I searched the web but came up with mostly vague references and nothing detailed enough to help. Thanks! |
| ||
| if you have the link to the article :) Can't think of a way to do that beside predefined splines etc which won't be that "physical correct" in the end |
| ||
| It's on www.gamasutra.com main page. You have to be registered to read the actual article. |
| ||
| I know! you render a particle on 3ds max or maya, then you play it like a video! But I'll go check the article. |
| ||
| Um, that wouldn't decrease processor overhead at all. That would increase it, because now you're eating up processor time to play a movie. As for physical correctness in particle systems, it's not like standard real-time particle systems are physically correct. |
| ||
| "To simulate particles on a GPU you can use stateless or state-preserving PS. Stateless PS require a particle's data to be computed from its birth to its death by a closed form function which is defined by a set of start values and the current time." In other words, the article is saying that you can render particles using a pixel shader, with, presumably, one particle per pixel, and using equations like the following: Current_X# = Start_X# + Normal_X#*Current_Time# Current_Y# = Start_Y# + Normal_Y#*Current_Time# Note that Start_X# and Start_Y# need not be stored if all particles start at the same location, or you have a randomize function where you can seed it so the output is the same every time. Same goes for Normal_X# and Normal_Y#. The only variable is time, and the current location is not stored to be used in the equation again later, it is only used that frame to draw the particle. This is the equation for a line. To be useful you'd need more complicated equations which define curves, and allow for acceleration and deceleration. With this method it is not possible for particles to collide with anything and change direction, but it is possible to have complex looking motion and lots and lots of particles. [edit] My bad, I should have read the article all the way through... While what I described would work, the article goes on to describe a method which uses textures to store data. My first guess as to what it was doing... I was going to say it's like a water simulation somehow. There is a well known algorithm for simulating water where all you do is update a bitmap each frame using it's last set of values and waves move through it automatically when changes are made to it. This works because the height of a water pixel also encodes it's energy. Ie, a tall wave has a lot of energy and will collapase when when it does will send out other waves in all directions. Skimming through this algorithm appears to use a texture to store velocities and positions, but upon closer inspection, it does not appear ro be doing anything like the water algorithm. In fact, it appears to be anyhting BUT "stateless". It appears to just use the textures to store the locations and velocities of each particle, and then it calculates it's motion from that in a pixel shader. Then it draws the particles using a vertex shader. I guess the advantage here is the GPU is doing all the work, rather than the CPU. This sort of thing won't help anyone write a faster particle system in Blitz because it doesn't have pixel or vertex shaders. [/edit] |
   |