🎨 Unreal Editor – Interface, Outils & Workflow

L'Unreal Editor (UE Editor) est l'IDE (Integrated Development Environment) de l'Unreal Engine. C'est l'application (GUI) principale que les développeurs et artistes utilisent pour assembler, visualiser, et tester le jeu.

Il est l'équivalent de "Unity Editor" (Unity) ou "Sandbox Editor" (CryEngine).

WYSIWYG (What You See Is What You Play)

La philosophie de l'éditeur est le "Temps Réel". Ce que vous voyez dans le Viewport (1.2) est (grâce à Lumen/Nanite) une représentation quasi-finale du jeu.

Le mode Play In Editor (PIE) (2.3) permet de lancer le jeu instantanément dans l'éditeur pour des tests et un débogage rapides.

L'interface (GUI) de l'Éditeur Unreal est composée de plusieurs fenêtres (Views) modulables.

Le Content Drawer (ou Content Browser) est l'explorateur de fichiers d'Unreal. Il représente le dossier Content/ de votre projet sur le disque.

C'est là que tous les Assets (ressources) du jeu sont stockés. Contrairement à Unity, Unreal utilise (majoritairement) un format binaire propriétaire : .uasset.

Types d'Assets (.uasset)

• Level (.umap) : (Le seul autre format) La Scène.
• Blueprint (.uasset) : (Logique) (ex: BP_Player).
• Static Mesh (.uasset) : (3D) Le modèle 3D (géométrie).
• Material (.uasset) : (Rendu) Le Shader.
• Texture (.uasset) : (Rendu) L'image (.png/.tga importée).
• Skeletal Mesh (.uasset) : (Animation) Le modèle 3D avec squelette.

Unreal utilise un modèle hybride (Héritage + Composition).

C'est l'architecture (conceptuelle) d'Unreal pour la logique de jeu. Elle sépare les "Règles", le "Cerveau" et le "Corps".

PIE est la fonction principale (bouton "Play") de l'éditeur pour tester le jeu instantanément.

Modes de "Play"

• Selected Viewport : (Défaut) Lance le jeu *dans* la fenêtre "Viewport" actuelle.
• New Editor Window : Lance le jeu dans une nouvelle fenêtre (taille ajustable).
• Standalone Game : Lance le jeu dans un processus séparé (.exe). (Plus lent à démarrer, mais simule les conditions "Build").

Fonction "Possess" (Possession)

Pendant le PIE, le PlayerController (2.2) "possède" (possesses) le Pawn (personnage) défini dans le GameMode (2.2).

Eject (Éjecter) (Touche F8) : Permet (pendant le PIE) de "quitter" le Pawn (le jeu se met en pause) et de revenir à la caméra "Spectateur" de l'éditeur pour inspecter (debug) la scène (ex: "Où est mon ennemi bloqué ?").

Le Scripting Visuel (Nodal)

Blueprints (BP) est le système de scripting visuel (Nodal) d'Unreal. Il permet de créer une logique de jeu (fonctions, variables) sans écrire de code C++.

C'est un système "basé sur les nœuds" (Nodes) : on connecte des "boîtes" (Fonctions) avec des "fils" (Flux d'exécution).

(Équivalent C# de Unity: 'OnTriggerEnter')

[Event 'OnActorBeginOverlap']──(Exec)──►[Cast To 'BP_Player']──(Exec)──►[Apply Damage]
 (Actor) ───────────────────────────────► (Object)              (Target) ◄─ (Self)
                                         (As BP_Player) ───────────────► (Damaged Actor)

Avantages

• Accessibilité : Permet aux non-programmeurs (Game Designers, Artistes) de créer de la logique.
• Prototypage Rapide : Extrêmement rapide pour tester une idée (itération).
• Intégration : Parfaitement intégré à l'éditeur.

Quand vous créez un Blueprint (clic droit -> Blueprint Class), vous héritez d'une classe. Les plus courants :

Un "Actor Blueprint" (3.2) contient deux graphes (espaces de code) principaux :

Le C++ est le langage "natif" d'Unreal Engine. Il est utilisé pour la performance et pour créer des systèmes de base (ex: la "fondation" d'un Personnage) qui seront ensuite étendus/utilisés par les Blueprints.

Unreal Header Tool (UHT) - La "Magie"

UE utilise un C++ "modifié" (via un pré-processeur, l'UHT) qui gère la Réflexion (Reflection) (voir 6.3 du guide "Custom Engine") et le Garbage Collection (GC).

Pour que le C++ soit "visible" par l'Éditeur Unreal (et par les Blueprints), vous devez utiliser des Macros :

// MyCharacter.h (Fichier Header)
#pragma once
#include "GameFramework/Character.h"
#include "MyCharacter.generated.h" // (Généré par UHT)

// 1. UCLASS() (Rend la classe visible par UE)
UCLASS(Blueprintable) // (Permet d'en hériter en Blueprint)
class AMyCharacter : public ACharacter
{
    GENERATED_BODY() // (Magie UHT)

public:
    AMyCharacter();

protected:
    // 2. UPROPERTY() (Rend la variable visible/éditable)
    // (Visible dans l'Inspecteur ET en Blueprint)
    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Stats")
    float Health;

    // 3. UFUNCTION() (Rend la fonction visible/appelable)
    // (Peut être appelée depuis un Event Graph Blueprint)
    UFUNCTION(BlueprintCallable, Category="Stats")
    void TakeDamage(float Amount);

    // (Événement natif, implémentable en BP)
    UFUNCTION(BlueprintImplementableEvent)
    void OnDeath();
};

Historiquement, la compilation C++ (surtout pour un moteur de jeu) était un processus très lent (Hot Reload).

Live Coding (UE5)

Live Coding (UE 4.22+) est le système de compilation "moderne". Il permet de modifier le code C++ pendant que l'Éditeur (ou le jeu) tourne.

Workflow (Live Coding)

1. Lancer le jeu (Play in Editor).
2. Ouvrir Visual Studio / VS Code / Rider.
3. Modifier une fonction C++ (ex: changer la vitesse du joueur).
4. Appuyer sur Ctrl+Alt+F11 (Compiler).
5. Live Coding compile les deltas (changements) (très rapide).
6. Il "patch" (applique) le nouveau code (DLL) à chaud dans le processus du jeu.
7. Vous voyez le changement (nouvelle vitesse) instantanément, sans redémarrer le jeu.

Limite : Le Live Coding ne fonctionne (généralement) pas si vous modifiez les en-têtes (.h) (ex: ajouter un UPROPERTY). Cela nécessite un redémarrage complet de l'Éditeur.

La force d'Unreal est l'hybridation des deux. La question n'est pas "l'un *ou* l'autre", mais "quand utiliser l'un *et* l'autre".

Le Workflow Hybride (Recommandé)

1. (C++) Le Programmeur crée les systèmes de base (fondations) en C++.
   • (Ex: AMyCharacter.cpp).
   • (Crée les UPROPERTY (ex: float Health) et les UFUNCTION (ex: TakeDamage())).
2. (BP) Le Designer crée un Blueprint (Enfant) qui hérite de la classe C++ (ex: BP_Joueur hérite de AMyCharacter).
3. (BP) Le Designer (dans l'Éditeur) :
   • (Inspecteur) : Règle les variables (UPROPERTY) (ex: Health = 150).
   • (Event Graph) : Assemble la logique (ex: Event OnOverlap -> (Appelle C++) TakeDamage(10)).
   • (Event Graph) : Implémente les événements (ex: Event OnDeath -> (Logique BP) Spawn Explosion VFX).

Lumen est le système d'Illumination Globale (Global Illumination - GI) et de Réflexions dynamique (temps réel) de UE5.

Le Problème (Avant Lumen)

Avant UE5, l'éclairage "indirect" (les rebonds de lumière, ex: la lumière du soleil qui rebondit sur un mur rouge et colore le plafond en rouge) était pré-calculé ("baked").

Ce "baking" (ex: "Lightmass") prenait des heures (voire des jours) de calcul et était statique (si vous déplaciez une lumière, il fallait tout re-calculer).

La Solution (Lumen)

Lumen calcule l'éclairage indirect et les réflexions en temps réel (dynamique). Si vous déplacez le soleil, l'éclairage de la scène est mis à jour instantanément.

Résultat : Itération artistique ultra-rapide, mondes dynamiques (ex: cycle jour/nuit, lampes torches).

Modes (Software vs Hardware)

• Software Ray Tracing : (Défaut) Rapide, fonctionne sur (presque) tout.
• Hardware Ray Tracing : (Meilleure qualité) Utilise les cœurs RT des cartes (NVIDIA RTX, PS5, Xbox Series X).

Nanite est le système de géométrie virtualisée (micropolygones) de UE5.

Le Problème (Avant Nanite)

Un modèle 3D "ciné-qualité" (ex: une statue) peut avoir 10 millions de polygones. (Budget de polygones/frame : 1-5M polys).

Solution (Legacy) : L'artiste 3D devait manuellement créer des LODs (Level of Detail) :

• LOD 0 (proche) = 50k polys
• LOD 1 (moyen) = 5k polys
• LOD 2 (loin) = 500 polys

Un travail long et coûteux.

La Solution (Nanite)

Avec Nanite, vous importez directement le modèle ciné-qualité (10 millions de polygones) dans le moteur.

Nanite analyse le modèle et génère automatiquement une représentation (micropolygone) qu'il peut "streamer" (diffuser) à la volée. Il ne dessine que les polygones (Clusters) qui sont visibles et de la taille d'un pixel.

Résultat : Niveaux de détail géométrique infinis, plus de "pop-in" de LOD, et un gain de temps de production artistique massif.

Problème : Nanite (5.2) permet des milliards de polygones. Les "Shadow Maps" (cartes d'ombres) traditionnelles ne peuvent pas gérer cette complexité (elles pixelliseraient).

Solution : VSM (Virtual Shadow Maps). C'est le "Nanite" pour les ombres. C'est un système de "shadow map" à résolution virtuelle (micropolygones) conçu pour fonctionner avec Nanite et Lumen (5.1) et produire des ombres dynamiques (temps réel) extrêmement nettes et stables, même sur des scènes immenses.

Problème : Comment créer un monde ouvert (Open World) (ex: 100km x 100km) ? On ne peut pas charger tous les assets (terrains, arbres, bâtiments) en mémoire en même temps (RAM/VRAM).

Solution (Legacy - UE4) : World Composition. L'artiste découpait manuellement le monde en "Levels" (sous-niveaux) et gérait leur chargement (streaming) manuellement.

Solution (UE5) : World Partition

World Partition (le système par défaut pour les "Open Worlds" UE5) automatise ce processus.

1. L'artiste travaille sur 1 seul "Persistent Level" (Niveau Persistent).
2. Il place ses assets (ex: une forêt, un village).
3. En arrière-plan, UE5 assigne automatiquement ces assets à une grille (Grid) (cellules).
4. Au Runtime : UE5 ne charge (stream) que les cellules (grilles) qui sont proches du joueur.

Résultat : Mondes ouverts massifs avec streaming automatique. (Fonctionne avec "Data Layers" (ex: charger/décharger la version "détruite" d'un bâtiment)).

UMG (Unreal Motion Graphics) est l'éditeur d'interface utilisateur (UI) d'Unreal. (Similaire au "Canvas" d'Unity ou "Control" de Godot).

Widget Blueprint

L'UI est créée dans un "Widget Blueprint".

C'est un éditeur spécialisé (Drag & Drop) qui combine deux vues :

• Designer (Design) : La vue "visuelle" (WYSIWYG) où vous glissez/déposez les contrôles (Boutons, Textes, Images, Barres de progression...).
• Graph (Graphe) : Un "Event Graph" (Blueprint) standard, utilisé pour la logique de l'UI (ex: Event OnClicked (Button_1) -> Ouvrir Level "Options").

Sequencer est l'outil de cinématique (non-linéaire) d'Unreal (remplace l'ancien "Matinee").

C'est un "Adobe Premiere" ou "After Effects" intégré à l'éditeur.

Usage

Permet de créer des "Séquences" (.uasset) qui animent n'importe quoi dans la scène via une Timeline (chronologie) :

• Caméras : (Mouvement, Focus (Focale)).
• Actors : (Mouvement, Propriétés (ex: couleur de lumière)).
• Animations : (Déclencher des animations de personnages).
• Audio : (Déclencher des musiques, sons).

C'est l'outil utilisé pour les cinématiques de jeu ("Cutscenes") et la production virtuelle (VFX).

Chaos est le moteur physique (développé en interne par Epic) de UE5. Il remplace l'ancien moteur (NVIDIA PhysX) utilisé dans UE4.

Chaos Destruction

Le point fort. Permet la destruction dynamique (temps réel).

Workflow (Éditeur) :

1. Fracture Editor : L'outil (dans l'éditeur) pour "casser" un Static Mesh (ex: un Mur) en morceaux (Fragments), en utilisant des "Fractures" (Voronoi, etc.).
2. Geometry Collection : L'Asset (résultat) qui contient tous les morceaux "fracturés".
3. Simulation : Le moteur Chaos simule (dynamiquement) la chute/collision de ces morceaux lors d'un impact.

Autres (Chaos)

• Chaos Cloth : Simulation de vêtements, tissus.
• Chaos Vehicles : Simulation de véhicules.

L'animation dans UE est (principalement) gérée par les Animation Blueprints (Anim BP), qui sont appliqués aux Skeletal Meshes (Meshs avec Squelette/Armature).

Éditeur (Anim BP)

Un Anim BP (comme les Blueprints) a deux graphes principaux :

(Event Graph - Tick)
1. Get Owning Pawn
2. Cast To MyPlayerCharacter
3. Get Velocity -> (Set 'Speed' variable)
4. Get IsFalling -> (Set 'bIsJumping' variable)

[État: IDLE] ── (Condition: "Speed > 0.1") ──► [État: RUN]
   ▲
   │
   └─ (Condition: "Speed < 0.1") ◄── [État: RUN]
   
(L'état "RUN" joue l'animation "Run_Loop")

"Packaging" (Empaquetage) est le processus (File > Package Project) qui compile le jeu final (ex: .exe) pour une plateforme (Target).

Processus de Build

1. "Cooking" (Cuisson) : (Le plus long) Convertit tous les Assets (.uasset) en formats optimisés pour la plateforme cible (ex: Textures compressées, Shaders compilés).
2. Compilation (C++) : Compile le code C++ du jeu (en mode "Shipping" / Release).
3. Packaging (Empaquetage) : Met tous les assets "cuits" et le code compilé dans les fichiers (.pak) finaux.

Configurations de Build

• Debug : (Débogage C++).
• Development : (Défaut) (Inclut les outils de console, profiling).
• Shipping : (La "Release") (Version finale optimisée, sans logs, sans console).