not working

[vautieri]

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];

[azsn]

Hi! I'm currently developing on Mac, so AMD GPU. I've never tried it on Windows. It's definitely possible I've stumbled across undefined / non-conformant behavior. And because I'm on Mac, my OpenGL version is very old (GL Version: 4.1 ATI-2.11.23) because Apple is dumb. I don't own a physical Windows machine, but I'll see if I can setup the environment and run this in a Windows VM and reproduce the problem. Then I'll try to debug it.

The gridAtlas.bmp that's written to disk should appear nearly solid black in most cases -- the values written are normally very low numbers. bezierAtlas.bmp should be partially solid black but with a bunch of noise at the bottom. Here are my bmps from right when the program opens (before typing anything new) when running directly from the latest commit on master, although I had to convert them to a JPG because github doesn't like bmps, so they're compressed/changed a slightly

gridAtlas.bmp (not actually solid black, zoom in near the bottom)

bezierAtlas.bmp

I'd expect your atlases to match these, because the logic which generates the atlases doesn't depend on OpenGL at all. So if your atlases don't match, that's very strange. But otherwise, it's likely to be some shader or OpenGL configuration mistake.

[vautieri]

Thanks for the response. Yeah, the atlas looks the same. I started thinking it was the texture buffer object not making its way to the GPU. If I change the percent for the alpha output to something like .1 (your variable at the top of the fragment shader), I can see where the text is supposed to go (I see the solid blocks). I tried using the integrated GPU (intel), as well as the nvidia geforce, and even a quadro and I don't see anything. They all have recent drivers. I do believe everything is working on the CPU side, as if I set your nodata variable o something like 64, I can see the characters showing up on the textures/atlas(s) on disk.. so I feel confident your glyph and grid alas(s) are being built just fine.. simply acts like the intersections that are suppose to be happening on the GPU are simply not happening, and I am not sure of a good way yet to debug it. All the best, V

…

On Thu, Feb 25, 2021 at 6:33 PM Aury ***@***.***> wrote: Hi! I'm currently developing on Mac, so AMD GPU. I've never tried it on Windows. It's definitely possible I've stumbled across undefined / non-conformant behavior. And because I'm on Mac, my OpenGL version is very old (GL Version: 4.1 ATI-2.11.23) because Apple is dumb. I don't own a physical Windows machine, but I'll see if I can setup the environment and run this in a Windows VM and reproduce the problem. Then I'll try to debug it. The gridAtlas.bmp that's written to disk should appear nearly solid black in most cases -- the values written are normally very low numbers. bezierAtlas.bmp should be partially solid black but with a bunch of noise at the bottom. Here are my bmps from right when the program opens (before typing anything new) when running directly from the latest commit on master, although I had to convert them to a JPG because github doesn't like bmps, so they're compressed/changed a slightly gridAtlas.bmp (not actually solid black, zoom in near the bottom) [image: gridAtlas] <https://user-images.githubusercontent.com/7142049/109232732-c347e280-7796-11eb-850a-2ca5eca87195.jpg> bezierAtlas.bmp [image: bezierAtlas] <https://user-images.githubusercontent.com/7142049/109232759-ce9b0e00-7796-11eb-88e5-205be0a98ec3.jpg> I'd expect your atlases to match these, because the logic which generates the atlases doesn't depend on OpenGL at all. So if your atlases don't match, that's very strange. But otherwise, it's likely to be some shader or OpenGL configuration mistake. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHWHGXWVE7REAJFINJPR7CLTA3M3XANCNFSM4YBUBQ7A> .

-- *Vincent Autieri* Vice President Co-Founder, Geoweb3d Inc. 607-731-3904 | vautieri@gmail.com | autierifamily.com <https://autierifamily.com:5011/>

[azsn]

Okay, good to know those parts are working at least. And yeah, debugging fragment shader issues is hard. It will probably be a while before I have time to try to reproduce and debug this myself. If you want to try to debug this more yourself, I think there are some good tools for debugging the OpenGL rendering pipeline. I've never used any of them, but one of the other people who helped me on this project was using a program called "renderdoc" which looked neat. Maybe give it a try?

[azsn]

Hey @vautieri , I just merged #23 by @Confucius19 which fixed a bug with the data vData attribute on some hardware. This might be the problem you were experiencing; with this bug, the glyph quads would still be in the right position (hence them showing up when you set a fixed alpha value) but would be invisible because all the glyph data is corrupted. Update to the latest commit and try again, let me know if it works for you now! Thanks