Skybox renders with magenta tint when run after PBR example (v0.9.1 regression)

[graphnode]

When running examples sequentially in the same process, the skybox renders with a magenta tint if the PBR example runs first. This is a regression introduced in r3d v0.9.1, it did not occur with v0.9.0.

Steps to Reproduce

1. Build and run with r3d v0.9.1 bindings
2. Run: Examples.exe Pbr Skybox
3. Close the PBR window normally (press Escape/close)
4. Observe the Skybox example opens with a magenta tint

Expected Behavior

The Skybox example should render identically regardless of whether it runs standalone or after another example.

Actual Behavior

The skybox and scene have a magenta color cast when the Skybox example follows the PBR example.

What doesn't trigger the bug

• Running Examples.exe Skybox alone — works fine
• Running Examples.exe Skybox Pbr (reversed order) — works fine

Investigation

Each example performs a full lifecycle (InitWindow → R3D_Init → game loop → R3D_Close → CloseWindow), so the OpenGL context is destroyed and recreated between examples. Despite this, some internal r3d state appears to leak across the Close/Init cycle.

The v0.9.1 release introduced a UBO/sampler binding cache and a shader alias system (r3d_shader_custom_t refactor with program/programOwner split). We suspect the binding cache or related GL state tracking becomes stale when r3d is reinitialized within the same process, causing incorrect texture bindings that manifest as magenta (missing texture fallback color).

Removing the UBO binding cache (uniformBindings guard in r3d_shader_set_uniform_block/r3d_shader_bind_uniform_block) did not resolve the issue, so the root cause may be in the sampler binding cache or another part of the shader module refactor.

Environment

• OS: Windows 11
• r3d version: v0.9.1
• Bindings: R3D-cs (C#/.NET)
• Last working version: v0.9.0

[graphnode]

Workaround: spawn a separate process per example

After investigating more deeply the r3d and raylib internals, the root cause is possibly that raylib's internal rlglData static struct is never fully zeroed between CloseWindow()/InitWindow() cycles, rlglInit() only overwrites specific fields, leaving stale GL state (texture bindings, shader IDs) from the previous context. The v0.9.1 release added sampler/UBO binding caches in r3d that assume clean GL state, and these caches interact badly with the stale rlgl data when r3d is reinitialized in the same process.

Upstream r3d examples each run as separate executables, so this code path was never exercised or tested upstream.

The fix: when running multiple examples, the runner now spawns a child process per example instead of calling them in-process. Each process gets its own fresh rlgl/r3d state. Single-example runs still execute in-process with zero overhead.

var exe = Environment.ProcessPath!;
foreach (var example in examples)
{
    var process = Process.Start(new ProcessStartInfo(exe, example.Name)
    {
        UseShellExecute = false
    })!;
    process.WaitForExit();
}

This sidesteps the issue entirely without touching any example code or the upstream library but doesn't solve the bug.