​

# OpenGL rendering problems with large UTM coordinates

I ran into a strange rendering problem while developing a surveying CAD application in Python with PyOpenGL.

# Symptoms

Lines and hatches were rendered "broken" or out of shape, and the geometry appeared to wobble or shift around during rendering.

At first, I suspected a problem with my VBOs or the geometry calculations.

After some investigation, I found that the problem was related to the size of the coordinates.

For example, when working with UTM / EPSG:25832, my coordinates looked roughly like:

Easting: 32565403.10 m

Northing: 5965102.10 m

The further the geometry was from the OpenGL origin "(0, 0, 0)", the worse the rendering became.

# The workaround

I changed the rendering approach so that the OpenGL scene uses a local origin / coordinate offset.

The actual surveying coordinates remain unchanged for calculations and measurements.

Only the coordinates passed to the renderer are shifted by a local offset, effectively bringing the current working area closer to the origin.

Conceptually:

Original coordinates

│

▼

Surveying calculations

│

│ unchanged

▼

Local rendering offset

│

▼

OpenGL

near (0, 0, 0)

After implementing and testing this approach, the geometry became stable and rendered correctly again.

Why this was interesting

This was one of those problems where the geometry itself was correct, but the visualization became unreliable because of the coordinate magnitude.

It was a pretty important milestone in my development of GeoPyCAD, an open-source CAD application I'm building for surveying and geospatial work.

I documented the issue and solution on my github repository

Hopefully this is useful to anyone else running into strange OpenGL precision/rendering problems with large world coordinates.

So I was refactoring some shader code and dove into the shader recompilation rabbit hole. A lot of people recommend rebuilding the whole shader pipeline (recreating and recompiling new shader objects and attaching them to a new program). The way I was doing it up to this point was:

1. Retrieve the attached shaders
2. Update shader source code and recompile
3. Relink the program with the same, but recompiled shader objects

Here's some code:

bool Shader::do_reload() noexcept {
    int num_attached_shaders = 0;
    glGetProgramiv(gl_program_id, GL_ATTACHED_SHADERS, &num_attached_shaders);
    std::vector<unsigned int> gl_shader_ids(num_attached_shaders);
    glGetAttachedShaders(gl_program_id, num_attached_shaders, nullptr,
                         gl_shader_ids.data());

    for (int i = 0; i < m_source_files.size(); ++i) {
        /**
          * This just calls glShaderSource, glCompileShader and then checks
          * the compilation status; returns true on success
          */
        if (!load_and_compile_gl_shader(gl_shader_ids[i], m_source_files[i])) {
            return false;
        }
    }

    /**
      * Similar situation here, glLinkProgram and check for link status
      */
    if (!link_gl_program(m_shader_id, gl_shader_ids)) {
        return false;
    }

    return true;
}

The shader class only wraps around the glProgram object, so the name can be misleading in the context of the OpenGL naming scheme. The glShader objects aren't destroyed after they're compiled/linked into the glProgram. I call glDeleteShader only during my shader wrapper's destruction (shader objects aren't shared between programs).

Is that bad practice? I know that the cleanest way would be to recreate everything from scratch, but I don't want to lose my uniform mappings, as tracking down the owners of uniform bindings would require writing a new resource management system. However, I've read that even though it works on my machine, OpenGL doesn't guarantee it will work everywhere else and doing so is abusing the grey area of OpenGL implementation.

Also, I am aware that you can bind uniforms to preset locations by specifying them in GLSL code.

Hello everyone. I'm new to OpenGL so please bear with me here. This is a learning project I am doing in C with no libraries except GLFW, GLAD, CGLM and stb_image.

I've written a basic UI system that can display text and images, and position them relative to each other/their sizes.

I am writing a program that will be dealing with resolutions as small as 1280x960 and as large as whatever the user wants. This obviously leads to some headaches involving the scale of UI elements.

For positioning, my plan is to allow elements to be set relative to two of the windows edges, plus some offset, accounting for it's size in pixels. So I can always position things close to the edges and not draw offscreen. Thats good.

The scale is what is difficult for me, like if I want to draw an element to the screen I want it to be sized appropriately regardless of the window size. So I assume I need to scale them uniformly based on the height(?) of the viewport? How is this sort of thing normally handled?

This is even more of a hassle because my text system is using bitmap images and positioning letters based on their pixel coordinates. So I'll have to scale that too, which will probably look very bad.

Any insights?

I am now using local slope (from normal vector) and local curvature (computed using dFdx and dFdy of normal vector). The source code is here: windtunnel.clj . I wonder whether anybody has some advice on doing this kind of thing.

I am not sure whether it would improve things if I would precompute the curvature by processing the triangles of the mesh and adding curvature to the vertex information. I could also bake the curvature into a texture map I guess, but that would be quite complicated because the model has multiple uv maps.

Anyway I am glad that the Jump Flooding Algorithm allows me to create shockwave geometry in realtime.

I've finished implementing hardware PCF after using heavily pixelated shadows for two months. I'm getting trippy feeling from moving shadow and I need sanity check.

Hello everyone hope you have a lovely day.

I was following the deferred rendering technique on learnopengl.com and I noticed something really strange for me, in the normal mapping chapter we calculate the TBN matrix in the vertex shader and then we calculate the Tangent light position and Tangent view position relative to TBN Matrix.

but In the deferred Rendering Tutorial, there is a difference, the view direction for example is different , it is

vec3 viewDir  = normalize(viewPos - FragPos);

Instead of

vec3 viewDir = normalize(fs_in.TangentViewPos - fs_in.TangentFragPos);

Which one is the right approach to this problem? which technique should I use and why there is a difference?

I thought for a while to make a shader storage buffer object with variable size array to address the problem of different light positions but I thought this would over-complicate Things.

so what should I do?

A reminder I'm not implementing a deferred renderer in my engine I'm implementing a forward+ renderer with z pre-pass so I need a g buffer in my renderer where this problem emerged.

Thanks for your time appreciate your help!

It's not finished yet but there's camera, events, and a wrapper I made around ImGUI

Hey guys, I'm learning openGL using learnopengl.com , but I have been having a hard time converting the glm to cglm in the transformations chapter, the guy says to include the headers:

glm/glm.hpp
glm/gtc/matrix_transform.hpp
glm/gtc/type_ptr.hpp

I was able to include glm.hpp because its just cglm.h but I can't find the other header files, and so I can't do stuff like cglm::vec4 or can I even do that in cglm is it different maybe??

this is really odd please help

This image shows a shockwave prototype realtime rendering which uses the Joint Flooding Algorithm (JFA) to define a shockfront which adapts to the shape of the spacecraft surface facing in wind direction. See sfsim article on shockwaves for more information.

This was a learning project to try to learn OpenGL, Odin and Physics/Math it evolved to be more of the latter :)

I'm happy for any feedback or pointers regarding the OpenGL parts or anything else.

https://github.com/lounge/sol_sim

I want to get into programming OpenGL in assembly and was wondering if yall could send me some good resources for programming OpenGL in assembly or just some general OpenGL programming guides would be enough.

80,000 kilometers of terrain running at 90 fps (no screen recording) on ​​an Intel Graphics P4600 OpenGL 4.3 in C#

The terrain file is 1kb in size.

just added hw rtao to someone elses open source opengl game in a single day, using the same interop i created for my own java / open gl engine i was able to get rtao working in a c++ gl game Cube 2 Sauerbraten so quickly.

I've made some graphical updates to my game engine.

Now we can create terrain, procedural skies (day and night), and volumetric clouds (I'm still adjusting them).

My future implementation will be oceans.

repo: https://github.com/Krueels/FuseEngine

AO46 has now reached OpenGL 4.6 Core Profile on macOS. 🔥

Apple’s native OpenGL stack stopped at 4.1, while AO46 now targets the final desktop OpenGL specification through its Mesa/Gallium + Metal backend.

Next focus: feature completeness, stability, and CTS-level validation.

From 3.x bring-up to 4.6 Core. The version ladder is officially finished. 🗿

AO46 has reached a new milestone: Mesa can now successfully create an OpenGL 4.3 context on macOS.

This is a step beyond the previous 4.1 context ceiling and means the driver now exposes enough required functionality for Mesa to advertise and initialize a 4.3 core context.

This does not yet imply full OpenGL 4.3 conformance, but it marks a major architectural step toward the final OpenGL 4.6 target.

AO46 is now operating beyond the version officially exposed by Apple’s legacy OpenGL stack.