Use a texture array (3D texture) for the imgui's atlas

[nekitu]

I am hitting some limitations of the atlas generation from multiple fonts, especially I want to have icon fonts, so those glyph are pretty large.
Do you have planned or thought about using a texture array, many slices, and you keep on adding slices when the is no room in the atlas predefined size (lets say 4k x 4k), this way you can add layers as you go, when an atlas slice is filled up.
On render, just bind that texture array and you can add a slice index to the vertex info.
I am using this technique in my imgui library HorusUI and it works great, no worries of chinese/icon ranges not fitting in, virtually if the the card is holding 256 slices of a 4k texture, then awesome :), but of course you can check and have a limitation of N slices max.

[ocornut]

Hello,

I am hitting some limitations of the atlas generation from multiple fonts, especially I want to have icon fonts, so those glyph are pretty large.

Current default is x3 oversampling on X axis which tbh can be overkill (compared to x2). Also using FreeType tends to give better result without any oversampling. So those are some ways to alleviate that.

Linking to #3198 and #2489 which are somehow related. Also #3471 uses multiple textures (but no texture array).

While I understand your issue I don't think we realistically investigate this before we put serious work on a new font system, and at that point there'll be less need for it. But still possible of course: we would have to make it optional, and there will be some complication in backends, but being optional we can step it up over time.

I see your code is using a texture index, whereas #2489 suggest using a third UV coordinates, and wondered if you are aware of the differences between those two approaches and how they map to graphics API and GPUs?

[nekitu]

Frankly I don't know, I chose an index because it felt more logical, as a slice index, for each vertex. I haven't tested any speed differences in the type chosen.

[nekitu]

And I didn't want to transport more than I needed in the vertex layout. The less the better on upload.

[nekitu]

btw, where can I find info about a future font system, and how would it eliminate the need for an atlas, unless dynamic rendering of glyphs

[ocornut]

It would dynamically render glyphs into the atlas.

[nekitu]

I am probably doing the same or sorts. When a glyph codepoint is not already in the atlas and it is requested through text rendering, I am quickly caching/rasterizing it in the atlas, by default you can add the ranges you want anyway to be prebaked, but in case of chinese text, they can be dynamically added. Also when font sizes changes, the atlas is regenerated. I dont use SDFs or other tricks, just raw big glyphs, but I think SDFs might help, I havent implemented them because of speed concerns, I havent checked how fast is their computation nowadays.