stb_truetype - reimplementing PackFontRanges to split across multiple textures

[philipguin]

Hey there,

I'd like to reimplement PackFontRanges to accept a max_texture_size, then allocate multiple textures beneath that size until all requested glyphs are packed. However, there are some challenges:

1. Determining the smallest power-of-two texture size needed to contain a set of glyphs.
2. Trying to account for glyphs that have already been packed and ignoring them in successive calls (working backward from stbrp_rect::is_packed).
3. Swapping out the underlying pixel buffer between calls to PackFontRangesPackRects and PackFontRangesRenderIntoRects.
4. Reporting the assigned texture correctly on a per-glyph basis.

With significant work I could probably overcome these, but I was wondering if there was a better approach than what I've outlined? Perhaps something more explicitly supported by stb_truetype? Otherwise, any tips on the above challenges? Thanks.

[nothings]

PackFontRanges already takes a max texture size, specified in PackBegin (width & height).

All you have to do is change the code in the "else" clause inside the loop, currently line 4283, which handles the case where a character wasn't packed, and have that set a flag value into the return value for this character. That's the variable 'bc' in the main if clause, which you'd need to copy the definition of into this clause. Then maybe set bc->x0,y0,x1,y1 to -1, which isn't ever valid, ot add a new 'was_packed' field.

Now, when you call PackFontRanges, you can find out which characters weren't packed by checking for those -1 values, and recompute a new set of pack ranges, and call PackFontRanges again, repeat. If you use the built in packer, I believe these will still be in dense runs because the built-in packer traverses the characters in order, so it will have just packed the first N characters. But if you use stb_rect_pack, the final result will be sparse, so you'll want to switch to specifying sparse ranges using array of unicode_codepoints.

The only limitation of this is that the packer will stop trying to pack as soon as the first character fails, instead of trying to pack as much as possible in. It's possible to try to hack on the packer to change this, but I wouldn't recommend it; I believe it requires totally different packing strategies to do well. Most of the time it'll still require the same total number of textures whether you pack the extra bits in or not.

[philipguin]

Thanks for your time!

PackFontRanges already takes a max texture size, specified in PackBegin (width & height).

But this is a static size, at least from my testing. What I'm hoping for is the equivalent of attempting to fill the tiniest texture possible that's a power of two, then going up a power if that fails, then again, etc, up until the requested max_texture_size, after which I would just split into a new texture. This is basically for texture atlasing with a big OpenGL 2D texture array. I suppose I could just use the rects' sum total area as initial, conservative guess for size.

All you have to do is change the code...

Unfortunately I'm using the library in Kotlin via LWJGL, which means I can't (easily) make changes at such a fine level. (Would be nice!) The rectangles are still marked, however, and appear to always be in order of stbtt_pack_range? If so, I can just work backwards by iterating over ranges in exactly the same fashion as when the rects are generated, including the if checks, then writing out my own per-glyph is_packed array from the rects. Main problem is it'd be brittle.

But how would you feel about setting the coordinates or a new flag as a pull request? Or for compatibility's sake, a new method that basically does what I just described. Would let people more generally handle "overflow" without scratching their heads too much :)

Side note: at line 4281, ranges[i].chardata_for_range[missing_glyph];, using i here looks like a bug? E.g. if missing_glyph is found on a different i.

Now, when you call PackFontRanges...

I've been relying on the range version, but LWJGL appears to include stb_rect_pack.h, so I will probably need to go with array_of_unicode_codepoints. My current glyph set is pretty sparse anyway. If I end up supporting 1000+ CJK glyphs, however, it could make sense to use both by re-detecting ranges.

The only limitation of this is that the packer will stop trying to pack as soon as the first character fails...

I think this will be alright - if stb_pack_rects.h is already resorting by size, then it'll probably be rare that it matters. And with the minimal texture thing above, even spilling one character over shouldn't be too bad.

[nothings]

You can address the max_texture_size thing by just looping and calling PackFontRanges with the same input and successively larger textures until it succeeds, or even binary search the power of 2 if you want. Slower than ideal but cleaner than changing the code internally.

A PR that adds a flag or sets the values to -1 would be accepted.