Partial Transparency Issue... - 2nd problem

After the help from mojomonk yesterday things finally made sense to me.

I rewrote the FirstPersonHandler to have a “bird’s eye-view” camera like in RTS Games.

And things look pretty good.

Today, I looked into transparency. I took the alphastate from HelloMousePick and modified HelloStates to have a cube with full and partial transparency.

And now i’m already back again asking for help :confused:

First of all: yes i did search the forums before making a new thread.

Found that appearently many people have had problems with transparency, too. But not the kind of problem i have.

Now to my problem:

As you see in the bottom right corner of the picture, i made a texture (.png) with

full transparency,

partial transparency (outer light red circle ) and

no transparency (inner two red circles).

I played around a bit with the Source, Destination and Test values in alphastate.

Starting with those from the tutorial

 as.setSrcFunction( AlphaState.SB_SRC_ALPHA );
 as.setDstFunction( AlphaState.DB_ONE_MINUS_SRC_ALPHA );

But it seems to me that no matter the settings, partial transparency only works "inside" the object itself, but not for objects behind it.
As you can see in the picture, the outer red circle (half transparent) is completely opaque for the sphere behind the box.

The doc mentions in the description of the class AlphaState that you could make a bottle with green glass and everything behind it would be tinted green.
That's what i'm trying to achieve (with texture of course). But how?

Are there additional settings required?
And what exactely do the various SB_, DB_ and TF_ values mean?

Thanks again for any answer :)

Are you putting the cube with the transparent texture in the transparent render queue?


SB stands for Source Blend

DB Destination Blend

TF Test Function

Sorry it took so long to reply, for some reason this post didn't ever show up when I clicked 'show unread posts'


Think I found it on my own.


Sorry for the thread. :slight_smile:

Amazing timing:

Warning - while you were typing a new reply has been posted. You may wish to review your post.

But thx anyway! :smiley:

I encountered another problem concearning transparency.

Looking a little closer at partial transparent textures, the following thing came up:

I don’t get transparency working for ALL faces of a real 3D object (like a cube).

The right cube on the screen is created via the jME Box class. The left one consists of 6 seperate Quads.

Both objects have exactely the same Material-, Texture- and AlphaState assigned.


Although, only the Quad-cube has correct transparency in all 6 faces, while the Box-cube seems to have only 3 faces working correctely, depending on the direction from which the faces are looked at.

The problem occurs in every test case I made. Even in the unchanged, where each face of the transparent boxes is only rendered correctely from one side.

As seen on the screenshot, the right and back faces behind the front face are rendered as they should be; while the left, top and bottom faces seem to be ignored (?)

I guess there is only a thing missing or wrong set, as usual :). Maybe it has something to do with the normals of the box? Or with the correct combination of Source, Destination and Test values?
(Sadly, flipping normals and testing various src/db combinations didn't help me...)

I hope it is no actual engine bug in handling transparency :/

To put it in one sentence:
How do I get the Box-cube to be rendered the same way like the Quad-cube (from any direction, of course)?

Ahhh, you figured out a difficult problem. Because transparency is based on pixels being set in the same place before it, rendering order is important (back to front). Currently, the render queue handles that for whole objects, but when the object needs to be self transparent we run into the problem. The object (box in this case) is rendered in a specific order, one face at a time. It's rendered in this order no matter what direction you are facing it, because it doesn't have any sense of camera. So if one side is rendered first and it is in the front we have a problem.

We are looking into a solution. If anyone knows a quick fix, I'm all ears. Right now, it involves breaking up geometry by tris and queuing them up, which isn't a pleasant thought.

I was kind of hoping there was some OpenGL solution.

Ok, we are going to have to implement a multi-pass transparency, to make sure all sides are rendered correctly. Renanse and I are discussing it, I'll get back to you.


Once again, i’m very impressed, i must say. Not only because of the quick and detailed answer, but also because of the support you are giving here.

Although i want to say that there is no need to haste at all (as far as my case is concearned), I already have come across another problem which I have to ask. :frowning:

Anyway, awesome job from you, mojomonkey!

Renanse is going to add the multipass transparency fix soon.

The fix is to render the object twice (as mentioned above,) culling the front facing polys the first pass and the back facing ones on the second pass.  Fix tested and works, doing a bit of cleanup now.  The RenderQueue will always render this way (giving more correct results) unless you specifically tell it not too by means of a flag on the RenderQueue.

Ok, the fix is in cvs.  Please note that two pass transparency is enabled by default when you use the transparent renderqueue bucket.  Also, any cullstate or zbufferstate you might have set on those objects will not be applied…  we need to override them to make the transparent effect look right.

See TestRenderQueue for some fun.  Hit Q to turn on the render queue and use R to toggle twopass rendering.