Hot answers tagged particles
It's a cool idea. You'd need some sort of diffusion gradient around your ship. There are three physical models I can think of that you might want: You want it to seem almost like it's a liquid medium, where the pressure gradient rebalances, i.e. once you've passed some particles they move back into your wake (like water behind a boat). In this instance, ...
Check out how PixelJunk Shooter did it (including simulation) in this presentation (PDF) at GDC2010.
I'm not sure why so many answers claim this is difficult or impossible. Handling a few dozen dynamic point lights is pretty conventional for a modern deferred rendering pipeline running on PC. Here's a quick example I cooked up: I use this script to dynamically spawn enough lights for my max particles (make sure you adjust your Particle System settings so ...
I stumbled across this tutorial a while back, which looks to be a good resource: http://www.gamedev.net/page/resources/_/creative/visual-arts/make-a-particle-explosion-effect-r2701
This is a very broad question, but generally particle system features can be broken down into a few categories. Here are some general ideas for the sorts of things you might want to have. Emission features define how, when, and where particles are emitted. Continuously generate particles at a fixed rate, or generate a cluster all at once when triggered ...
You could try the old school fire effect. Let's say you store an 8-bit temperature value for each of your pixels. At each update: Feed the bottom line with random "hot" pixels (e.g. 200-256). For the others lines, all the way up: Each pixel gets a new temperature from the pixel below Times a random decay factor Pick your pixel colors from an 8-bit ...
I admit I'm not aware of any ideal solution to this problem, so I'll describe a workaround that you may or may not be comfortable with: Render all of the particles using additive blending to a separate texture (or render target) with its background cleared to transparent. Render that texture (or render target) on top of your scene using alpha blending. I ...
There is an excellent SIGGRAPH presentation on PixelJunk Shooter 2's lighting and physics simulation, including fluid mechanics, available on youtube.
Yes, it is. Allocation time isn't the only factor. Allocation can have side-effects, such as inducing a garbage collection pass, which can not only impact performance negatively it can also impact performance unpredictably. The specifics of this will depend on your language and platform choices. Pooling also generally improves locality of reference for the ...
George Duckett's answer is far more direct and really well presented if you need fully-simulated water in your game. For simulated shallow-water physics with minimal accuracy (less realism, more playful), this image gave me an incredible moment of clarity: http://www.patrickmatte.com/stuff/physicsLiquid/
Here's what I would do. Step 1: Don't sort. Just do it. See if it's a problem. Most likely isn't. Step 2: Limit particles into such that do not really need sorting, such as: Just solids (with possibly alpha-to-coverage edges) let zbuffer take care of the sorting. Just additive bits a+b = b+a, so order doesn't matter Step 3: if more is needed, ...
What you want to do can also be thought of as reflecting the particle's velocity off the plane tangent to the circle at the point of contact. If you know the equation for doing that, then all you need to know is the circle's normal at the point of contact. To get that, all you need to do is normalize the vector from the center of the circle to the point in ...
Conserve your precious CPU/GPU cycles! You can inexpensively approximate rain (and rain splats) without using particles. The rain drops and splats don't even have to move or be aligned! Basically, randomly draw a bunch of the following sprites onto the screen: Source: bulletproofoutlaws.com (There's also a video of the final effect)
Praetor's link is excellent; +1 for that :). Sadly it doesn't mention blend modes. Additive blending is crucial for getting overlapping particles to saturate to white for really hot explosions.
The keyword you might need is "Metaballs," and ranges from the complex nVidia GPU Gems sample down to the demo scene driven versions designed only to look good and run fast.
Probably the first option, as the second option implies you can only have a single explosion in any given frame. Unless you're talking about having a factory produce the explosion objects in the second option, in which case the two options are not mutually exclusive and you probably should, in fact, do both. Regardless, the only downside to the first option ...
I think the key phrase is particle system so most of the samples out in the wild are going to be more complex than you would think a simple demonstration should be. OOP doesn't really enter into the low level part of particle systems and C is very straight forward to convert to other languages so I wouldn't worry about that. The trick to particles is that ...
Have a look at premultiplied alpha. http://blogs.msdn.com/b/shawnhar/archive/2009/11/07/premultiplied-alpha-and-image-composition.aspx
From the video showed it just seems to be plain gravity to me. Most people think gravity makes things flying downwards, but looking at it from a more far away perspective it makes things fly in a elliptical or spiral kind of motion around the center. The particles are always accelerated towards the center, however fly beyond it until the gravity forces it to ...
Box2D was written as a tutorial on how to write 2D physics engines. The site contains links to a lot of presentations on how the algorithms work and how to make it efficient. You might also want to look into this presentation done by the Pixeljunk Shooter team, describing how they did 2D fluids. If you are interesed in 3D, read Realtime Collision ...
Found the answer in here. You can directly use the output of the editor in the API. It's really cool.
How to create prerendered effect is another question. You can create fires, smoke etc in Autodesk Maya. It has very strong fluid solver (fluids means fire, smoke, nebulas or even fog ...). This can be also putted into sequence of files and played. For real smoke/fire etc. simulation, you can implement physically correct (or very near to it) fluid solver is ...
Just don't write to the depth buffer when rendering the particles. This will allow them to all be rendered and blended with each other. You should still perform depth testing though so that they can be properly occluded by geometry in the scene.
How does that save any significant amount of time? Presuming you handle the rotation in a vertex shader, that only saves time if you're VS bound. If you are talking about a fixed-function pipeline, it's much cheaper to precompute the rotated edge vectors for the quads you are using. Rotating the texture is then done by the GPU. The only way that might incur ...
The particle system solution is likely the one you want as creating and maintaining 100+ sprites with varying positions and gravity is exactly what a particle system does. Only it will handle object re-use for you automatically which will help make it as efficient as possible. Just create a line emitter that covers the entire width of your viewport. ...
The example image makes it much clearer what you want. "Contrail" probably isn't the right word for this; at my company we call it a "swoosh" but other people probably call it something like "sword trail", "sword slash" or similar. Anyway, the way to do this is basically to generate dynamic geometry, by recording the position of two points on the sword ...
First figure out the direction based on where the particle is in reference to where it came from (the explosion). Then you take the arc-tangent of that to get the angle. Vector2 direction = particlePosition - explosionPosition; float angle = Math.Atan2(direction.Y, direction.X);
The first option seems overwhelmingly preferable: it allows for the particles owned by a given emitted to be processed in bulk, and it allows you to do better broad-phase culling of objects. It provides locality of reference to your particles and implies far less per-frame maintenance of the same. The second "global particle list" option is a bad design ...
As with all other "preferable" or "best" approaches, it depends on what your end goal is. For example, if you associate the particle list with it's emitter, this means that the emitter must continue to live until the particles have all decayed away. So your emitter needs to have more state. It needs to know whether it should be actively emitting more ...
Using additive blending order doesn't matter: glEnable(GL_BLEND) glDepthMask(GL_FALSE) glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA) DrawParticles(); // Now turn depth masking on and blending off, so state is unchanged. glDepthMask(GL_TRUE) glDisable(GL_BLEND) This assumes that your sprite texture has a transparent background.
Only top voted, non community-wiki answers of a minimum length are eligible