why transparencies change as camera turns around?
each of these 3 cubes are using a transparent material,
mat...("Common/MatDefs/Misc/Unshaded.j3md");
mat.getAdditionalRenderState().setBlendMode(BlendMode.Alpha);
geom.setQueueBucket(Bucket.Transparent);
on the 4 screen shots, they change a bit the color as I turn the camera,
how can I fix that?
The back to front sorting for the cubes will be different as you turn around.
Short answer: you canāt, really. Itās just the nature of transparency.
You could control the sort order but then it will be wrong in other directions.
You could turn off depth testing but then it will interact poorly with other things.
At some point, transparent objects are not going to play well together so itās best to not put too many of them together.
wow, so many ppl asked that kind of thing?
may be, when we are trying to create a topic here, this forum engine could show/search more similar topics, as I always read them to see if my question was already answered, and this time there was nothing useful there.
thx!
Transparency is one of those things that seems really cool until you start to hit the issuesā¦ and then they turn out to be impossible to resolve in a general case.
So it comes up often.
It does if you use the search in the upper right corner.
Once you enter the search term you might have to arrow back to get the popup to show.
Impossible is a strong word, especially since unreal engine has this sort of thing in the bag.
No matter the technique, until we have pixel-level depth sorting, there is always some case that will break the technique or some limitation that is deemed āacceptableā but is still a limitation.
It canāt really be otherwise since the failing cases are trivial to conceive. Just take two semi-transparent triangles that intersect. Pretty impossible.
Even in the unreal example, as soon as you try sorting between the different soldiers you will run into issues where oneās arm is hidden or hiding the other. Even in the view above Iām pretty sure you see the one on the far left completely obscured by the one in the middle when we are viewing the one on the far right. They seem very careful to try to avoid those views.
But anyway, itās kind of provably impossible to handle in the general case at the triangle level.
I usually type my question subject on a new question and wait for that few 6 sugestions show on the right
mmmā¦ like in the current z sorting is based on each geometry translation, so we have the glitches.
And if we had the per triangle z sorting, small triangles would work better than big ones.
so, those blender models with a huge amount of triangles could work almost perfectly, as long we use them sparingly (memory, GPU/CPU usage) right?
Despite the boxes are for tests only, if I was going to actually use them, I could subdivide in many small quad geometries to create the boxes 6 walls, and put them all in a BatchNode to speed up, I guess it would work better? I wonder if BatchNodes mesh support skeleton/bones bending btw?
Finally, the pixel thing would be required to be a GPU internal capability because on the CPU it would not work well I guess (too costy)?
Per-pixel real time transparency sorting is kind of a pipe dream but yeah, it would absolutely have to be on the GPU. I like to imagine someday weāll have enough memory that we could keep a stack per pixel of some depthā¦ even then the limitation would be that more than āstackā number of transparent overlap would have artifacts.
Iām sure there are tons of white papers on this subject.
Blender doesnāt really have this issue because it can ray trace and do other non-real-timey things
Sometimes I make test cases to test things like transparency and, in doing so, make impossible scenarios. Your example looks like that is the case. The three trans above, are far enough apart that you wonāt have issues. Move your boxes farther apart and see if it works better.
I just tried that, didnt work, many transparencies are not working also, against each other and against opaques, most of the time transparencies per se seem to not work at al, it is like all are opaque, my guess is it is my old notebook internal gfx card limitations, may be it is just impossible with it.
On the other handā¦ I just thought, what would be an alternative for low end pcs? may be textures where colored opaque dots are intercalated with fully transparent ones, I guess that could overcome all transparencies requirements to have a funcional gameplay wise transparency (where the transparency is part of the game logic, of the gaming experience), even if it does not look as good as a full transparency effect, but it could still be functional.
99% of the time, transparency problems are sorting issues. The other 1% of the time, they are also sorting issues but the person reporting hasnāt figured that out yet.
Itās not really a graphics card specific thing unless itās a total piece of garbage and barely functions.
there is something I am not being able to grasp,
it is spoken as if we end users can control the sorting of transparent objects,
but I read that opaques are drawn near to far, and transparencies are drawn far to near, therefore camera Z.
and so, we cannot control it.
so what I mean is, if we cant determine what will be drawn first/last, and still there is a way to let the transparencies work here (āIntel Core Processor Integrated Graphics Controllerā i915), what I am missing? 
It doesnāt matterā¦ it is IMPOSSIBLE to sort it properly in all directions.
As in NOT POSSIBLE.
Imagine your cubes penetrated each other. Which way should they be sorted so that transparency works properly? Answer: impossible.
You CAN control the sort order. Just register your own geometry comparator. But how would you sort them so that it works? If you can find a way then you can solve your problem but it will be extremely specific to your use case.
wow cool thx! will look for that and make some tests 
btw, if it is possible at all, I would render the regions of each cube that are not intersecting, and would render the intersections after, something like that I guess, so I would have not 2 but 3 things to be rendered, and the 3rd could even be created with CSG, but this was just a wild thought :).
Yes, if you break everything up into separate geometry it might be ok for a static scene. It gets trickier if things move.
I think most people eventually just decide not to have so many transparent things together.
Note: you could also try rendering them with depth write off. If they render as youād like to see them that way then you could just render them that way.
If you need them to properly Z-test with other objects then you could have fully transparent geometry drawn in the same place with with depth write onā¦ and make sure they always sort to draw after.