Clipping issues with BitmapText in 3D

delaney · May 6, 2011, 6:24am

I’d like to be able to have BitmapText in 3d. Looked at the TestBitmapText3D.java but its using a solid background. Would like to use a transparent bg so here’s the jist of what I tried.

[java]

BitmapFont font = assetManager.loadFont(“interfaces/fonts/verdana-small-regular.fnt”);

BitmapText helloText = new BitmapText(font, false);

helloText.setSize(1f);

helloText.setText(“Hello World”);

helloText.setLocalTranslation(0f, 1.5f, 0f);

helloText.setQueueBucket(Bucket.Transparent);

rootNode.attachChild(helloText);

[/java]

However getting weird clipping issues, setting the Bucket.Transparent didn’t seem to have an effect. Hopefully the pic shows what I’m doing wrong.

http://img831.imageshack.us/img831/7933/weirdclipping.jpg

Note that the clipping stuff changing as you move the camera around.

Momoko_Fan · May 6, 2011, 3:41pm

To have a transparent background, it should just be enough to remove the quad behind it

delaney · May 6, 2011, 4:12pm

Hey Momoko Fan, thanks for all the help so far. Not sure what you mean. If I turn off the gray plane it still is getting clipping. I had to modify the example jme3/src/test/jme3test/gui/TestBitmapText3D.java slightly cause I"m using eclipse but

[java]import com.jme3.app.SimpleApplication;

import com.jme3.asset.plugins.FileLocator;

import com.jme3.font.BitmapFont;

import com.jme3.font.BitmapText;

import com.jme3.font.Rectangle;

import com.jme3.renderer.queue.RenderQueue.Bucket;

import com.jme3.scene.Geometry;

import com.jme3.scene.shape.Quad;

public class TestBitmapText3D extends SimpleApplication

{

private String txtB = “ABCDEFGHIKLMNOPQRSTUVWXYZ1234567890`~!@#$%^&*()-=_+[];’,./{}|:<>?”;

public static void main(String[] args)

{

TestBitmapText3D app = new TestBitmapText3D();

app.start();

}

@Override

public void simpleInitApp()

{

assetManager.registerLocator(“assets/”, FileLocator.class.getName());

BitmapFont font = assetManager.loadFont(“interfaces/fonts/verdana-small-regular.fnt”);

Quad q = new Quad(6, 3);

Geometry g = new Geometry(“quad”, q);

g.setLocalTranslation(0, -3, -0.001f);

g.setMaterial(assetManager.loadMaterial(“Common/Materials/RedColor.j3m”));

rootNode.attachChild(g);

BitmapText txt = new BitmapText(font, false);

txt.setBox(new Rectangle(0f, 0f, 6f, 3f));

txt.setQueueBucket(Bucket.Transparent);

txt.setSize(0.5f);

txt.setText(txtB);

rootNode.attachChild(txt);

}

}[/java]

Gives me

http://img849.imageshack.us/img849/7169/textclipping.jpg

Doesn’t seem to be related to the quad at all (I didn’t use a quad behind it in my test before.

pspeed · May 6, 2011, 6:01pm

Is this a font that you’ve created? Did you create it in jme or the angel font tool? If the latter, what font settings did you use for things like padding, etc.?

…to me, it seems like the letter quads are way bigger than they need to be for some reason. Do either of the standard JME fonts also do this (Interface/Fonts/Console.fnt and Interface/Fonts/Default.fnt)?

delaney · May 6, 2011, 6:09pm

The is a font from the nifty gui package that I took out and used for my eclipse project. If I use the Default/Console fonts it works fine! Going to try custom fonts from angel and will report back. thanks!

delaney · May 6, 2011, 6:19pm

Yep, so making my own font works much better than the ones I found in nifty gui. There is still some clipping where there is overlap (such as W & X) between characters but i’m sure that’s just an options thing in angel font.

Momoko_Fan · May 6, 2011, 11:35pm

It looks to me like a z-fighting issue.

Maybe you can move the red quad back a bit?

pspeed · May 7, 2011, 12:52am

It is Z fighting but it Z fights when there’s no square. It’s the bitmap text quads that are Z fighting… like in the first picture.

…at least that was my guess and switching fonts confirms it more or less.

delaney · May 7, 2011, 1:01am

Yep it was definitely z fighting. Narrowed it down to using the ‘outline’ feature of angel font. If you don’t do that then it works perfectly. Solved!

pspeed · May 7, 2011, 1:11am

Ah, yes. I’ve hit this issue too. I think JME’s BitmapText doesn’t provide the extra spacing necessary.

delaney · May 7, 2011, 3:13am

yep, it’d be nice if there was a wiki entry on the valid angel font’s configurations.

mulova · June 22, 2011, 6:05am

I’m so sorry for late reply.

I compared BitmapText with jme2 version and found one bug about xOffset.

Please check this.

[patch]

Index: src/core/com/jme3/font/LetterQuad.java

===================================================================

— src/core/com/jme3/font/LetterQuad.java (revision 7686)

+++ src/core/com/jme3/font/LetterQuad.java (working copy)

@@ -25,6 +25,7 @@

private float width = Integer.MIN_VALUE;

private float height = Integer.MIN_VALUE;

private float xAdvance = 0;

private float xOffset = 0;

private float u0;

private float v0;

private float u1;

@@ -140,11 +141,11 @@

}

float getX0() {

```
 return x0; 
```

```
 return x0+xOffset; 
```

}

float getX1() {

```
 return x0+width; 
```

```
 return x0+xOffset+width; 
```

}

float getNextX() {

@@ -228,6 +229,7 @@

height = Integer.MIN_VALUE;

alignX = 0;

alignY = 0;

```
 xOffset = 0; 
```

BitmapCharacterSet charSet = font.getCharSet();
this.bitmapChar = bitmapChar;
@@ -281,7 +283,7 @@
height = 0;
xAdvance = 0;
} else {
- float xOffset = bitmapChar.getXOffset() * sizeScale;
+ xOffset = bitmapChar.getXOffset() * sizeScale;
float yOffset = bitmapChar.getYOffset() * sizeScale;
xAdvance = bitmapChar.getXAdvance() * sizeScale;
width = bitmapChar.getWidth() * sizeScale;
@@ -292,7 +294,7 @@
if (previous.isHead() || previous.eol) {
x0 = bound.x;
} else {
- x0 = previous.getNextX() + xOffset * incrScale;
+ x0 = previous.getNextX();
}
y0 = lineY + LINE_DIR*yOffset;

@@ -343,8 +345,8 @@
}

public void storeToArrays(float[] pos, float[] tc, short[] idx, byte[] colors, int quadIdx){
- float x = x0+alignX;
- float y = y0-alignY;
+ float x = getX0()+alignX;
+ float y = getY0()-alignY;
float xpw = x+width;
float ymh = y-height;

@@ -379,8 +381,8 @@
}

public void appendPositions(FloatBuffer fb){
- float sx = x0+alignX;
- float sy = y0-alignY;
+ float sx = getX0()+alignX;
+ float sy = getY0()-alignY;
float ex = sx+width;
float ey = sy-height;
// NOTE: subtracting the height here
@@ -394,8 +396,8 @@
public void appendPositions(ShortBuffer sb){
final float x1 = getX1();
final float y1 = getY1();
- short x = (short) x0;
- short y = (short) y0;
+ short x = (short) getX0();
+ short y = (short) getY0();
short xpw = (short) (x1);
short ymh = (short) (y1);

[/patch]

I have a question about the .fnt format generated by AngelFont.
The jme2 code says 'xadavnce' is the distance from one character(A) and the next character(B).
and 'width' is the (A)'s character width.
So I think 'xadvance' should be not smaller than 'width' but it's not always true.
It incurs the overlap of the characters like above.
Does anybody know what I have missed?

pspeed · June 22, 2011, 6:13am

I don’t remember if “float getNextX()” is used in the size calculations but if so then there may need to be similar changes made in BitmapFont or nifty will start overclipping again.

BitmapFont and BitmapText use entirely different algorithms to calculate text size but it’s important that they return the same value. The nifty interface uses BitmapFont’s calculation to determine the clip rectangle and if it is too small then the BitmapTexts get clipped.

mulova · June 22, 2011, 6:25am

You mean the change should be applied to BitmapFont.getLineWidth(). right?

pspeed · June 22, 2011, 6:47am

Yes, if BitmapText is now returning a different value.

mulova · June 22, 2011, 6:57am

Thank you. I’ll check it and back.

Ogli · November 18, 2013, 1:37pm

Z-Fighting with nearby Quads:
Shouldn’t happen if you don’t write to Z buffer when a quad pixel has alpha <= 0.0
The solution is to simply change the GLSL code a little bit: use the “discard” function for fragments with zero alpha

:roll:

pspeed · November 18, 2013, 4:47pm

@Ogli said: Z-Fighting with nearby Quads: Shouldn't happen if you don't write to Z buffer when a quad pixel has alpha <= 0.0 The solution is to simply change the GLSL code a little bit: use the "discard" function for fragments with zero alpha
:roll:

This thread is 1.5 years old at last response. Did you really mean to necro it?

Ogli · November 18, 2013, 6:20pm

Sorry, but I couldn’t resist.
In the coming days I shall experiment with 3D GUIs and find out if the problem is really fixed.
Did not know this term “necro” before, though.

My recent experiments with Fonts and BitmapText brought me here.
Soon I will have a closer look at the jME, Nifty, Font rendering routines.
I want to do some things like Nifty in 3D, custom shaders with Nifty, multiple Niftys at once.
And I have a cool hologram-shader in mind, that will need multiple transparent render queues from jME.
Also there might be a problem with humanoids and clothes attached to them, if jME works the way I think it works.

pspeed · November 18, 2013, 8:12pm

@Ogli said: Sorry, but I couldn't resist. ;-) In the coming days I shall experiment with 3D GUIs and find out if the problem is really fixed. Did not know this term "necro" before, though.
My recent experiments with Fonts and BitmapText brought me here.
Soon I will have a closer look at the jME, Nifty, Font rendering routines.
I want to do some things like Nifty in 3D, custom shaders with Nifty, multiple Niftys at once.
And I have a cool hologram-shader in mind, that will need multiple transparent render queues from jME.
Also there might be a problem with humanoids and clothes attached to them, if jME works the way I think it works.

BitmapText uses Unshaded. It’s possible to loop over the materials in the font and set the alphaDiscardThreshold to avoid z-fighting… or just turn depth write off all together.

You can set your own geometry sorter… you may not need separate queues. Multiple viewports might work for you, also.