We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now

x

Alpha Transparency Problem

RageDBL
RageDBL asked
on
Medium Priority
494 Views
Last Modified: 2013-12-08
I'm having trouble with rendering some transparent polygons.
When I'm using z-buffer, if the first polygon in the vertex buffer is closer to the camera than the rest, then it doesn't blend with transparent ones behind it.
I have turned off z-buffer, and they will all blend, but because I have to render them separate from the ones that are z-buffered, that means that they are drawn on top of the other ones, and as a result, you can see them right through the solid polygons that were drawn with the z-buffer on.

My main problem is the blending. I want it to draw these polygons in BACK TO FRONT order of depth, so that the transparent polygons will always blend with the ones behind them, even if they are in the same vertex buffer.

Thankx
Comment
Watch Question

Commented:
First, draw your non-transparent polys with the z-buffer on like you're doing.

But then, before you draw your transparent polys, don't turn the z-buffer off entirely, just disable writing to it, like this:

      pD3DDevice->SetRenderState(D3DRS_ZWRITEENABLE, FALSE);

Then draw you transparent polys.  This way z-buffer *testing* will still be enabled, so your transparent polys won't draw over anything that's already there and closer to the camera, but z-buffer *writing* will be disabled, so the transparent polys won't change what's in the z-buffer.

Author

Commented:
Yes, I found out about something like that when reading 'Beginning Direct3D Programming' (2nd Edition, Premier Press) by Wolfgang Engel. I thought it might have something to do with the z-func, or something like that.

Are you sure that the same thing won't happen? I guess if that polygons are drawn front to back, then the nearest one will be drawn first, and the ones behind it will not be allowed to change that z-write, and therefore you will have the same problem.

I don't know, I'll have to try it, but right now, my newly installed DirectX9 oddly crashes upon window create. I just upgraded the program from DX8.1b to DX9.0b, and it's not working. I'm not even sure if DX9 is installed properly because there is no DirectX property page on the Control Panel.
If you could advise me on how to re-install DX8.1, I'd like to know.
I'm thinking of downloading the official DX9 SDK off the site because the one I'm using came on a CD with the aforementioned book ('Beginning Direct3D...'), and the what the book said was on the CD is different than what is actually on the CD.

If you can help there, please do.

RageDBL

Commented:
Quote:
"Are you sure that the same thing won't happen? I guess if that polygons are drawn front to back, then the nearest one will be drawn first, and the ones behind it will not be allowed to change that z-write, and therefore you will have the same problem."

I just want to make sure you're clear on how z-buffer writing and testing works.  I apologize if I'm over-explaining things (I don't intend to be insulting); I just want to make sure we're on the same page.

The z-buffer is essentially a depth buffer that tells you how far away each screen pixel is from the camera.  When you clear the z-buffer between frame renders, it sets all of the pixels to be the maximum distance from the camera.

When you render a poly, it takes each pixel that it wants to draw, and figures its z-depth (or how far it is from the camera).  If z-testing is enabled, before it draws the pixel it compares the pixel's z-depth with the depth at that location in the z-buffer.  If your poly's pixel depth is further from the camera than what's in the z-buffer, it doesn't draw that pixel, and it's done.

But if your poly's pixel depth is closer to the camera, then it does draw the pixel in the appropriate color.  Then, if (and only if!) z-writing is enabled, it changes that location in the z-buffer to the depth of the pixel that was just drawn.

So if you have z-testing and z-writing both enabled, it won't ever draw a pixel that's further away from the camera than the pixel that's already there.  This is how solid, non-transparent things are typically rendered.

So let's say you enable both z-testing and z-writing, then render all of your solid polys.  Then the z-buffer will have the correct depth values for all of the pixels visible on the screen.

But now you turn off z-writing (but leave z-testing on), and draw a transparent poly close to the camera.  It tests all the pixels to make sure it's okay to draw them, then draws their alpha-blended colors, but it doesn't actually change the depth values in the z-buffer.  So the z-buffer still has the further-away depth values of the solid polys, even though there's a transparent poly drawn in front of them (it's like the z-buffer doesn't "know" about this closer transparent poly).  Now if you draw another transparent poly behind the first one (but still in front the solid polys), it WILL draw it, because the z-buffer says it's okay (since the first transparent poly didn't change the z-buffer).  But if you try to draw a transparent poly behind a solid poly, it won't draw, because the z-buffer will have the correct depth values for the solid poly.

You will, however, get slightly different visual results in the way semi-translucent polys blend over each other if you draw them in different orders.  Just try it and see if you think it's an issue.  If it is, you will have to sort your transparent polys by their distance from the camera before rendering them.  Unless, of course, you're using additive blending (the kind you use for glowing effects like fire particles, etc.) in which case you get the same results regardless of rendering order.

Quote:
"I don't know, I'll have to try it, but right now, my newly installed DirectX9 oddly crashes upon window create. I just upgraded the program from DX8.1b to DX9.0b, and it's not working. I'm not even sure if DX9 is installed properly because there is no DirectX property page on the Control Panel.
If you could advise me on how to re-install DX8.1, I'd like to know.
I'm thinking of downloading the official DX9 SDK off the site because the one I'm using came on a CD with the aforementioned book ('Beginning Direct3D...'), and the what the book said was on the CD is different than what is actually on the CD."

You can get all the information about the different DirectX components on your system by going the the Start menu, selecting Run..., and typing "dxdiag".

As far as un-installing DirectX or installing an older version, technically, you can't.  There are some rather hacky uninstallers people have made, but they're the kind of thing you use at your own risk.

I would definitely download the latest DX9 SDK (rather than using what came with your book).

Author

Commented:
You are awesome! Thanx for the explaination. It's one thing to have someone who can tell you the answer, it's another thing for them to go on to explain it for you. The explaination was very helpful.
However, I DO have semi-transparent polygons in the scene (where one vertex is transparent and one is solid). So your saying that this would cause it to blend transparent polygons over the solid type? (it would be like you turned off the z-buffer). I know about glow-mapping with textures (or that additive blending thing), but I've never heard of using it with transparency (usually because the texture has to have an alpha channel (usually you use something like dds (Direct Draw Surface) files),  or you would have to use a monochrome bitmap as a second texture).
 
Thanx
Commented:
Unlock this solution with a free trial preview.
(No credit card required)
Get Preview

Author

Commented:
Interesting, I see, but I'd like to know exactly what value is used for 'D3DBLEND_ONE'. I know that the ADD operation in color brightens things, but I'd just like to know what the blending formula for this does (if you know). Wolfgang Engel went over such things in 'Beginning Direct3D Game Programming', which I mentioned before.

Right now, I fried my motherboard when I tried to upgrade the BIOS. The disk I was using was bad. I just got my computer back yesterday, with a different motherboard and a new processor and memory. I have yet to get the ATI Radeon 9600 SE 128MB AGP graphics card. I'll have to get back to you when I get everything installed OK. I'm currently using a public computer for everything.

Thanx anyways.

RageDBL

Author

Commented:
I got my graphics card (I got an ATI Radeon 9600 XT instead of SE) and I have everything running. I'm going to try your suggestion.
I still haven't set up my windows internet connection, though, so I'm still using a public computer.

Author

Commented:
I've tried your method with the ZWRITEENABLE stuff. That works great. However, the Additive blending thing has undesirable affects on the rendering when transparent and semi-transparent polygons are rendered together. I haven't yet tried separating the two, but I'm going to. I think that the normal polygons should be rendered with INVSRCALPHA and SRCALPHA, and the semi-transparent should use additive blending.

I'll get back to you later.

Author

Commented:
I have separated the two and seen that D3DOP_ADD does indeed work for semi-transparent polygons. It still looks as it did before, though. I think this might be what I have to live with. If there's anything that can be done to optimize this, please tell. Thank you.
Unlock this solution with a free trial preview.
(No credit card required)
Get Preview

Author

Commented:
I think I'm all set for now, thanks. I have it down. It works well enough for me.

Thanx for your help

RageDBL
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.