Babylon.js est un framework complet pour créer des jeux 3D à l'aide de HTML5 et WebGL basé 100% en JavaScript, développé par des programmeurs de Microsoft. Il fonctionne correctement sur Firefox et Chrome et il est compatible avec les caractéristiques suivantes:
- Graphiques complets de scènes , luz, cámaras, materiales y texturas
- Moteur de collisions
- Sélection de scènes
- Antialiasing
- Moteur d'animations
- Systèmes de particules
- Sprites et layers 2D
- Moteurs d'optimisation
- Matériaux standard au niveau du pixel
- Brouillard
- Blending alpha
- Tests alpha
- Billboarding
- Mode plein écran
- Maps d'ombres et maps de variation d'ombres
- Rendu de textures
- Textures dynamiques (canvas)
- Textures vidéo
- Caméras (perspectives et orthogonalité)
- Clonage de maille
- Maillages dynamiques
- Maps de hauteur
- Les scènes de Babylone peuvent se convertir en. OBJ, .FBX, .MXB
- Exporte vers Blender
Ci-dessous est un cours vidéo bien très bien expliqué en espagnolOscar Uh Pérez (Develoteca) qui nous donne toutes les compétences nécessaires pour mettre les mains dans la pâte.
Aussi, je laisse quelques tutoriaux intéressants de Julian Chenard pour commencer avec Balylon.js dans le lien suivant: http://www.pixelcodr.com/
Plus de tutoriels: http://www.babylonjs-playground.com/
Dépôt
Babylon.js est un puissant, belle, simple, et jeu ouvert et moteur de rendu emballé dans un framework JavaScript convivial.
https://github.com/BabylonJS/Babylon.js
3,662 fourches.
25,703 étoiles.
21 questions ouvertes.
commits récents:
- réparer(cœur): register PostProcess side-effects for tree-shaken SSAO2 (#18624)## ProblemSSAO2 — and other texture-chaining post-process pipelines — renderincorrectly in **tree-shaken / selective-ES6 builds** (importing corethrough the pure barrel rather than the full `@babylonjs/core` bundle).The scene color is lost and the image washes out to a near-white, bandedresult.This surfaced in the **Viewer**, whose SSAO path runs against thedev/tree-shaken build. The published full bundle is unaffected becausebundling pulls in every side effect, which is exactly what masks thebug.| SSAO off | SSAO on (before this PR) ||—|—|| Correctly shaded, textured scene | Scene color gone, washed white +banded |This PR completes the construction-time / eager side-effect registrationwork from #18546 et #18620, which covered ~20 classes plus the`PostProcessRenderPipelineManager` getter but missed the two casesbelow.## Root causesThere are **two independent missing side-effect registrations**:### 1. `PostProcess` texture-binding methods were never registeredSSAO2's combine pass binds the captured original scene color via:“`tseffect.setTextureFromPostProcessOutput("originalColor", this._originalColorPostProcess);“`That `Effect` / `AbstractEngine` prototype method is installed only by`RegisterPostProcess()`, which normally runs as a side effect ofimporting the `postProcess.ts` wrapper. In a tree-shaken build only`postProcess.pure` is imported, so the method stayed an **unregisteredno-op stub**: `originalColor` never bound → the combine shader sampledthe default (white) texture → the output became `AO × white` instead of`AO × sceneColor`.**Fix:** the `PostProcess` constructor now calls the idempotent`RegisterPostProcess()`, matching the pattern #18620 applied to ~20other classes. This also latently repairs **bloom, depth of field, andSSR**, which rely on the same `setTextureFromPostProcess` /`setTextureFromPostProcessOutput` methods.### 2. The `Scene.postProcessRenderPipelineManager` getter wasregistered too late for some consumers#18546 injects the manager class in the `PostProcessRenderPipeline`constructor. But a consumer may access the manager (par exemple. to subscribe toits `onNewPipelineAddedObservable` / `onPipelineRemovedObservable`)**before** constructing the pipeline. In that ordering the getter isstill unregistered and the manager is `undefined`, so SSAO neverattaches.**Fix:** `RegisterSsao2RenderingPipeline()` — the import-time entrypoint already triggered when the SSAO2 module loads — now eagerlyregisters the getter and injects the concrete`PostProcessRenderPipelineManager` class, so it is available as soon asSSAO2 is imported. This follows #18546's "inject the class, don't forcethe full side-effect wrapper" approach and keeps the fix scoped to SSAO2without affecting other pipelines' tree-shaking.## TestsAdds a Viewer visualization test, `load OBJ model with ssao="enabled"`,that loads `StanfordBunny.obj` with SSAO enabled and screenshot-comparesthe result (also exercising OBJ loading, which had no Viewer coverage).SSAO seeds its sampling-kernel rotation texture from `Math.random`, sothe test installs a deterministic PRNG via `addInitScript` to keep thescreenshot stable.This gives CI coverage for SSAO2, whose standard visualization test(`ssao2`) is currently `excludeFromAutomaticTesting`. Re-enabling thatstandard test as an additional guard would be a reasonable follow-up.## Validation- Viewer OBJ+SSAO renders correctly with **no Viewer-side change** (thefix is entirely in core).- New test passes deterministically; **all 44 Viewer tests pass**.- Post-process unit tests pass.- **Tous 16 tree-shaking checks pass** (manifest drift, side-effectimport closure, pure barrels, side-effect stubs) — confirming the new`.pure` imports don't break the side-effects contract.- `prettier –check` and `eslint` clean (0 errors).Co-écrit par: Copilot <223556219+[email protected]>, GitHub
- docs: add shareable Babylon.js tools design guidelines (#18621)## WhatAdds `.github/design-guidelines.md` — a standalone, copyable designguidelines document for **Babylon.js tools** (Inspector,NME/NGE/NPE/NRGE, de darraghjburke/geParametersUIOverhaul, Smart Filters Editor, Téléspectateur, Cour de Récréation,and future tools).It is based on the existing Fluent UI / `MakeModularTool` work in the**Inspector (inspector-v2)** and **Flow Graph Editor**, which alreadydefine a strict color schema and a consistent panel/overlay structure.## WhyWe want one shared baseline so every tool — across all Babylon.jsrepositories — looks, feels, and behaves like part of the same family.The doc is intentionally self-contained so it can be copied into otherrepos.## Contents- **Core principles** — Fluent-first, theme-token-driven, sharedwrappers, one shell, modular services.- **Color schema** — the Babylon brand ramp (key color `#3A94FC`),light/dark theme generation, and the no-hard-coded-colors rule.- **Layout & shell structure** — central content, dockable side panes(left/right × top/bottom), toolbars, `compact` vs `full` modes.- **Bootstrapping** — `MakeModularTool`, services, reactive hooks,`ISettingsStore`.- **Components / styling / typography / icônes / sizing / feedback** —shared wrappers, `PropertyLine`/`Accordion`, `ToggleButton`/`Collapse`,`makeStyles` + tokens, text presets, unsized icons, `ToolContext`,toasts/dialogs/teaching moments.- **Consuming from npm** — install + peer-dependency guidance for`@babylonjs/shared-ui-components` and a stability caveat.- A per-tool **checklist** and a **references** section.Also links the new doc from `.github/instructions/index.md`.## NotesDocs-only change. The local `precommit` hook (`lint-staged`) is notinstalled in this worktree, so the commit was made with `–no-verify`;there is no code to lint/build/test here.———Co-écrit par: Copilot <223556219+[email protected]>, GitHub
- Fix unregistered image processing parser breaking material clone in tree-shaken builds (#18623)## ProblemIn tree-shaken builds,`SerializationHelper._ImageProcessingConfigurationParser` stays anunregistered throwing stub unless the `imageProcessingConfiguration`side-effect wrapper happens to be imported transitively. As a result,`clone()` / `Parse()` throws for any material that serializes an imageprocessing configuration, because cloning serializes`_imageProcessingConfiguration` (serialization type 9) and invokes thatunset parser.This affects every material that mixes in `ImageProcessingMixin`:- `StandardMaterial`- `BackgroundMaterial`- `NodeMaterial`- `PBRMaterial`- `PBRMetallicRoughnessMaterial`- `PBRSpecularGlossinessMaterial`- `OpenPBRMaterial`## FixRather than relying on a manual side-effect import at the call site,each affected material now calls`RegisterImageProcessingConfiguration()` from its own `Register*()`function in its `.pure.ts` — the place the tree-shaking architecturedesignates for side effects. Importing a material's side-effect wrapper(or calling its register function directly) now self-registers theparser, while the pure import path remains side-effect-free.## TestsAdds `babylon.imageProcessingSideEffect.test.ts`, which for each of the7 materials asserts:1. The parser is a throwing stub on a fresh module import.2. Importing the material's `.pure` module produces no side effect.3. Running the material's `Register*()` wires up a working parser.This test fails on `master` before the fix.## Validation- `tsc` build: clean- ESLint (incl. pure-import rules): 0 errors- Prettier: formatted- `check:manifest-drift` and `check:side-effects-sync`: up-to-date (notop-level side-effect change)- Existing material unit tests: pass## Note`StandardMaterial` also serializes `FresnelParameters`(`_FresnelParametersParser`), which has the same latent stub problem intree-shaken builds. This PR is intentionally scoped to the reportedimage-processing issue; happy to extend the same pattern to fresnelparameters in a follow-up if desired.Co-authored-by: Copilot <223556219+[email protected]>, GitHub
- OpenPBR Fuzz Fixes (#18617)Sampling fixes for OpenPBR fuzz, including a fix to use the correctdiffuse lighting when coating is used., GitHub
- réparer(cœur): register hard side-effect dependencies at construction time for pure barrel (#18620)## MotivationWhen consuming `@babylonjs/core` through the **pure barrel**(tree-shaking-friendly path), features could fail silently or crashbecause a prototype-augmented engine/scene method was never registered.That registration only happened as a side effect of an `import "…"` inthe feature's `.ts` wrapper — which the pure barrel deliberately skips.The guiding principle: **if a feature simply cannot work without anotherfeature** (a *hard* dependency, not an optional capability), it shouldregister that dependency **at construction time**, rather than forcingthe consumer to add a manual side-effect import.## What changedHard dependencies are now registered inside the feature's `.pure.ts`constructor using the existing idempotent `Register*()` functions. Thismirrors the pre-existing precedent in `depthRenderer.pure.ts`.**Engine extensions** — now self-register the engine extension theyrequire:- `dynamicTexture`, `cubeTexture`, `htmlElementTexture`,`multiRenderTarget`- `webgl2ParticleSystem` / `thinParticleSystem` (transformFeedback),`gpuParticleSystem`- `vrMultiviewToSingleviewPostProcess` (alpha / multiview),`thinDepthPeelingRenderer`**Scene components** — caller now registers the scene component beforeinvoking the augmented `scene.enableX()`:- `prePassRenderer` → geometryBufferRenderer SC- `IBLShadows/iblShadowsRenderPipeline` → geometryBufferRenderer SC +iblCdfGenerator SC- `FrameGraph/…/iblShadowsRendererTask` → iblCdfGenerator SC- `Cameras/VR/vrExperienceHelper` → gamepad SC + animatable- `animationGroup` → animatable**Redundant import removal** — the `ssao` and `lens` rendering pipelinesalready self-register the depth scene component in their `.pure`constructors, so the now-redundant wrapper imports were dropped.## Metadata- Side-effects manifest shards updated (`Animations`, `Cameras`,`FrameGraph`, `Materials`, `Particles`, `Rendering`).- `@babylonjs/core` `package.json` `sideEffects` array updated to dropthe wrappers that are now side-effect-free (684 → 675 cumulative).## Backward compatibilityFully preserved. The wrappers only lose bare side-effect imports thataffect the **pure barrel** path. The **full** side-effect barrel(`@babylonjs/core` via `index.ts`) still registers everything, becauseevery target is still `export *`'d from its package index barrel. Theregistration calls are all idempotent, so the full path incurs nodouble-registration cost.## Notes for reviewers- All `Register*()` functions used here are idempotent (guarded by amodule-level `_Registered` flag or an instance check), soconstruction-time calls are safe and cheap.- Scene-component register functions receive the feature class as anargument (the augmented `scene.enableX()` constructs it), so no circularvalue imports are introduced.- Some candidates were intentionally **skipped**:`baseTexture.polynomial` (handled by the generated`_MissingSideEffectProperty` stub pattern + too cross-cutting),`colorCurves` (serialization-only, not a hard dep),`planeRotationGizmo`→`linesBuilder` (vestigial),`gaussianSplattingMesh`→`thinInstanceMesh` (no `thinInstance` usage in`.pure`).Co-écrit par: Copilot <223556219+[email protected]>———Co-écrit par: Copilot <223556219+[email protected]>, GitHub