azsn / gllabel Goto Github PK

• 翻 of NotoSansCJKjp-Regular: Made of ~100 beziers, which is currently too many. Maximum is floor( ((bezier atlas width)-2) / 3 ) (currently 84) because all the beziers for one glyph must be in one row of the atlas. This can be solved by using a one dimensional buffer (e.g. Buffer Texture backed by a Shader Storage Buffer Object) instead of a 2D texture acting as a data buffer for the bezier atlas. [Fixed in 6aa072d by using buffer textures which removes this 84-beziers limit.] [This glyph still doesn't render completely right due to detail density, but that's covered in another bullet below].

• Any character in a font which uses cubic beziers. (A known offender is NotoSansCJKjp-Regular.) The algorithm as-is cannot handle cubic beziers, and although it could be made to handle them, it would require finding 3rd order polynomial roots in the fragment shader. So probably a better solution is to convert the cubics to quadratics up to some resolution limit before generating the atlases. [Fixed in 4cc6d9f by converting cubics to quadratics during the outline decompose phase.]

• ç, Ç of LiberationSans-Regular: The intersection between the c and the ¸ renders corrupted. Not yet sure why. Based on how the corruption looks, I suspect it's related to the cell midpoint-inside detection algorithm (GridGlyph.cpp find_cells_mids_inside()).

• Any glyph which requires over 254 beziers. Any of a glyph's beziers must be able to be referenced by one byte in the grid atlas, minus two values for storing metadata. I have yet to see any glyph even coming close to 254 beziers, so I don't think this a big problem. Could solve by splitting up single glyphs into multiple rendered glyphs, e.g. 4 quadrants each getting ~1/4th the beziers (might have some overlap).

• Any glyph which is too dense in detail and has regions which break the "4 beziers per grid cell" limit at the current fixed grid size of 20x20. Examples: 翻. Making the grid size larger fixes this problem for most glyphs, but increases memory usage for the glyphs that do not need it. Also, at large grid sizes, glyph rendering breaks down for unknown reasons (all characters, not just this one). One solution would be a variable sized grids (perhaps packed into one atlas or separated into multiple based on grid size). Will Dobbie's original solution was to have two grids, a 2nd as an "extra" which means up to 8 beziers are allowed per grid cell. This might be able to be generalized to any number of grids per glyph, adding more as needed (e.g. using 3D textures).

(To be continued as more are discovered.)

Move to its own file and/or class?

https://hacktoberfest.digitalocean.com/hacktoberfest-update
Because some idiots created spammy pull requests to get a T-shirt, they made the whole event opt-in for maintainers. So if you want to participate, you should add the hacktoberfest topic to the repo, and maybe someone will contribute.

Inside label.cpp I added:
GlyphVertex v[6]; // Insertion code depends on v[0] equaling appendOffset (therefore it is also set before continue;s above)
v[0].pos = glm::vec2(0, 0); //new

So I'm making a branch that uses CMake, and I'm trying to make a well thought-out structure for the project there. One thing I need is some naming convention, for example the casing of filenames, { on newline? etc.. Right now it seems really mixed. Maybe make a CONTRIBUTING.md?

I'm getting a Debug assertion failed: vector subscript out of range.
For some reason I can't find out where it is coming from.
I made a self-contained fork of your project, with the following changes

• GLEW to GLAD
• Make to CMake (a lot better, do cd build, cmake .. and cmake --build .
• I disabled the forward compatibility window hint so the shader code would work
• Using my own fonts, my loadTTF() renders them to the terminal to make sure that my code isnt at fault
• added 2 casts to double so it would compile

https://github.com/discapes/gllabel

Also it said something about "MORE THAN 4 on 112"

tryna fix...

Tried it, nothing shows up. I am using nvidia hardware, also tried intel hardware. If I take the fragment shader and start with something higher than 0, I do see the blocks where the text is suppose to be (escape also rotates...). the glyph atlas looks like its working. the other atlas I don't think is working or making its way into she shader??? just a hunch assuming this code is suppose to work. if I take the nodata (0) and change it to something like 4, I do see the numbers in the bitmap saved to disk, so I believe the buffer on the cpu is getting created. IF I leave it at 0, it looks like its an all black texture on the CPU ( I didn't look at every single pixel at 1:1 resolution).

I have a hunch something is going on here with uGridAtlas.. without getting deep into the code .. I am developing on windows, I have a hunch you might be linux.. don't think that matters unless you were getting away with a non conformity with the opengl driver you were using??? (again, could be 1000% wrong, but I am assuming the code you have is suppose to work, so other than a GPU issue, what else would it be)

ivec4 indices1 = ivec4(texelFetch(uGridAtlas, indicesCoord, 0) * 255.0);

// The mid-inside flag is encoded by the order of the beziers indices.
// See write_vgrid_cell_to_buffer() for details.
bool midInside = indices1[0] > indices1[1];

I believe this happens when more than 4 bezier curves in a glyph intersect one grid cell. When the glyph is too dense with detail for this algorithm (as currently implemented) to handle, and so that character might render slightly corrupted. The easy fix is to just to make the grid atlas have a higher resolution, but that wastes space for all the glyphs that don't need it. Perhaps a nice solution could be complex glyphs get their own, higher resolution atlas. Not sure offhand what changes that would require in the fragment shader, though.

label.cpp seems to call clamp() with incorrect type parameters. Those can be fixed with a simple cast, I can PR that...

As of commit cc1d694, grid sizes 37x37 and above cause the program to immediately crash with the message:

Assertion failed: ((atY + grid.height) <= this->height), function WriteVGridAt, file lib/vgrid.cpp, line 221.

This took me way too long to figure out as I am a Lisp guy and naturally despise makefiles and such... The makefile fails with a shid of 'undefined reference' errors from ld. But moving cpp files forward makes it work on my linux box...
g++ -Wall -g -o demo demo.cpp label.cpp -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/GLFW -I/usr/include/GL -lGLEW -lGLU -lGL -lglfw -lfreetype

Pango seems like it could work. It might be able to replace the FreeType dependency for font loading too, I'm not sure. HarfBuzz is probably not sufficient on its own because it just does shaping -- no line breaks, bidirectional text, justification, etc.

I'm thinking this should look like a class or some functions which take in some text with formatting (e.g. Pango markup) and returns an array of rectangles specifying the location where each glyph should be placed. (The rectangles could then be converted to triangle verts and sent off to the graphics card.)

I made a branch that uses CMake (cross platform) and GLAD, a more modern alternative to GLEW. It has the includes in a separate folder, for the convenience of library users. It also follows the convention that users of the library do lib/file, (here gllabel/label.hpp, just like other libraries (glm/vec2.hpp, GLFW/glfw3.h, glad/glad.h)). The libary source code itself can refer to just <label.hpp> for the sake of less typing (that can be easily changed though). I also made simple build instructions in README.md, and a small script to run them all. I have also set the code up to bake the fonts right into the executable using a CMake script (CMakeRC), so the executable can be run everywhere. It really doesn't take much more than ~FT_New_Memory_Face(cmrc::fonts.open("Sans-Regular.tff), ...). So I thought you might wanna make a CMake branch for users who prefer to use that, I could PR there...

I'm trying to understand how the library works, thanks a lot for making comments.
So what I have gathered, each grid cell is 1 pixel, which is 4 bytes. The index of a bezier is represented by one byte, so per grid cell, there can be 4 beziers. As said in this comment in vgrid.hpp:

Bytes per pixel, aka. how many bezier curves are allowed per grid
cell. This should probably always be 4, since that's the limit of
bytes per pixel that OpenGL supports (GL_RGBA8).
uint8_t depth;

Then in vgrid.cpp there's this comment:

Each grid cell is represented as one byte in the atlas, and values 0 and 1
are reserved for special meaning. This leaves a limit of 254 beziers per
grid/glyph.

Shouldn't that be "Each bezier index is represented as one byte in the grid cell, ...", because each grid cell is represented as 1 pixel?