🚀 O3DE (Lumberyard) – Moteur 3D Open Source

Qu'est-ce que O3DE ?

O3DE (Open 3D Engine) est un moteur de jeu (Game Engine) 3D temps réel, entièrement open-source (Licence Apache 2.0 / MIT) et multiplateforme.

Il est géré par l'Open 3D Foundation (O3DF), qui fait partie de la Linux Foundation. C'est un effort collaboratif (membres : Adobe, AWS, Intel, Microsoft, Epic Games...) pour créer un moteur AAA "libre", sans royalties ni frais.

Caractéristiques Clés

• Licence Permissive : Apache 2.0. (Totalement gratuit, pas de royalties, pas de frais).
• Architecture Modulaire : (Voir 2.1) Basé sur des "Gems" (plugins). Le cœur est minimal.
• Rendu Moderne : (Voir 3.1) Utilise Atom Renderer (Vulkan, DX12, Metal).
• Multi-Langage : Supporte C++ (performance), Lua (scripting léger), et Python (outils).
• Scripting Visuel : Script Canvas (Nodal, équiv. Blueprints).
• Cloud-Focus : (Héritage d'Amazon) Conçu pour une forte intégration Cloud (AWS).

O3DE est un "fork d'un fork". Son histoire est complexe :

1. CRYTEK (Moteur : CryEngine)
   (Jeu : Crysis)
   │
   │ (Licence vendue à Amazon en 2015, basé sur CryEngine 3.8)
   ▼
2. AMAZON (Moteur : Amazon Lumberyard)
   (Fork propriétaire, gratuit, focus AWS)
   (Jeu : Star Citizen (migration))
   │
   │ (Amazon "offre" le moteur à la Linux Foundation en 2021)
   │ (Amazon abandonne Lumberyard)
   ▼
3. O3DF (Moteur : O3DE - Open 3D Engine)
   (Fork open-source (Apache 2.0) de Lumberyard)
   (Réécriture/Remplacement de composants clés :
    - Rendu (Atom)
    - Build (CMake)
    - ...)

En résumé : O3DE est le successeur spirituel et technique d'Amazon Lumberyard, lui-même basé sur le CryEngine.

O3DE se positionne comme une alternative AAA open-source à Unreal, et une alternative "haute performance" à Godot.

L'architecture de O3DE est "Gem-based" (basée sur les Gemmes). C'est une philosophie hautement modulaire.

Concept : Le "cœur" d'O3DE est minimal. Toutes les fonctionnalités (même celles du moteur) sont implémentées en tant que Gems (Gemmes).

Qu'est-ce qu'une Gem ?

Une "Gem" (Gemme) est un plugin ou un module (un dossier contenant du code C++, Python, des assets, des scripts...).

Un Projet est défini par le cœur (Engine) + la liste des Gems (plugins) qu'il active.

Exemples de Gems

• Atom : Le moteur de rendu (Gem).
• EMotionFX : Le moteur d'animation (Gem).
• ScriptCanvas : Le scripting visuel (Gem).
• PythonEditor : L'intégration Python (Gem).
• (Custom) : MaGemDeMultiplayer (Votre propre Gem).

Avantage : Permet de n'embarquer que le strict nécessaire (ex: un jeu 2D n'a pas besoin de la Gem "Atom" 3D). Permet aux studios de remplacer facilement un système (ex: remplacer la physique par leur propre moteur).

Comme Unity et CryEngine, O3DE utilise une architecture ECS (Entity Component System), basée sur la Composition.

Fonctionnement

1. Entity : Un "conteneur" (une "coquille" vide) avec un ID unique et un Transform (Position, Rotation, Scale).
2. Component : Une "brique" de fonctionnalité (écrite en C++, Lua, ou Script Canvas) attachée à l'Entité.

Exemple (BP_Lampe)

• Entity: "Lampe"
  • Component: Mesh (Visuel 3D du lampadaire)
  • Component: Point Light (Lumière)
  • Component: Audio (Son "buzz")
  • Component: Script Canvas (Logique : "Si le joueur approche, allumer la lumière")

Slices (.slice) sont l'équivalent des Prefabs (Unity) ou des Blueprints (Unreal). C'est le système de "modèle" (template) d'O3DE.

Un "Slice" est un Asset (un fichier .slice) qui stocke une collection d'Entités (Entities) et leurs Composants (Components), ainsi que leur hiérarchie (parent/enfant).

Exemple (Lampe.slice)

(Fichier: Lampe.slice)
  └ Entity ("Root")
    ├─ Component (Mesh)
    ├─ Component (Point Light)
    └─ Component (Script Canvas)

Usage

• Instanciation : Vous pouvez "glisser/déposer" le Lampe.slice 100 fois dans votre Level (Scène) pour créer 100 lampes.
• Héritage (Overrides) : (La force de O3DE/Lumberyard) Vous pouvez créer un "Slice enfant" (ex: LampeRouge.slice) qui hérite de Lampe.slice, mais qui surcharge (override) la couleur du "Point Light Component". (Héritage de Prefabs).

Atom Renderer (ou "Atom") est le nouveau moteur de rendu (Renderer) de O3DE. C'est une réécriture complète (modulaire, via une "Gem") qui remplace le moteur hérité de CryEngine/Lumberyard.

Caractéristiques

• Moderne (API) : Conçu "API-first". Il n'est pas basé sur OpenGL/DX9. Il cible les APIs modernes :
  • Vulkan (Linux, Android)
  • DirectX 12 (DX12) (Windows, Xbox)
  • Metal (macOS, iOS)
• Multi-thread : Conçu pour utiliser massivement le multi-threading CPU (Job System).
• PBR (Physically Based) : (Voir 3.3) Utilise un workflow PBR (Metallic/Roughness) standard.
• Forward+ : Utilise un pipeline "Forward+" (hybride) pour gérer efficacement des milliers de lumières dynamiques.

Atom Renderer (O3DE) supporte le Ray Tracing (RT), mais avec une approche hybride (similaire à UE5 avant Lumen, ou CryEngine).

Rendu Hybride (Rasterization + RT)

Au lieu d'un "Path Tracer" complet (lent), O3DE utilise le "Ray Tracing" (via Vulkan RT / DXR) pour améliorer des parties spécifiques du rendu "raster" (standard) :

• Ombres (Shadows) : Ray Traced Shadows (ombres nettes/douces).
• Réflexions (Reflections) : Ray Traced Reflections (miroirs parfaits).
• Global Illumination (GI) : Ray Traced GI (éclairage indirect).

Note : Le concurrent (Lumen de UE5) utilise du *Software* Ray Tracing (par défaut), tandis qu'Atom (O3DE) et CryEngine se concentrent sur le *Hardware* Ray Tracing (RTX/Radeon).

O3DE (via Atom) utilise un Éditeur de Matériaux (Material Editor) nodal (visuel), similaire à Unreal Engine.

PBR (Physically Based Rendering)

Le workflow est PBR (Rendu Basé sur la Physique), utilisant le standard "Metallic/Roughness".

Un Matériau de base (.material) expose des entrées physiques :

• Base Color : La couleur/texture (Albedo).
• Metallic : (0=Non-métal, 1=Métal).
• Roughness (Rugosité) : (0=Miroir parfait, 1=Mat/Diffus).
• Normal : (La "fausse" texture de relief (Normal Map)).
• Emissive : (Auto-illumination).

C++ est le langage principal (natif) d'O3DE. Il est utilisé pour la haute performance, la création de systèmes moteur (Gems), et l'implémentation de la logique de gameplay fondamentale.

Philosophie (AZ)

O3DE (hérité de Lumberyard) utilise sa propre bibliothèque "core" appelée AZ (Amazon).

• AZ::Component : La classe de base pour tous les Composants C++.
• AZ::Entity : L'Entité.
• AZ::EventBus (EBus) : (Voir 5.2) Le système central d'événements (Signals/Slots).

Exemple (Composant C++)

// MyComponent.h
#include 

namespace MyGame
{
    class MyComponent : public AZ::Component
    {
    public:
        AZ_COMPONENT(MyComponent, "{GUID-Unique}");
        
        // --- Fonctions (Handlers) du cycle de vie ---
        void Activate() override; // (Équiv. _Ready / BeginPlay)
        void Deactivate() override;
        
    protected:
        // --- Réflexion (Équiv. UPROPERTY) ---
        // (Expose 'm_speed' à l'Éditeur et à Lua/ScriptCanvas)
        static void Reflect(AZ::ReflectContext* context);
        float m_speed = 10.0f;
    };
}

// MyComponent.cpp
void MyComponent::Activate()
{
    // (Logique d'initialisation)
}

Lua est le langage de scripting "léger" (haut niveau) intégré à O3DE (hérité de CryEngine/Lumberyard). (Similaire à GDScript pour Godot).

Usage

Utilisé pour le prototypage rapide et la logique de gameplay (IA, Événements) qui ne nécessite pas la performance brute du C++.

Exemple (Script Lua)

-- Script (attaché à une Entité)
local MyScript = {
    Properties = {
        Speed = { default = 5.0, type = "float" }
    }
}

-- Équivalent de Activate() / Start()
function MyScript:OnActivate()
    -- Se connecter au "TickBus" (Événement Update)
    self.tickBusHandler = TickBus.Connect(self, self.OnTick)
end

-- Équivalent de Update()
function MyScript:OnTick(deltaTime)
    -- (Logique de mouvement)
    local move = Vector3(0, 1, 0)
    self.entity:Move(move * self.Properties.Speed * deltaTime)
end

return MyScript

Python n'est pas utilisé pour le gameplay (Runtime). Il est utilisé exclusivement pour l'Automatisation et l'Outillage (Tooling).

Usages de Python

• Build System (CMake) : Le système de build d'O3DE (basé sur CMake) est géré via des scripts Python.
• Automatisation de l'Éditeur (Editor) : L'Éditeur O3DE expose une API Python. Permet de scripter des tâches d'éditeur (ex: "Importer 1000 assets", "Placer 50 lumières", "Lancer un build").
• Scripts CLI : (ex: Le Project Manager, les outils de Gem).

Script Canvas est le système de scripting visuel (nodal) d'O3DE. C'est l'équivalent direct des Blueprints (Unreal) ou de Schematyc (CryEngine).

Fonctionnement

Permet aux designers (non-programmeurs) de créer une logique de gameplay (un "Component") en connectant des nœuds (nodes) dans un éditeur graphique (Graphe).

(Événement)                   (Flux d'Exécution)
[On Tick (Update)]──(Exec)──►[Get Input Axis]──(Exec)──►[Move Entity]
                              (Nom: "MoveX")  │
                                              │ (Float)
                                              └───────────────────► (Input: Vitesse)

Les fonctions C++ (exposées via Reflect) et les événements (EBus) sont automatiquement disponibles sous forme de nœuds dans Script Canvas.

Le Bus d'Événements (EBus) est le système de communication (Signals/Slots) principal d'O3DE. C'est ce qui permet aux Composants (et Entités) de communiquer de manière découplée.

Le Problème (Couplage Fort)

// (Couplage Fort)
// Le Joueur (Player.cpp) doit "connaître" l'UI (UI.cpp)
// pour appeler sa fonction.
m_uiManager->UpdateHealth(newHealth);

La Solution (EBus - Découplage)

Le Joueur émet (Broadcast) un événement sur un "Bus" (ex: "HealthBus"), sans savoir (ni se soucier) qui écoute.

// 1. (Player.cpp) Émet l'événement
// (Envoie l'événement "HealthChanged" sur le bus de CETTE Entité)
EBUS_EVENT_ID(GetEntityId(), PlayerNotificationBus, OnHealthChanged, newHealth);

// 2. (UIManager.cpp) Écoute (Listen) l'événement
// (Le 'UIManager' s'abonne (Connect) au 'PlayerNotificationBus'
//  de l'Entité du joueur au démarrage)
void UIManager::OnHealthChanged(int newHealth)
{
    // (Mettre à jour la barre de vie)
}

Contrairement à Unreal (Unreal Build Tool - UBT) ou Unity (MSBuild), O3DE a standardisé son système de build sur CMake (le standard de l'industrie C++).

Fonctionnement

L'ensemble du projet (Moteur, Gems, Jeu) est défini par des fichiers CMakeLists.txt.

Avantages :

• Standard : Les développeurs C++ connaissent déjà CMake.
• Flexible : S'intègre nativement avec tous les IDEs (Visual Studio, VS Code, CLion, Xcode).
• Transparent : Le processus de build est (relativement) clair.

O3DE hérite du stack réseau de Lumberyard (CryEngine), qui est très puissant pour le multijoueur (AAA).

GridMate

GridMate est la bibliothèque réseau (Couche 4) de O3DE. C'est une couche d'abstraction qui gère :

• La gestion de session (Rejoindre, Quitter).
• La topologie (Client/Serveur, Peer-to-Peer).
• Le transport (fiable/non-fiable).

Réplication (Replica)

O3DE utilise un modèle de Réplication (Stateful) (similaire à Unreal).

• Replica (Réplique) : Un objet (Entité, Component) qui existe sur le Serveur (Autorité) et qui est "répliqué" (synchronisé) aux Clients.
• RPC (Remote Procedure Call) : Permet à un Client d'appeler une fonction sur le Serveur (et vice-versa).

EMotion FX (acquis par Amazon, maintenant intégré à O3DE) est le moteur d'animation (Runtime) de O3DE. (Équivalent : Mecanim (Unity) / Animation Blueprints (Unreal)).

Composants

• Animation Editor : L'interface pour importer, prévisualiser et configurer les animations (.fbx).
• Anim Graph (Anagraphe) : (Le "cœur") Un graphe d'état (State Machine) nodal (visuel) qui définit la logique d'animation.

Exemple (Anim Graph)

Définit les transitions (ex: "Idle" -> "Run") :

[État: IDLE] ── (Condition: "Speed > 0.1") ──► [État: RUN]
   ▲
   │
   └─ (Condition: "Speed < 0.1") ◄── [État: RUN]