Transparent BitmapTexts block particle effects and each other

Hi!

I have a problem with BitmapTexts. The image below demonstrates the problem, I think.

In the top screen shot everything looks like it should. But in the second one, the closest BitmapText blocks the view of the one behind it. It happens when the BitmapText in the back does not extend, horizontally, beyond the front one, on the screen. Also, as you can see in the bottom screen shot, BitmapTexts block the view of particle effects. Why does this happen? Is there a way to fix it?

This has to do with alpha transparency sorting. The nearer transparent pixels are drawn first and fill the zbuffer preventing the other pixels behind it from getting drawn.

In your situation, probably the only way to get reasonable results is to grab the font materials and force them to have an alphaDiscardThreshold suitable to your purposes. And you will probably also want to use a higher resolution font, anyway. (which would also minimize the issue here)

@pspeed said: This has to do with alpha transparency sorting. The nearer transparent pixels are drawn first and fill the zbuffer preventing the other pixels behind it from getting drawn.

Excuse my ignorance, but this seems to be fundamentally wrong. Surely if something is partly transparent, things behind it should get drawn first? :stuck_out_tongue: In the case with the particles, I know that the particles are all one mesh, or something like that, so it’s hard to say if they are in front or behind the text. But in the case of two BitmapTexts, it seems weird to me.

@pspeed said: In your situation, probably the only way to get reasonable results is to grab the font materials and force them to have an alphaDiscardThreshold suitable to your purposes. And you will probably also want to use a higher resolution font, anyway. (which would also minimize the issue here)

alphaDiscardThreshold seems to work well. Is there any downside to using it? :stuck_out_tongue: And by the way, is the best way to get at the material(s) of a BitmapText to use text.getChildren() and then .getMaterial() on all children?

Thank you!

@tuffe said: Excuse my ignorance, but this seems to be fundamentally wrong. Surely if something is partly transparent, things behind it should get drawn first? :P In the case with the particles, I know that the particles are all one mesh, or something like that, so it's hard to say if they are in front or behind the text. But in the case of two BitmapTexts, it seems weird to me.

Objects are sorted back to front when they are in the transparent bucket (presumably your text is) but this is imperfect. No matter what approach is used to sort at the object level it is trivial to construct cases where it isn’t right. JME sorts by nearest point on the bounding shape… which for billboarded text is going to vary widely if it’s even correct at all.

@tuffe said: Excuse my ignorance, but this seems to be fundamentally wrong. Surely if something is partly transparent, things behind it should get drawn first? :P In the case with the particles, I know that the particles are all one mesh, or something like that, so it's hard to say if they are in front or behind the text. But in the case of two BitmapTexts, it seems weird to me.

ad “behind drawn first”
in normal case of opaque objects, you dont want to bother which one is hidden behind another and checking if object has another object over it and that another object is transparent (it can kill fps), and rewriting pixels from one object by another object doesnt make sense in general because you should not draw unnecessary things (so you can have performance boost). and because opaque objects are majority in games, so you should want to optimize them first and most
so then it can make a sense to draw nearest objects first

ad “how to draw transparent things over opaque things”
you have buckets which has their order of drawing, so opaque first, transparent over opaque, translucent over transparent
i think you should be able to fix particles, by setting font’s spatial’s bucket to transparent and particle emitter’s to translucent bucket (or emitter to transparent and font to translucent)

ad “particles”
they are separate meshes (mostly flat quads rotated towards camera, this is named billboarding, like billboards near roads) and they have position, so you can say if they are there, or far away

@pspeed said: JME sorts by nearest point on the bounding shape...

what about make this as parameter?

something like spatial.setShapeCheck(ShapeCheck.Nearest / .Origin / .Farthest)

i think check against origin for billboarded things should improve it

@Ascaria said: what about make this as parameter?

something like spatial.setShapeCheck(ShapeCheck.Nearest / .Origin / .Farthest)

i think check against origin for billboarded things should improve it

Improve in some cases, make it worse in others. Billboards need not be flat and no matter what object sorting has trivial cases that will be wrong no matter what method you use.

Bottom line: you cannot rely on sort order to help you out of all situations and so must do different stuff (layers, material sorting, whatever). No reason to over-complicate the whole engine just to reduce the edge cases by 5% or so.

Edit: note that you can already set your own comparator and do whatever you want.