clipping problem in particle system

Started by
4 comments, last by Martin Fuller 18 years, 3 months ago
is there any effective way to deal with clipping problem (clipping line between particle and geometry when a particle collides with a geometry) when rendering particle system?
Advertisement
I don't understand your problem. Do you want to destroy a particle that collides with geometry?

JVFF
ThanQ, JVFF (Janito Vaqueiro Ferreira Filho)
There are a couple of different ways to deal with it. If it will still look ok, you could just disable the depth test when rendering your particles. However, this means that you have to render the particles from back to front. Most of the time the particles won't look out of place as long as you aren't in a confined space - the ceiling and walls would cause obvious artifacts.

You could also try to do collision detection with the particles and move them accordingly. Generally most particles are representing some type of spherical object, so the collision detection should be relatively simple. Then you could modify the particle position so that it doesn't intersect with other geometry.

Really it depends on the situation that you are going to be using the particles in. Hope this helps.
Wild early morning concept:
Why not just disable depth WRITES for particles? That way everything that was rendered already will still obstruct them, but they won't get in each others way.
f@dzhttp://festini.device-zero.de
Depth writes should most likely be disabled, but the problem is that particles get occluded by scene geometry when they should not be. Eg. when smoke moves close to a wall and the billboard geometry partly intersects the wall geometry. ATI has demo that shows how solve this problem by using depth sprites. I haven't tried this myself but someone mentioned in another thread that modifying depth in the pixel shader is really expensive so I don't know if this is a practical solution. Anybody know if this technique is used in any games?
Z textures seem to me like a nice concept. One console does this very nicely indeed. This is possible with pixel shaders by modifying oDepth. Normally a pixel shader is only executed on pixels which pass the z test, I guess the driver must spot writes to oDepth and move the ztest to after the pixel processing rather than before it. This would in effect kill most zbuffer optimisations + potentially massively increase fillrate. (In the case of a sprite which is partially or totally occluded)

The best thing I can think of is to artificially move the sprite forward in the z range in the vertex shader and then in the pixel shader, compute a new z based on a texture lookup and the sprite z's to get the actual z and write a totally transparent pixel if this fails a test with a depth buffer. While this is just two additional texture reads, depth buffer and sprite depth texture creating the depth texture itself might be quite expensive. Maybe a z only pass which wrote the depth of a low res render target? I suspect any artifacts introduced by using a lower than screen resolution render target would be acceptable for this use.

Just a thought.

[Edited by - Martin Fuller on January 10, 2006 10:38:31 AM]

This topic is closed to new replies.

Advertisement