Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

The correct approach has already been explained here. What you're trying to do is unnecessarily complex, the only thing you need is stbtt_GetCodepointHMetrics and the advance value.

I have updated the Truetype demo in the LWJGL repository with some example code, here. It does the following:

- Iterates the string's codepoints correctly (i.e. combines surrogate pairs), so works across the entire UTF-16 range.
- Uses stbtt_GetCodepointHMetrics to sum the codepoint advance values. (super simple)
- Uses stbtt_GetCodepointKernAdvance to adjust the advance value, for fonts with kerning information. (improves quality significantly)

All of the above can be precomputed/cached for performance.

If you can run the demo, press K to toggle kerning on/off and B to render a bounding box around each line (it should be tight around the text). Note that the included demo/FiraSans.ttf does not have kerning information. Change it to e.g. C:\Windows\Fonts\Arial.ttf to see how kerning works.

Also note how the line bounding box is adjusted with the descent value returned from stbtt_GetFontVMetrics.

hello, ive recently stepped into LWJGL and the first problem i encountered is that when rescaling the window it will rescale the textures according to the width AND height, which is not really what i want because squares will turn up into rectangles

ive tried using gluPerspective which does the same, i tried glOrtho which also does the same,
so im asking nicely, can somebody help me by just giving an general direction of what method i should use?

The number of vertices is not really that big of a deal. The resulting fragments are much more important. Rendering a trillion very tiny triangles is easier than rendering a million really big ones.

OMG you are true I was Trying to render 134217728 vertices per frame
with my dead pc

Thanks Guys

This is not really how you would build a game like minecraft. Even if you ditch the horribly slow immediate mode rendering you are using right now and replace it with VBO's or Display Lists you will still not get a comparable result. Games like minecraft do not render the entire world all the time. They carefully calculate exactly which blocks need to be rendered and which ones dont. They also calculate which sides of these blocks need to be rendered. Without doing this culling, the professionally made games would have awful performance as well.

Hi there,

I am running into troubles with stb_truetype again when it comes to calculating string sizes. I have a very simple question and I am afraid of the answer since I guess it wont be the one I want:

Can I calculate the width of a String rendered with stb_truetype without actually rendering it?

I tried the following:
1) My first approach was to call stbtt_GetCodepointBox and stbtt_GetCodepointHMetrics for each code point and calculating the width and height of the glyph like this:
float glyphW = Math.max(Math.abs(x0 - x1), Math.abs(adv + lsb));
float glyphH = Math.max(Math.abs(y0 - y1), fontHeight);
with x0, x1, y0 and y1 taken from stbtt_GetCodepointBox and adv and lsb being the advance and the left side bearing from stbtt_GetCodepointHMetrics.

Then I calculated the size of a string by adding up the glyphW values for each code point in the String. This value was too large! It usually missed the mark by 5% ~ 20% depending on the contents of the String.

2) My second approach was to calculate the width of all glyphs the same way the rendering does and store the widths statically. I called stbtt_GetBakedQuad and calculated:
float glyphW = Math.abs(q.x0() - q.x1());
float glyphH = Math.max(Math.abs(q.y0() - q.y1()), fontHeight);

Again I calculated the width of a String by iterating over all code points and adding the glyphW values I previously calculated. This value was often (not always) too small!




So, is there a reliable and correct way to statically calculate the string size without keeping the stb data around after an initialization phase? Or do I need to call stbtt_GetBakedQuad (and keep the quad info) every time I want to know the size of a String?

Thank you all.

Where Is It int LWJGL 3 
My OpenGL 1.4.0 - Build 4.14.10.4543

Thank u very very much!
It seems now i have a lot of things to read and learn; I'll try to apply all your advices.
I'll post my, hopefully better, situation when I reach a significant improvement.

Everything you upload to OpenGL via glBufferData will be pretty certainly committed to video memory.
When you don't want something to be stored on the graphics card, decommit the memory of the buffer object via:

Code: [Select]

glBindBuffer(GL_ARRAY_BUFFER, bufferId);
glBufferData(GL_ARRAY_BUFFER, 0, GL_STATIC_DRAW);
and possibly delete the buffer object's name via glDeleteBuffers(). But you don't need to do that, because you could recommit memory to it later on.

Then later, when some chunk is about to become visible, you recommit the data again to the buffer object via another call to glBufferData(), but now with the actual data.

However, an even better way would be to ask yourself why you need this rediculuous precision everywhere in the terrain, and whether you can employ some LOD mechanism to reduce the number of vertices. For example: if your terrain has medium/large areas of constant first order derivatives (i.e. its slope does not change), you can make a single triangle/quad out of that area.
Another example would be view-dependent LOD, in which you constantly adapt the tessellation of the terrain based on the distance to the viewer. One practical example of this is "Chunked Lod".
This will in the end save you the most memory and will massively improve rendering performance.

Have a look at this: http://vterrain.org/LOD/Papers/