Anatomie d'une frame : le cycle de vie complet de suckless-ogl

De main() aux photons sur l'écran — une plongée complète dans un moteur PBR OpenGL moderne écrit en C.

Introduction

suckless-ogl est un moteur de rendu PBR (Physically-Based Rendering) minimaliste et performant, écrit en C11 avec OpenGL 4.4 Core Profile. Il affiche une grille de 100 sphères aux matériaux variés (métaux, diélectriques, peintures, organiques…) éclairées par Image-Based Lighting (IBL), avec un pipeline de post-processing complet : bloom, depth of field, motion blur, FXAA, tone mapping, color grading…

Cet article retrace le cycle de vie complet de l'application : depuis le premier octet alloué dans main() jusqu'au moment où le GPU présente la première frame complètement éclairée à l'écran. On va traverser chaque couche — mémoire CPU, ressources GPU, la poignée de main X11/GLFW, la création du contexte OpenGL, la compilation des shaders, le chargement asynchrone de textures, et l'architecture de rendu multi-pass qui produit chaque frame.

Ce qu'on va couvrir

Chapitre 1 — Le point d'entrée

Tout commence dans main() (src/main.c) :

int main(int argc, char* argv[])
{
    tracy_manager_init_global();          // 1. Bootstrap du profiler

    CliAction action = cli_handle_args(argc, argv);  // 2. Parsing CLI
    if (action == CLI_ACTION_EXIT_SUCCESS) return EXIT_SUCCESS;
    if (action == CLI_ACTION_EXIT_FAILURE) return EXIT_FAILURE;

    // 3. Allocation SIMD-aligned de la structure App
    App* app = (App*)platform_aligned_alloc(sizeof(App), SIMD_ALIGNMENT);
    *app = (App){0};

    // 4. Initialisation complète
    if (!app_init(app, WINDOW_WIDTH, WINDOW_HEIGHT, "Icosphere Phong"))
        { app_cleanup(app); platform_aligned_free(app); return EXIT_FAILURE; }

    // 5. Boucle principale
    app_run(app);

    // 6. Nettoyage
    app_cleanup(app);
    platform_aligned_free(app);
    return EXIT_SUCCESS;
}

Le design est volontairement simple — toute la complexité est encapsulée dans app_init() → app_run() → app_cleanup().

Décisions de design

graph TD
    A("🚀 main()") --> B("app_init()")
    B --> B1("Fenêtre + Contexte OpenGL")
    B --> B2("Caméra & Entrées")
    B --> B3("Scène — Ressources GPU")
    B --> B4("Thread de chargement async")
    B --> B5("Pipeline Post-Processing")
    B --> B6("Systèmes de profiling")
    B1 & B2 & B3 & B4 & B5 & B6 --> C("app_run() — Boucle principale")
    C --> C1("Poll Events")
    C1 --> C2("Physique caméra")
    C2 --> C3("renderer_draw_frame()")
    C3 --> C4("SwapBuffers")
    C4 -->|"frame suivante"| C1
    C --> D("app_cleanup()")
    D --> E("🏁 Fin")

    classDef entryExit fill:#fce4ec,stroke:#c2185b,stroke-width:2.5px,color:#2d2d2d
    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef subsystem fill:#ffffff,stroke:#aaaaaa,stroke-width:1.5px,color:#444444
    classDef loopNode fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d

    class A,E entryExit
    class B,C,D keyFunc
    class B1,B2,B3,B4,B5,B6 subsystem
    class C1,C2,C3,C4 loopNode

Chapitre 2 — Ouvrir une fenêtre (GLFW + X11 + OpenGL)

Le premier vrai travail se fait dans window_create() (src/window.c).

2.1 — Initialisation GLFW et Window Hints

glfwInit();
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 4);          // OpenGL 4.4
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_OPENGL_DEBUG_CONTEXT, GL_TRUE);     // Messages de debug
glfwWindowHint(GLFW_SAMPLES, DEFAULT_SAMPLES);           // MSAA = 1 (désactivé)

En coulisses, GLFW effectue un handshake X11 complet :

sequenceDiagram
    participant App as Application
    participant GLFW as GLFW
    participant X11 as Serveur X11
    participant Mesa as Mesa/Driver GPU
    participant GPU as GPU

    App->>GLFW: glfwInit()
    GLFW->>X11: XOpenDisplay()
    X11-->>GLFW: Display* (connexion)

    App->>GLFW: glfwCreateWindow(1920, 1080)
    GLFW->>X11: XCreateWindow() + GLX setup
    X11->>Mesa: glXCreateContextAttribsARB(4.4 Core, Debug)
    Mesa->>GPU: Allocation command buffer + état contexte
    Mesa-->>X11: GLXContext
    X11-->>GLFW: Fenêtre + Contexte prêts

    App->>GLFW: glfwMakeContextCurrent()
    GLFW->>Mesa: glXMakeCurrent()
    Mesa->>GPU: Bind du contexte au thread appelant

2.2 — GLAD : chargement des pointeurs de fonctions OpenGL

gladLoadGLLoader((GLADloadproc)glfwGetProcAddress);

OpenGL n'est pas une bibliothèque au sens classique — c'est une spécification. Les adresses réelles des fonctions vivent dans le driver GPU (Mesa, NVIDIA, AMD). GLAD interroge chaque adresse à l'exécution via glXGetProcAddress et remplit une table de pointeurs de fonctions. Après cet appel, glCreateShader, glDispatchCompute, etc. deviennent utilisables.

2.3 — Contexte debug OpenGL

setup_opengl_debug();

Cela active GL_DEBUG_OUTPUT_SYNCHRONOUS et enregistre un callback qui intercepte chaque erreur, warning et hint de performance GL. Une table de hachage déduplique les messages (log uniquement à la première occurrence).

2.4 — Capture d'entrées et VSync

glfwSwapInterval(0);                    // VSync OFF — FPS illimité
glfwSetInputMode(app->window, GLFW_CURSOR, GLFW_CURSOR_DISABLED);  // Mode FPS

Le curseur est capturé en mode relatif — les mouvements souris produisent des deltas pour le contrôle orbital de la caméra.

Chapitre 3 — Initialisation côté CPU

Avant de toucher au GPU, plusieurs systèmes CPU sont initialisés.

3.1 — La caméra orbitale

camera_init(&app->camera, 20.0F, -90.0F, 0.0F);

La caméra démarre à :

• Distance : 20 unités de l'origine
• Yaw : −90° (regarde le long de −Z)
• Pitch : 0° (niveau de l'horizon)
• FOV : 60° vertical
• Z-clip : [0.1, 1000.0]

Elle utilise un modèle physique à pas fixe (60 Hz) avec lissage exponentiel pour la rotation :

graph LR
    subgraph "Pipeline de mise à jour caméra"
        A("Delta souris") -->|"Filtre EMA"| B("yaw_target / pitch_target")
        B -->|"Lerp α=0.1"| C("yaw / pitch (lissés)")
        C --> D("camera_update_vectors()")
        D --> E("vecteurs front, right, up")
        E --> F("Matrice de vue (lookAt)")
    end

    subgraph "Physique (60Hz fixe)"
        G("Touches ZQSD") --> H("Vélocité cible")
        H -->|"accélération × dt"| I("Vélocité courante")
        I -->|"friction"| J("Position += vel × dt")
        J --> K("Head bobbing (sin)")
    end

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef subsystem fill:#ffffff,stroke:#aaaaaa,stroke-width:1.5px,color:#444444
    classDef loopNode fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d

    class D,F keyFunc
    class A,B,C,E subsystem
    class G,H,I,J,K loopNode

3.2 — Thread de chargement asynchrone

app->async_loader = async_loader_create(&app->tracy_mgr);

Un thread POSIX dédié est créé pour les I/O en arrière-plan. Il dort sur une variable de condition (pthread_cond_wait) jusqu'à ce qu'un travail soit soumis. Cela empêche les lectures disque de bloquer la boucle de rendu.

stateDiagram-v2
    [*] --> IDLE
    IDLE --> PENDING: async_loader_request()
    PENDING --> LOADING: Le worker se réveille
    LOADING --> WAITING_FOR_PBO: I/O terminée, besoin d'un buffer GPU
    WAITING_FOR_PBO --> CONVERTING: Le thread principal fournit le PBO
    CONVERTING --> READY: Conversion SIMD Float→Half terminée
    READY --> IDLE: Le thread principal consomme le résultat

Chapitre 4 — Initialisation de la scène (le GPU se réveille)

scene_init() (src/scene.c) est l'endroit où le GPU reçoit son premier vrai travail.

4.1 — État initial de la scène

scene->subdivisions    = 3;                     // Icosphère niveau 3
scene->wireframe       = 0;                     // Remplissage solide
scene->show_envmap     = 1;                     // Skybox visible
scene->billboard_mode  = 1;                     // Sphères transparentes (billboard)
scene->sorting_mode    = SORTING_MODE_GPU_BITONIC;  // Tri GPU
scene->gi_mode         = GI_MODE_OFF;           // Pas de GI
scene->specular_aa_enabled = 1;                 // AA basé sur la courbure

4.2 — Textures factices et BRDF LUT

Deux textures sentinelles sont créées immédiatement — elles servent de fallback tant qu'une texture IBL n'est pas prête :

scene->dummy_black_tex = render_utils_create_color_texture(0.0, 0.0, 0.0, 0.0);  // 1×1 RGBA
scene->dummy_white_tex = render_utils_create_color_texture(1.0, 1.0, 1.0, 1.0);  // 1×1 RGBA

Puis la BRDF LUT (Look-Up Table) est générée une seule fois via compute shader :

scene->brdf_lut_tex = build_brdf_lut_map(512);

Cette texture mappe (NdotV, roughness) → (F0_scale, F0_bias) et est utilisée chaque frame par le fragment shader PBR pour éviter l'intégration BRDF coûteuse en temps réel.

4.3 — Deux modes de rendu : Billboard Ray-Tracing vs. Mesh Icosphère

Le moteur supporte deux stratégies de rendu de sphères. Le mode par défaut est le billboard ray-tracing.

Mode par défaut : Billboard + Ray-Tracing par pixel (billboard_mode = 1)

Chaque sphère est rendue comme un simple quad aligné à l'écran (4 vertices, 2 triangles). Le fragment shader effectue une intersection rayon-sphère analytique par pixel, produisant des sphères mathématiquement parfaites.

Avantages :

• Silhouettes parfaites au pixel près (jamais de facettage polygonal)
• Profondeur correcte par pixel (gl_FragDepth écrit depuis le point d'intersection)
• Normales analytiquement lisses (normalisé hitPos − center)
• Anti-aliasing des bords via atténuation douce du discriminant
• Vraie transparence alpha (aspect verre, avec tri back-to-front)

graph LR
    subgraph "Billboard Ray-Tracing (Défaut)"
        A("Quad 4-vertex
(par instance)") -->|"Vertex Shader :
projection sur bounds sphère"| B("Quad écran")
        B -->|"Fragment Shader :
intersection rayon-sphère"| C("Sphère parfaite
normale + profondeur par pixel")
    end

    subgraph "Mesh Icosphère (Fallback)"
        D("Mesh 642-vertex
(icosaèdre subdivisé)") -->|"Rastérisé en
triangles"| E("Approximation polygonale
(facettée à basse subdiv)")
    end

    classDef highlight fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef fallback fill:#f5f5f5,stroke:#bdbdbd,stroke-width:1.5px,color:#666666

    class A,B,C highlight
    class D,E fallback

💡 Pourquoi le billboard ray-tracing ? Avec 100 sphères, l'approche billboard utilise 100 × 4 = 400 vertices au total, versus 100 × 642 = 64 200 vertices pour des icosphères niveau 3. Plus important encore, les sphères sont mathématiquement parfaites à tout niveau de zoom — aucun artefact de tessellation.

Fallback : Mesh icosphère instancié (billboard_mode = 0)

Le chemin icosphère génère un icosaèdre subdivisé récursivement :

graph LR
    A("Niveau 0
12 vertices
20 triangles") -->|"Subdiviser"| B("Niveau 1
42 vertices
80 triangles")
    B -->|"Subdiviser"| C("Niveau 2
162 vertices
320 triangles")
    C -->|"Subdiviser"| D("Niveau 3
642 vertices
1 280 triangles")
    D -->|"..."| E("Niveau 6
~40k vertices")

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef subsystem fill:#ffffff,stroke:#aaaaaa,stroke-width:1.5px,color:#444444

    class D keyFunc
    class A,B,C,E subsystem

4.4 — Bibliothèque de matériaux

scene->material_lib = material_load_presets("assets/materials/pbr_materials.json");

Le fichier JSON définit 101 matériaux PBR organisés par catégorie :

Chaque matériau fournit : albedo (RGB), metallic (0–1), roughness (0–1).

4.5 — La grille d'instances

const int cols    = 10;       // DEFAULT_COLS
const float spacing = 2.5F;   // DEFAULT_SPACING

Une grille 10×10 de 100 sphères est disposée dans le plan XY, centrée à l'origine :

Dimensions de la grille :
  Largeur = (10 - 1) × 2.5 = 22.5 unités
  Hauteur = (10 - 1) × 2.5 = 22.5 unités
  Z = 0 (toutes les sphères dans le même plan)

Chaque instance stocke 88 octets :

typedef struct SphereInstance {
    mat4  model;      // 64 octets — matrice de transformation 4×4
    vec3  albedo;     // 12 octets — couleur RGB
    float metallic;   //  4 octets
    float roughness;  //  4 octets
    float ao;         //  4 octets — toujours 1.0
} SphereInstance;     // Total : 88 octets par instance

4.6 — Layout du VAO (mode billboard)

En mode billboard, le VAO lie un quad de 4 vertices et les données matériaux par instance :

┌────────────────────────────────────────────────────────────────┐
│              Billboard VAO (Mode de rendu par défaut)          │
├────────────┬────────────┬─────────────────────────────────────┤
│  Location  │  Source    │  Description                        │
├────────────┼────────────┼─────────────────────────────────────┤
│  0         │  Quad VBO  │  vec3 position   (±0.5 quad verts)  │
│  1         │  Quad VBO  │  vec3 normale    (stub, inutilisé)  │
│  2–5       │  Inst VBO  │  mat4 modèle     (par instance)     │
│  6         │  Inst VBO  │  vec3 albedo     (par instance)     │
│  7         │  Inst VBO  │  vec3 pbr (M,R,AO) (par instance)   │
└────────────┴────────────┴─────────────────────────────────────┘

Location 0–1 : glVertexAttribDivisor = 0 (avance par vertex, 4 verts)
Location 2–7 : glVertexAttribDivisor = 1 (avance par instance)

Appel de draw : glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, 100) — 100 quads, face culling désactivé.

4.7 — Compilation des shaders

Tous les shaders sont compilés pendant scene_init(). Le loader (src/shader.c) supporte un système d'inclusion @header personnalisé :

// Dans pbr_ibl_instanced.frag :
@header "pbr_functions.glsl"
@header "sh_probe.glsl"

Ce système inline récursivement les fichiers (profondeur max : 16), avec déduplication type include-guard.

graph TD
    INIT("scene_init() — Compilation des shaders") --> REND
    INIT --> COMP
    INIT --> POST

    subgraph REND ["🎨 Programmes de rendu"]
        direction TB
        PBR("PBR Instancié — pbr_ibl_instanced.vert/.frag")
        BB("PBR Billboard — pbr_ibl_billboard.vert/.frag")
        SKY("Skybox — background.vert/.frag")
        UI("UI Overlay — ui.vert/.frag")
    end

    subgraph COMP ["⚡ Compute Shaders"]
        direction TB
        SPMAP("Prefiltre Spéculaire — IBL/spmap.glsl")
        IRMAP("Conv. Irradiance — IBL/irmap.glsl")
        BRDF("BRDF LUT — IBL/spbrdf.glsl")
        LUM("Réduction Luminance — IBL/luminance_reduce")
    end

    subgraph POST ["✨ Post-Process"]
        direction TB
        PP("Composite Final — postprocess.vert/.frag")
        BL("Bloom — down/up/prefilter")
    end

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef render fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d
    classDef compute fill:#f3e5f5,stroke:#ab47bc,stroke-width:1.5px,color:#2d2d2d
    classDef postfx fill:#fce4ec,stroke:#c2185b,stroke-width:1.5px,color:#2d2d2d

    class INIT keyFunc
    class PBR,BB,SKY,UI render
    class SPMAP,IRMAP,BRDF,LUM compute
    class PP,BL postfx

Chapitre 5 — Setup du pipeline de post-processing

postprocess_init(&app->postprocess, &app->gpu_profiler, 1920, 1080);

5.1 — Le FBO de scène (Multi-Render Target)

Le framebuffer offscreen principal utilise le MRT (Multiple Render Targets) :

graph TD
    FBO("FBO de Scène — Multi-Render Target") --> C0
    FBO --> C1
    FBO --> DS
    DS --> SV

    C0("🟦 Color 0 — GL_RGBA16F
Couleur HDR scène")
    C1("🟩 Color 1 — GL_RG16F
Vecteurs vélocité")
    DS("🟫 Depth/Stencil — GL_DEPTH32F_STENCIL8")
    SV("🟪 Vue Stencil — GL_R8UI (TextureView)")

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef color0 fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d
    classDef color1 fill:#e8f5e9,stroke:#66bb6a,stroke-width:1.5px,color:#2d2d2d
    classDef depth fill:#fff3e0,stroke:#ff9800,stroke-width:1.5px,color:#2d2d2d
    classDef stencil fill:#f3e5f5,stroke:#ab47bc,stroke-width:1.5px,color:#2d2d2d

    class FBO keyFunc
    class C0 color0
    class C1 color1
    class DS depth
    class SV stencil

5.2 — Ressources des sous-effets

Chaque effet de post-processing initialise ses propres ressources :

5.3 — Effets actifs par défaut

postprocess_enable(&app->postprocess, POSTFX_FXAA);  // Seulement FXAA

Au démarrage, seul FXAA est actif. Les autres effets sont activés/désactivés en temps réel via raccourcis clavier.

Chapitre 6 — Le premier chargement HDR

env_manager_load(&app->env_mgr, app->async_loader, "env.hdr");

Cela déclenche le pipeline de chargement asynchrone d'environnement — l'opération multi-frame la plus complexe du moteur.

6.1 — Séquence de chargement async

sequenceDiagram
    participant Main as Thread Principal (Rendu)
    participant Worker as Thread Worker Async
    participant GPU as GPU

    Main->>Worker: async_loader_request("env.hdr")
    Note over Worker: État: PENDING → LOADING
    Worker->>Worker: stbi_loadf() — décode HDR en float RGBA
    Note over Worker: ~50ms pour 2K HDR sur NVMe

    Worker-->>Main: État: WAITING_FOR_PBO
    Main->>GPU: glGenBuffers() → PBO
    Main->>GPU: glMapBuffer(PBO, WRITE)
    Main-->>Worker: async_loader_provide_pbo(pbo_ptr)

    Note over Worker: État: CONVERTING
    Worker->>Worker: Conversion SIMD float32 → float16
    Note over Worker: ~2ms pour 2048×1024

    Worker-->>Main: État: READY
    Main->>GPU: glUnmapBuffer(PBO)
    Main->>GPU: glTexSubImage2D(depuis PBO)
    Note over GPU: Transfert DMA : PBO → VRAM
    Main->>GPU: glGenerateMipmap()

6.2 — Machine à états de transition

Pendant le premier chargement, l'écran reste noir (pas de crossfade depuis une scène précédente) :

stateDiagram-v2
    [*] --> WAIT_IBL: "Premier chargement"
    WAIT_IBL --> WAIT_IBL: "IBL en cours..."
    WAIT_IBL --> FADE_IN: "IBL terminé"
    FADE_IN --> IDLE: "Alpha atteint 0"

WAIT_IBL : transition_alpha = 1.0 (noir opaque complet) — l'écran est noir pendant les premières frames.

FADE_IN : l'alpha diminue de 1.0 → 0.0 sur 250ms.

Chapitre 7 — Génération IBL (progressive, multi-frame)

Une fois la texture HDR uploadée, le coordinateur IBL (src/ibl_coordinator.c) prend le relais. Il calcule trois maps sur plusieurs frames pour éviter les stalls GPU.

7.1 — Les trois maps IBL

graph TB
    HDR("Map d'environnement HDR
2048×1024 equirectangulaire
GL_RGBA16F") --> SPEC
    HDR --> IRR
    HDR --> LUM

    SPEC("Map Prefiltre Spéculaire
1024×1024 × 5 niveaux mip
Compute: spmap.glsl")
    IRR("Map d'Irradiance
64×64
Compute: irmap.glsl")
    LUM("Réduction Luminance
1×1 moyenne
Compute: luminance_reduce")

    SPEC -->|"Réflexion par pixel
roughness → niveau mip"| PBR("Shader PBR")
    IRR -->|"Intégrale diffuse
hémisphérique"| PBR
    LUM -->|"Seuil auto-exposure"| PP("Post-Process")

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef compute fill:#f3e5f5,stroke:#ab47bc,stroke-width:1.5px,color:#2d2d2d
    classDef target fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d

    class HDR keyFunc
    class SPEC,IRR,LUM compute
    class PBR,PP target

7.2 — Stratégie de découpage progressif

Pour éviter les pics de frame time, chaque niveau mip est subdivisé en slices traitées sur des frames consécutives :

gantt
    title Timeline de génération IBL progressive
    dateFormat x
    axisFormat Frame %s

    section Luminance
    Luminance Pass 1       :lum1, 0, 1000
    Luminance Wait (fence) :lum2, 1000, 2000
    Luminance Readback     :lum3, 2000, 3000

    section Specular Mip 0
    Slice 1/24             :s1, 3000, 4000
    Slice 2/24             :s2, 4000, 5000
    Slice ...              :s3, 5000, 6000
    Slice 24/24            :s4, 6000, 7000

    section Specular Mip 1
    Slices 1-8             :m1, 7000, 9000

    section Specular Mips 2-4
    Dispatch groupé        :m3, 9000, 10000

    section Irradiance
    Slices 1-12            :i1, 10000, 12000

    section Terminé
    IBL Complet → Fade In  :ibl_done, 12000, 13000

7.3 — Machine à états IBL

enum IBLState {
    IBL_STATE_IDLE,             // Pas de travail
    IBL_STATE_LUMINANCE,        // Pass 1 : réduction luminance
    IBL_STATE_LUMINANCE_WAIT,   // Attente fence readback
    IBL_STATE_SPECULAR_INIT,    // Allocation texture spéculaire
    IBL_STATE_SPECULAR_MIPS,    // Génération progressive des mips
    IBL_STATE_IRRADIANCE,       // Convolution irradiance progressive
    IBL_STATE_DONE              // Toutes les maps prêtes
};

Chapitre 8 — La boucle principale

app_run() (src/app.c) est le battement de cœur — une boucle de jeu non capée classique avec physique à pas fixe.

graph TD
    A("① glfwPollEvents() — Clavier, souris, resize")
    A --> B("② Temps & FPS — delta_time, frame_count")
    B --> C("③ Physique Caméra — Pas fixe 60Hz, lerp rotation")
    C --> D("④ Mise à jour géométrie — si subdiv changé")
    D --> E("⑤ app_update() — Traitement état entrées")
    E --> F("⑥ renderer_draw_frame() — LE GROS MORCEAU")
    F --> G("⑦ Tracy screenshots — profiling")
    G --> H("⑧ glfwSwapBuffers() — Présentation à l'écran")
    H -->|"frame suivante"| A

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef loopNode fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d
    classDef subsystem fill:#ffffff,stroke:#aaaaaa,stroke-width:1.5px,color:#444444

    class F keyFunc
    class A,B,C,D,E,G loopNode
    class H subsystem

8.1 — Resize différé

Les événements de redimensionnement sont différés — le callback GLFW enregistre seulement les nouvelles dimensions. La recréation réelle des FBOs se fait au début de la frame suivante, hors du contexte limité du callback.

8.2 — Intégration caméra à pas fixe

app->camera.physics_accumulator += (float)app->delta_time;
while (app->camera.physics_accumulator >= app->camera.fixed_timestep) {
    camera_fixed_update(&app->camera);  // Vélocité, friction, bobbing
    app->camera.physics_accumulator -= app->camera.fixed_timestep;
}

// Rotation lissée (interpolation exponentielle)
float alpha = app->camera.rotation_smoothing;  // ~0.1
app->camera.yaw   += (app->camera.yaw_target   - app->camera.yaw)   * alpha;
app->camera.pitch += (app->camera.pitch_target - app->camera.pitch) * alpha;
camera_update_vectors(&app->camera);

Cela garantit une physique déterministe indépendamment du framerate, tandis que la rotation reste fluide via interpolation par frame.

Chapitre 9 — Le rendu d'une frame

renderer_draw_frame() (src/renderer.c) orchestre le pipeline de rendu complet.

9.1 — Architecture haut niveau

graph TD
    A("GPU Profiler Begin") --> B("postprocess_begin() — Bind Scene FBO, Clear")
    B --> C("camera_get_view_matrix()")
    C --> D("glm_perspective() — FOV=60°, near=0.1, far=1000")
    D --> E("ViewProj = Proj × View")
    E --> G1("🌅 Pass 1 : Skybox — depth désactivée")
    G1 --> G2("🔢 Pass 2 : Tri des sphères — GPU Bitonic")
    G2 --> G3("🔮 Pass 3 : Sphères PBR — draw instancié billboard")
    G3 --> H("✨ postprocess_end() — Pipeline 7 étapes")
    H --> I("🖥️ UI Overlay + Transition Env")

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef loopNode fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d
    classDef setup fill:#ffffff,stroke:#aaaaaa,stroke-width:1.5px,color:#444444
    classDef postfx fill:#fce4ec,stroke:#c2185b,stroke-width:1.5px,color:#2d2d2d

    class G1,G2,G3 keyFunc
    class A,B,C,D,E setup
    class H,I postfx

9.2 — Pass 1 : Skybox

La skybox est dessinée en premier, avec le test de profondeur désactivé. Elle utilise une astuce de quad plein écran :

// background.vert — reconstruction du rayon en espace monde
gl_Position = vec4(in_position.xy, 1.0, 1.0);  // Depth = 1.0 (plan lointain)
vec4 pos = m_inv_view_proj * vec4(in_position.xy, 1.0, 1.0);
RayDir = pos.xyz / pos.w;  // Rayon espace monde reconstruit

// background.frag — échantillonnage equirectangulaire de la HDR
vec2 uv = SampleEquirectangular(normalize(RayDir));
vec3 envColor = textureLod(environmentMap, uv, blur_lod).rgb;
envColor = clamp(envColor, vec3(0.0), vec3(200.0));  // Protection NaN + anti-fireflies
FragColor = vec4(envColor, luma);  // Alpha = luma pour FXAA
VelocityOut = vec2(0.0);          // Pas de mouvement pour la skybox

9.3 — Pass 2 : Tri des sphères (Bitonic Sort GPU)

Pour le rendu transparent par billboard, les sphères doivent être dessinées back-to-front :

9.4 — Pass 3 : Sphères PBR — Billboard Ray-Tracing

C'est le cœur du rendu. Un seul appel de draw rend les 100 sphères :

9.5 — Le fragment shader billboard (intersection rayon-sphère)

Le fragment shader (pbr_ibl_billboard.frag) est là où la magie opère. Au lieu de shader un mesh rastérisé, il intersecte analytiquement un rayon avec une sphère parfaite :

// Intersection rayon-sphère analytique
vec3 oc = rayOrigin - center;
float b = dot(oc, rayDir);
float c = dot(oc, oc) - radius * radius;
float discriminant = b * b - c;  // >0 = touché, <0 = raté
if (discriminant < 0.0) discard;
float t = -b - sqrt(discriminant);  // intersection la plus proche
vec3 hitPos = rayOrigin + t * rayDir;
vec3 N = normalize(hitPos - center);  // normale analytique parfaite

graph TD
    R("🔦 Construction rayon — origin=camPos, dir=normalize(WorldPos-camPos)")
    R --> INT("📐 Intersection Rayon-Sphère — discriminant = b² - c")
    INT --> HIT{"Touché ?"}
    HIT -->|"Non — disc < 0"| DISCARD("❌ discard — pixel hors sphère")
    HIT -->|"Oui"| HITPOS("✅ hitPos = origin + t × dir")
    HITPOS --> NORMAL("N = normalize(hitPos - center) — normale parfaite")
    HITPOS --> DEPTH("gl_FragDepth = project(hitPos) — Z-buffer correct")
    NORMAL --> PBR("V = -rayDir")
    PBR --> FRESNEL("Fresnel-Schlick")
    PBR --> GGX("Smith-GGX Geometry")
    PBR --> NDF("GGX NDF Distribution")
    FRESNEL & GGX & NDF --> SPEC("IBL Spéculaire — prefilterMap × brdfLUT")
    PBR --> DIFF("IBL Diffuse — irradiance(N) × albedo")
    SPEC & DIFF --> FINAL("couleur = Diffuse + Spéculaire")
    FINAL --> AA("Anti-Aliasing bords — smoothstep sur discriminant")
    AA --> ALPHA("FragColor = vec4(color, edgeFactor) — alpha prémultiplié")

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef compute fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d
    classDef entryExit fill:#fce4ec,stroke:#c2185b,stroke-width:2px,color:#2d2d2d
    classDef subsystem fill:#ffffff,stroke:#aaaaaa,stroke-width:1.5px,color:#444444

    class R,INT,HIT keyFunc
    class HITPOS,NORMAL,DEPTH,PBR compute
    class FRESNEL,GGX,NDF,SPEC,DIFF subsystem
    class FINAL,AA,ALPHA,DISCARD entryExit

Anti-aliasing analytique des bords

float pixelSizeWorld = (2.0 * clipW) / (proj[1][1] * screenHeight);
float edgeFactor = smoothstep(0.0, 1.0, discriminant / (2.0 * radius * pixelSizeWorld));
FragColor = vec4(color * edgeFactor, edgeFactor);  // alpha prémultiplié

Projection billboard

Chapitre 10 — Pipeline de post-processing

Après le rendu de la scène 3D dans le FBO MRT, postprocess_end() applique jusqu'à 8 effets dans un pipeline soigneusement ordonné.

10.1 — Le pipeline en 7 étapes

graph TD
    A("Memory Barrier — flush écriture MRT")
    A --> B("① Bloom — Downsample → Seuil → Upsample")
    B --> C("② Profondeur de Champ — CoC → Flou bokeh")
    C --> D("③ Auto-Exposition — Réduction luminance → PBO readback")
    D --> E("④ Motion Blur — Tile-max velocity → Neighbor-max")
    E --> F("⑤ Bind 9 Textures + Upload UBO")
    F --> H("Draw fullscreen quad")
    H --> J("Vignette")
    J --> K("Grain film")
    K --> L("Balance des blancs")
    L --> M("Color Grading — Sat, Contraste, Gamma, Gain")
    M --> N("Tonemapping — courbe filmique")
    N --> O("Grading 3D LUT")
    O --> P("FXAA")
    P --> Q("Dithering — anti-banding")
    Q --> R("Brouillard atmosphérique")

    classDef keyFunc fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef compute fill:#f3e5f5,stroke:#ab47bc,stroke-width:1.5px,color:#2d2d2d
    classDef shader fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d
    classDef subsystem fill:#ffffff,stroke:#aaaaaa,stroke-width:1.5px,color:#444444

    class A,F,H subsystem
    class B,C,D,E compute
    class J,K,L,M,N,O,P,Q,R shader

10.2 — Galerie des effets de post-processing

Voici le rendu vue de face avec différents effets activés individuellement — chaque image montre l'effet isolé appliqué à la même scène :

Sans post-processing (brut)

FXAA (anti-aliasing rapide)

Bloom

Depth of Field (Profondeur de champ)

Auto-Exposure

Motion Blur

Profil cinématique Sony A7S III

10.3 — Optimisation shader par compilation conditionnelle

Le fragment shader post-process utilise des #define au compile-time pour éliminer les branches :

#ifdef OPT_ENABLE_BLOOM
    color += bloomTexture * bloomIntensity;
#endif

#ifdef OPT_ENABLE_FXAA
    color = fxaa(color, uv, texelSize);
#endif

Un cache LRU de 32 entrées stocke les variantes compilées pour différentes combinaisons de flags d'effets. Changer d'effet déclenche une recompilation paresseuse uniquement à la première occurrence d'une nouvelle combinaison.

10.4 — Courbes de tonemapping

10.5 — Adaptation d'exposition

Chapitre 11 — La première frame visible

Voyons ce qui apparaît réellement à l'écran pendant les premières secondes :

Timeline de démarrage

Frame en état stable

Chapitre 12 — Budget mémoire GPU

Voici une estimation de la consommation VRAM en état stable :

Textures

Buffers

Total estimé

💡 Coût dominant : La map HDR d'environnement + chaîne bloom + FBOs de scène dominent l'utilisation VRAM. La géométrie elle-même (100 quads billboard × 4 vertices en mode par défaut) est négligeable — le vrai calcul de sphère se passe dans le fragment shader via ray-tracing.

Galerie : vues multi-angles

Le moteur supporte des captures automatisées depuis différents angles de caméra, utilisées pour les tests de régression visuelle :

Face	Gauche	Droite
Dessus	Dessous	Sony A7S III

Pipeline de données global

graph TD
    POLL("① CPU — glfwPollEvents()") --> TIME("② CPU — Calcul Δt")
    TIME --> CAM("③ CPU — Physique caméra 60Hz")
    CAM --> SORT("④ CPU → GPU — Tri des sphères")
    SORT --> FBO("⑤ GPU — Bind Scene FBO, Clear")
    FBO --> SKY("🌅 Pass Skybox — Sampling equirectangulaire")
    SKY --> SPHERES("🔮 Pass Billboard — 1 draw call, 100 instances, ray-tracing")
    SPHERES --> BLOOM("✨ Bloom + DoF + Auto-Exposure + Motion Blur")
    BLOOM --> COMP("🎬 Composite Final — 9 textures, UBO, fullscreen quad")
    COMP --> UI("🖥️ UI Overlay + Profiler + Transition")
    UI --> SWAP("⑩ glfwSwapBuffers()")

    classDef cpu fill:#e3f2fd,stroke:#42a5f5,stroke-width:1.5px,color:#2d2d2d
    classDef gpu fill:#fff59d,stroke:#f9a825,stroke-width:2px,color:#2d2d2d
    classDef postfx fill:#f3e5f5,stroke:#ab47bc,stroke-width:1.5px,color:#2d2d2d
    classDef subsystem fill:#ffffff,stroke:#aaaaaa,stroke-width:1.5px,color:#444444

    class POLL,TIME,CAM,SORT cpu
    class FBO,SKY,SPHERES gpu
    class BLOOM,COMP postfx
    class UI,SWAP subsystem

Glossaire

Référence rapide des termes techniques utilisés dans l'article, avec liens vers la documentation officielle.

Langages, API & Standards

Rendu 3D — Concepts fondamentaux

Objets GPU OpenGL

Ray-Tracing & Géométrie

PBR & Éclairage

Post-Processing

Architecture & Performance

Mathématiques & Caméra

Algorithmes de tri

Multithreading

Divers

Conclusion

suckless-ogl démontre qu'un moteur PBR complet peut être construit avec un code C11 lisible, un pipeline de rendu clair et des performances GPU mesurées en millisecondes. Les choix de design — billboard ray-tracing au lieu de mesh, chargement HDR asynchrone, IBL progressive, post-processing modulaire — montrent comment résoudre des problèmes graphiques réels avec élégance.

Le code source complet est disponible sur GitHub, et la documentation technique détaillée sur yoyonel.github.io/suckless-ogl.

Dans les prochains articles, on explorera les projets Vulkan et NVRHI qui poussent ces concepts encore plus loin.