[POC] Replace GLUT with Raylib

[michalpelka]

To say that HDMapping use legacy method to draw is to say nothing.

multi_view_tls_registration (step2) was still running on GLUT plus immediate-mode OpenGL straight out of the 90s — glBegin/glVertex, gluPerspective, gluUnProject, raster-position bitmap fonts, the lot. This PR moves it to raylib, in place, keeping the app's existing structure (globals, function
names, control flow) as close to the original as swapping the rendering backend allows.

#What changed

• multi_view_tls_registration_gui.cpp now runs on raylib instead of GLUT + legacy GL. The camera/picking/mini-compass/misc-widget code it used to pull from the shared core/src/utils.cpp (still used by several other GLUT apps, so it couldn't be touched) is now a local reimplementation in the app's
  own rl_utils.cpp/rl_utils.h, built on rlgl's legacy-GL-emulation API (a software matrix stack + immediate-mode layer) instead of real gl*/glu*/glut* calls.
• Point-cloud and loop-closure rendering — previously core's shared legacy-GL PointCloud::render()/PointClouds::render()/ManualPoseGraphLoopClosure::Render() — now goes through a new core_raylib target (Core/raylib_render.hpp's ScanRenderer): a real GPU shader-based point renderer.
• New, not something the legacy renderer could do: per-point jet-colormap coloring by intensity, height, or distance from the rotation center (View > Point cloud).
• Pose/edge index labels are back in the loop-closure overlay, projected to screen space by hand since there's no glutBitmapString equivalent under a core GL profile.

Porting was done with Sonnet 5 with Claude Code.

New dependencies and licensing

Two new third-party deps come in via cmake/raylib.cmake (FetchContent): raylib and rlImGui, both zlib-licensed — same permissive family as this project's MIT license, no new licensing friction. Dear ImGui itself isn't duplicated: imgui_raylib builds from the same already-vendored 3rdparty/imgui tree
the GLUT apps' imgui target uses (it's on the docking branch, which ShowMainDockSpace() needs), just without the GLUT/OpenGL2 backend files.

Strucutre

Raylib has thin abstraction for OpenGL, that is very handy in this project. It introduce intermediate mode, emulates old GL2 mechanism making conversion quite simple.

The split deliberately mirrors the project's existing architecture rather than inventing a new one:

• rl_utils.cpp/rl_utils.h plays the same role for this app that core/src/utils.cpp/Core/utils.hpp plays for the GLUT apps — same function names, same "shared camera/picking/widget glue, separate from the app's own main file" split.
• core_raylib sits alongside core/core_no_gui as a third target, the same way the project already splits GUI/no-GUI builds — gated behind whether raylib is actually needed, not linked into anything that doesn't use it.

Anyone already familiar with the GLUT apps' structure should find this one recognizable, not foreign.

Pictures

What to do next

It is not ready to be merged - the code is AI slop. But working prototype with managable diff.
I would like to continue, but I need to:

• create test scenarios for manual testing (based on Janusz's videos on yt)
• check current main for regression
• check / fix all bugs introduced by this refactor
• fix CI errors / deployments on all platforms

[michalpelka]

Here is good example why Raylib is great choice:

[mwlasiuk]

Nice. I would suggest to display GL_RENDERER string in the app bar. Although RAYLib prints it some people might not look at the console output at all and this string is helpfull especially on systems with multiple GPU as OpenGL uses some default GPU and might choose iGPU instead of dGPU.

Just debug thing to let the user know that they shoul probably set their OpenGL default renderer to high performace card in system settings.

[michalpelka]

good idea @mwlasiuk added:

Also I've tested Windows build.
I also added legacy version

[michalpelka]

Janusz tested macOS. It runs but draws incorectly. We need to address it

[michalpelka]

Fixed control points, gnss and ground control points.