Problem with blending particles
It looks like you're using z-buffering which works fine for opaque- but not for transparent geometry.
You should do the following:
1) Render all non-transparent geometry with enabled z-buffer
2) Disable z-write but keep z-testing enabled
3) Render all transparent geometry
4) Enable z-write again
This should do the trick in most cases. (Note that because z-write is disabled, the transparent objects won't necessarily be rendered in the right order. Sometimes this can be a problem and you'll have to manually sort your transparent geometry back to front.)
You should do the following:
1) Render all non-transparent geometry with enabled z-buffer
2) Disable z-write but keep z-testing enabled
3) Render all transparent geometry
4) Enable z-write again
This should do the trick in most cases. (Note that because z-write is disabled, the transparent objects won't necessarily be rendered in the right order. Sometimes this can be a problem and you'll have to manually sort your transparent geometry back to front.)
Here's a pretty good page on the issue: http://www.sjbaker.org/steve/omniv/alpha_sorting.html and it also suggests a good OpenGL-specific solution.
Explanation:
Most 3d applications use a z-buffer to ensure that objects that are closer the camera actually are drawn in front of objects that are further away. Rather than actually sorting the geometry back to front, a very cool trick is used:
Whenever a pixel is to be drawn, the depth of that pixel is determined and compared to what's called the z-buffer. The z-buffer is basically an image the size of the frame buffer. However, rather than storing color information it will store the depth of each pixel. This way, when drawing a pixel, you can do a very simple test to see if the pixel you're about to draw is closer to the camera than the one that's (probably) already been drawn at the same position. If the pixel is visible, the corresponding z-value is written to the z-buffer (z-write) and the color is written to the frame buffer. This works really well for opaque geometry because pixel that are closer to the camera will nicely occlude any pixels that are further away. However, it fails pretty badly for transparent pixels. Here's the thing: if a transparent object is drawn very early on and an opaque object which should be behind the transparent object is to be drawn later, that object will fail the z-test. That's because the z-buffer doesn't take transparency into acount and therefore doesn't know that it should actually be drawing the object.
Explanation:
Most 3d applications use a z-buffer to ensure that objects that are closer the camera actually are drawn in front of objects that are further away. Rather than actually sorting the geometry back to front, a very cool trick is used:
Whenever a pixel is to be drawn, the depth of that pixel is determined and compared to what's called the z-buffer. The z-buffer is basically an image the size of the frame buffer. However, rather than storing color information it will store the depth of each pixel. This way, when drawing a pixel, you can do a very simple test to see if the pixel you're about to draw is closer to the camera than the one that's (probably) already been drawn at the same position. If the pixel is visible, the corresponding z-value is written to the z-buffer (z-write) and the color is written to the frame buffer. This works really well for opaque geometry because pixel that are closer to the camera will nicely occlude any pixels that are further away. However, it fails pretty badly for transparent pixels. Here's the thing: if a transparent object is drawn very early on and an opaque object which should be behind the transparent object is to be drawn later, that object will fail the z-test. That's because the z-buffer doesn't take transparency into acount and therefore doesn't know that it should actually be drawing the object.
Author
Oh.... that seemed pretty complicated for what I wanted to do. I think if there's no easier solution than that, I'll just replace my particle texture with a solid circle or something instead. Thanks anyway.
By the way, I noticed that doing glDepthFunc(GL_ALWAYS) before drawing the particles seemed to remove the black box around the texture. It still doesn't look right though, because when viewed top-down there is 100% blending making the smoke full white bright instead.
By the way, I noticed that doing glDepthFunc(GL_ALWAYS) before drawing the particles seemed to remove the black box around the texture. It still doesn't look right though, because when viewed top-down there is 100% blending making the smoke full white bright instead.
I'm also going to ask what kind of blending are you doing? The circumstances you are using seem somewhat misleading. By that I mean it could be a depth issue but it also could be a blending issue where the image wasn't created correctly. Your "smoke" looks light so I'm guessing you are going for an Add Blended look?
There are basically 2 kinds of particals. Add Blended and Alpha blended. Add blended works well for lights and flames but not much else. They are easy to make art wise because only what you want tends to show up. For things like smoke you have to turn to alpha blending which requires a proper alpha channel which often gets forgoten about. It tends to also fry some people's brains because key programs like Photoshop and the Gimp won't create a correct alpha channel without you telling it to. You cant just click on save as 32-bit image and get a working alpha channel. You have to manualy go in to the alpha channel and get your hands dirty. Which can be irritating if your not a hard core photoshopper.
FYI PNG doen't support alpha channels.
There are basically 2 kinds of particals. Add Blended and Alpha blended. Add blended works well for lights and flames but not much else. They are easy to make art wise because only what you want tends to show up. For things like smoke you have to turn to alpha blending which requires a proper alpha channel which often gets forgoten about. It tends to also fry some people's brains because key programs like Photoshop and the Gimp won't create a correct alpha channel without you telling it to. You cant just click on save as 32-bit image and get a working alpha channel. You have to manualy go in to the alpha channel and get your hands dirty. Which can be irritating if your not a hard core photoshopper.
FYI PNG doen't support alpha channels.
In fact, PNG includes alpha information (only the PNG-32 format, not palleted PNG-8, if I recall correctly)
The easiest alpha support I've used is the one in Paint.NET. All images have translucency, and is saved if you use a format that supports alpha (PNG-32, TGA)
The easiest alpha support I've used is the one in Paint.NET. All images have translucency, and is saved if you use a format that supports alpha (PNG-32, TGA)
Quote:Original post by Ioachim Berselius
In fact, PNG includes alpha information (only the PNG-32 format, not palleted PNG-8, if I recall correctly)
The easiest alpha support I've used is the one in Paint.NET. All images have translucency, and is saved if you use a format that supports alpha (PNG-32, TGA)
I didn't think it did. I tried to get Photoshop to save a 32-bit PNG but it tossed my alpha channel away.
I like the TGA files myself. The support all the importaint goodies and provides some simple compression which can cut a lot disk space on the right images.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
