Sign in to follow this  

clipping problem in particle system

This topic is 4355 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites

This topic is 4355 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this