Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

fractoid

Fuzzy z-buffer for particles?

This topic is 5312 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

OK, this is something that''s been bugging me for a while: Whenever billboarded transparent particle systems are used, they are rendered the standard way (render opaque objects, then turn off z-buffer writing and render particles back-to-front), which works great most of the time. It goes ugly, however, when the particles intersect with geometry. You get a nice fuzzy outline round most of the particle, and then a hard line across where it intersects with a polygon. My thought is this: Treat each particle as having a ''depth'' as well as width and height, and evaluate opacity on a per-pixel basis depending on the z-buffer at that point, thus making a particle fade out where it hits a polygon rather than just being clipped and looking ugly. I guess this is relatively easy with shaders, but I''ve never seen it implemented... is it really hard, or does this graphical glitch just not irritate others as much as it does me? I know readbacks from frame and z buffers are slow normally, but surely that''s not the case with on-card operations? Bonus question: Can anyone think of a way to implement this using a fixed-function pipeline? I mean a practical, usable way, not just ''render the particle at fifteen different depths with varying opacities and send your performance down the tube''.

Share this post


Link to post
Share on other sites
Advertisement
Not really... although it is sort of faking a volumetric particle. The idea is to replace the boolean z-pass function with a floating point function. If Zpar is the z value of the particle, and Zpix is the z value of the pixel currently being drawn, then instead of the z-pass function being 'Zpar < Zpix' it becomes
if (Zpar < Zpix - fudge) return 1; else if (Zpar > Zpix + fudge) return 0; else return (Zpix - Zpar) / (2 * fudge) + 0.5f;

In this example 'fudge' is a depth fudge factor, which is equal to half the particle's 'thickness'.

Does that make sense?

[edit: forgot to point out that the return of the z-pass function is the opacity of the fragment. basically it fades out the particle instead of just cutting it off.]

[edited by - fractoid on March 5, 2004 8:21:51 AM]

Share this post


Link to post
Share on other sites
I thought of this a while ago, and as far as I can tell theres no way to emulate it on fixed function pipeline. Even using shaders I think you''ll need quite advanced ones since depth reads aren''t supported on the simpler ones.

You may be able to create this effect by abusing shadow mapping methods - fake soft shadows are basically the same thing, interpolating between several depth values to get an overall transparency value.

Share this post


Link to post
Share on other sites
A totally different approach (but probably equally CPU expensive) is to have a collision detection routine monitoring the particles, and fading then out if they get too close to a surface. You could also create a moderatedly simple bounding mesh for the particle system, and deform it so it never interects other models, and fade out the particles if they get close to the boundaries.

Silent Hill 2 used something like that for the fog. If you look carefully, the particle planes'' vertices will fade out if they get close to intersect other geometry, thus keeping the fog effect beliveable (seeing a cloud/smoke billboard intersect geometry completely destroys the effect).

Share this post


Link to post
Share on other sites
You could perhaps try depth sprites - they perturb the output depth of the pixel to avoid the ugly intersection.

Here''s a link

http://www.ati.com/developer/samples/DepthExplosion.html

-Mezz

Share this post


Link to post
Share on other sites
You can''t read the standard depth in a shader, so this trick requires rendering the entire scene to texture to get access to the deptyh values. Which is fairly expensive and probably the reason why people don''t do it. You could reduce the cost by only rendering objects that intersect the particles bounding volume, but it''s still a fairly high price to pay for a small visual gain.

I agree it''s an ugly artifact though.

Share this post


Link to post
Share on other sites
Actually - a neat approximation I thought of just now is this:
When doing occlusion culling, you generally render a low-res version of the scene (either in software or hardware) and have that image in system memory, right? How big is that low res image? Quarter screen res? Anything that size or bigger would give sufficient accuracy to just use the z-values in the occlusion culling image, and apply a single alpha to the whole particle billboard based on the float z_pass function at the centre of the particle. Then render without any depth test at all, back to front, after setting the particles'' alpha values ( culling invisible particles for speed).

It''d only work well for small particles, sure, but it does get rid of a most ulgy artifact, and this method shouldn''t make *too* much of a performance hit, assuming my guess about occlusion culling is right and you would be using that anyway...

Share this post


Link to post
Share on other sites
This really isn''t a soultion but if you use some sort of blurring you probably can hide the ugly intersections. You can render the particles the way the glows are rendered (like in Splinter Cell) so that in effect the rendered particles together will be blurred a bit and then blended onto the final image which should hide the intersection lines.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!