TGA transparency issue
Hi I have started creating a particle system using TGA Files with an Alpha Channel. To start with I am drawing 2 Quads to the screen after my 3D Environment, the 2 Quads have my TGA Image on them. Where the Quads are over a piece of my 3D World Geometry, the transparency works fine. But when one of my Quads is in front of the other Quad the front Quad's transparencey doesn't work. That is, the Rear Polygons are working fine. but the Front Polygons not working when they are overlapping other Polygons from the Particle System. My Workflow is: Draw 3D Environment Disable Lighting Enable Blending Use ONE_MINUS_SRC_ALPHA Draw Rear Polygon Draw Front Polygon Enable Lighting Disable Blending I need to get this problem ironed out before I can finish the Particle System, I need all of the System's Polygons to be transparent in the right places, even when one is in front of the other as far as the camera is concerned. Can anyone help and please point me to what I am doing wrong or give me any helpful advice? I would be grateful for any help or advice and thank you in advance.
This wont solve your problems, but you should always enable/disable in accending/descending order.
you disabled lighting then enabled blending, so in the end you should disable blending, then enable lighting. Also GL_RGBA i the image loader?
you disabled lighting then enabled blending, so in the end you should disable blending, then enable lighting. Also GL_RGBA i the image loader?
Hmm, I thought gl was a state machine where enable/disable order had no impact.
Well reguardless your problem is you want to disable depth writing. This saves you from having to sort from back to front. Then your renderloop will be broken down into 2 basic steps.
Draw non blended items.
Draw depth-tested (not depth writting)
Well reguardless your problem is you want to disable depth writing. This saves you from having to sort from back to front. Then your renderloop will be broken down into 2 basic steps.
Draw non blended items.
Draw depth-tested (not depth writting)
the thing with trasparent objects are that they always need to be drawn back to front.
My guess is that the rear polygon is drawn infront of the front one causing trouble in the z buffer(the z buffer thinks that transparent objects are opaque).
However, for particle systems there are ways around theis depending a little on what type of effect your looking for.
for fire effects
GL_ONE,GL_ONE blending
No need for an alpha channel in the texture
Disable depth writing
draw them in any order
for dust/smoke effects(where the dust/smoke have only one color)
Use the standard alpha blending
Disable depth writing
draw them in any order(preferably though back to front)
for any other effect you need to order them acording to depth(back to front) and disable depth writing(this alows you to have a slight overlap without risking z-fighting)
My guess is that the rear polygon is drawn infront of the front one causing trouble in the z buffer(the z buffer thinks that transparent objects are opaque).
However, for particle systems there are ways around theis depending a little on what type of effect your looking for.
for fire effects
GL_ONE,GL_ONE blending
No need for an alpha channel in the texture
Disable depth writing
draw them in any order
for dust/smoke effects(where the dust/smoke have only one color)
Use the standard alpha blending
Disable depth writing
draw them in any order(preferably though back to front)
for any other effect you need to order them acording to depth(back to front) and disable depth writing(this alows you to have a slight overlap without risking z-fighting)
www.flashbang.se | www.thegeekstate.com | nehe.gamedev.net | glAux fix for lesson 6 | [twitter]thegeekstate[/twitter]
Thanks for the replies, I appreciate the help.
Just so I understand then, (PLEASE CORRECT ME IF I AM WRONG, and confirm if I am right :) ) I have 2 choices:
1/ disable depth writing, and draw in any order, but have to accept that I will get some problems when the quads overlap (I am currently doing this, and have the transparency working, but do get some odd results when certain quads which should be at the rear are drawn infront of ones at the front).
2/ Order the quads in terms of depth, then draw them in the right order (have done this also, and this worked fine and was perfect for my needs graphically).
For me, technique 1 works, and with enough particles, small enough particles, and travelling at a decent speed, this works ok. But noticable z-fighting does occur at times when close up to the quads.
Technique 2 is great graphically, but if I have a system with say 5000 particles, which move on all 3 axis, then it strikes me that I would have to do a sort every single frame to get the particles in the right order for drawing.
Are these my 2 serious options? And if so, is the second technique not realistic with so many particles, or can modern processors handle such computation each frame, on top of all the other typical game calculations (in general, I know of course that only generalisations can be made with so little detail given).
Just so I understand then, (PLEASE CORRECT ME IF I AM WRONG, and confirm if I am right :) ) I have 2 choices:
1/ disable depth writing, and draw in any order, but have to accept that I will get some problems when the quads overlap (I am currently doing this, and have the transparency working, but do get some odd results when certain quads which should be at the rear are drawn infront of ones at the front).
2/ Order the quads in terms of depth, then draw them in the right order (have done this also, and this worked fine and was perfect for my needs graphically).
For me, technique 1 works, and with enough particles, small enough particles, and travelling at a decent speed, this works ok. But noticable z-fighting does occur at times when close up to the quads.
Technique 2 is great graphically, but if I have a system with say 5000 particles, which move on all 3 axis, then it strikes me that I would have to do a sort every single frame to get the particles in the right order for drawing.
Are these my 2 serious options? And if so, is the second technique not realistic with so many particles, or can modern processors handle such computation each frame, on top of all the other typical game calculations (in general, I know of course that only generalisations can be made with so little detail given).
that's pretty mutch the two choices you have if you disregard the case in where you have fully opaque alphatested particles(this is seldom done though).
a modern processor might handle 5000 particles if you do some optimizations, but anything over that might be hard.
There are some ways around this if you have a static particle field, witch is most comonly used for vegitation(if you ever played Battlefield Vietnamn you have seen this), but it's a bit advanced.
a modern processor might handle 5000 particles if you do some optimizations, but anything over that might be hard.
There are some ways around this if you have a static particle field, witch is most comonly used for vegitation(if you ever played Battlefield Vietnamn you have seen this), but it's a bit advanced.
www.flashbang.se | www.thegeekstate.com | nehe.gamedev.net | glAux fix for lesson 6 | [twitter]thegeekstate[/twitter]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement