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,675 fourches.
25,917 étoiles.
20 questions ouvertes.
commits récents:
- GPU particles: re-bake gradient lookup textures in place for value edits (#18787)Value-only gradient changes within an active family now update theexisting lookup texture's pixels via RawTexture.update() instead ofdisposing it and releasing the sim buffers, so the live particle poolsurvives the edit and retained WebGPU compute bindings stay valid.Structural transitions (family appearing/disappearing, color2 row-layoutflip) keep the release path unchanged.Associated forum thread:https://forum.babylonjs.com/t/pop-free-gradient-edits-on-gpuparticlesystem/63917———Co-écrit par: Claude Fable 5 <[email protected]>, GitHub
- Native nightly: downlevel every bundle, not just babylon.max.js (#18799)The "Update scripts from snapshot" step refills **every** `babylon*`file in the two Babylon Native artifact directories from the CDNsnapshot:“`batset destDir=..BabylonNativeNightlyPlaygroundRelWithDebInfoScriptsfor /f %%i in ('dir /b %destDir%babylon*') do ( unzip -p snapshot.zip "**%%i" > %destDir%%%i)“`…but the downlevel that follows names a single file:“`batnpm run downlevel:native-scripts — ..BabylonNativeNightlyPlaygroundRelWithDebInfoScriptsbabylon.max.js“`So the refill is a glob and the downlevel is an allowlist of one. Anybundle added to the Native script set later gets refilled from thesnapshot and then executed **un-downleveled**, which on Chakra surfacesas a parse error at load with nothing pointing at the cause.This passes the directory instead. `scripts/downlevelNativeScripts.mjs`already walks a directory and selects files itself with`/^babylon.*.js$/i` — the same set the refill loop uses — so no changeto the script is needed.### Please note: this is not a pure no-opSix bundles are currently refilled from the snapshot but neverdownleveled, and this makes them transpiled too. Syntax actually presentin each bundle on the CDN today:| bundle | downleveled today | `?.` | `#priv` | `**` | `async` |`function*` ||—|—|—|—|—|—|—|| `babylon.max.js` | **yes** | 19 | 2 | 74 | 1 | 631 || `babylonjs.loaders.js` | no | 2 | 0 | 0 | 0 | 148 || `babylonjs.serializers.js` | no | 2 | 0 | 0 | 0 | 62 || `babylonjs.addons.js` | no | 1 | 0 | 6 | 0 | 17 || `babylonjs.materials.js` | no | 0 | 0 | 3 | 0 | 14 || `babylon.gui.js` | no | 0 | 0 | 0 | 0 | 18 || `babylonjs.proceduralTextures.js` | n/a (not yet shipped) | 0 | 0 | 0| 0 | 0 |All seven are emitted at an ES2015 target, so transpiling them is theintended direction rather than a workaround — but it is a behaviorchange, and it costs some CI time. Flagging it explicitly rather thandescribing this as a no-op.### VerificationRan the existing script against a directory laid out like the artifact:“`babylon.max.js -> downleveled (var / fonction / Math.pow)babylonjs.proceduralTextures.js -> downleveled (var / fonction)babylon.max.js.map -> untouched (.js anchor excludes maps)earcut.min.js -> untouched (not babylon*)ammo.js -> untouched (not babylon*)““ci-monorepo.yml` still parses as YAML.### ContextPrompted by BabylonJS/BabylonNative#1823, which adds`babylonjs.proceduralTextures.js` to the Playground script set. Perreview there, this needs to land first: naming the new file on this sidewould fail until it exists in the Native artifact, whereas globbing thedirectory is correct both before and after.Co-authored-by: Branimir Karadzic <[email protected]>Co-écrit par: Copilot <223556219+[email protected]>Copilot-Session: 88569c10-a7ff-4373-9a58-afa9c68b8c09, GitHub
- Make the glTF loader's unique root url actually unique (#18798)[Created by Copilot on behalf of @bghgary]Correctifs #18788## ProblemTwo glTF/GLB files loaded from `data:` urls could render each other'sembedded textures. The load resolves and nothing is logged, so it lookslike a random per-page-load glitch rather than a failure.`_uniqueRootUrl` falls back to a millisecond timestamp whenever there isno usable file name, and that is the only thing distinguishing the imageurls a file synthesizes for its embedded images. Two files loaded in thesame millisecond produce identical urls, and `BaseTexture._getFromCache`matches on url alone, so the second file gets the first file's textureand its own decoded bytes are dropped.## Worth a look- The issue suggests naming `data:` sources instead. That fixes onesource kind indirectly, still leaves `file:` root urls colliding(drag-and-drop, Inspector — they take the timestamp branch whatever thefile name), and pushes a GUID into the glTF validator's `uri` and theloader's log. Fixing the timestamp covers every source and keeps theGUID inside the synthesized url, where nothing shows it to the user.- The `file:` test drives `GLTFFileLoader` directly: producing thatshape through `SceneLoader` needs a `File`, and the node testenvironment has no `FileReader`.- Tests pin `Date.now`; without it the loads can straddle a millisecondand pass while the bug is present.## VerificationAll three tests fail before the change and pass after. The `file:` testalso fails under the issue's suggested fix, which is what separates thetwo approaches. 516 tests / 39 files pass across the loaders and coreLoading suites., GitHub
- [KTX2 Decoder] Fix Zstd-compressed UASTC textures failing to load (bytesPlane[0] = 0) (#18793)Fixes a regression from #18740 where KTX2 textures with Zstdsupercompression fail to load.Forum report:https://forum.babylonjs.com/t/failed-to-load-ktx2-texture-data-used-zstandard-zstd-compression/63871## Root causePR #18740 changed the per-image byte length formula in `ktx2Decoder.ts`to:“`tsMath.ceil(levelWidth / blockWidth) * Math.ceil(levelHeight / blockHeight) * bytesPlane[0]“`The [KTX2 spec DFD for SupercompressedData](https://registry.khronos.org/KTX/specs/2.0/ktxspec.v2.html)contains a normative backwards-compatibility note:> Previous document revisions required `bytesPlane[0-7]` to be set to 0to indicate an *unsized format*. **For the foreseeable future softwaremust be able to handle such KTX files.**KTX-Software (the reference encoder) writes `bytesPlane[0] = 0` forZstd-compressed UASTC files — confirmed by the repo's own test fixtures(`sample_uastc_zcmp.ktx2`, `testalpha_uastc_zcmp.ktx2`). With`bytesPlane[0] = 0`, the formula produces 0 and the transcoder receivesan empty buffer.The old code accidentally worked because it stored the Zstd-decompressed`Uint8Array` directly in `levelDataBuffer`, and the`Uint8Array(typedArray, offset, length)` constructor overload ignoresoffset/length and copies the whole array.## FixWhen `bytesPlane[0]` is 0, fall back to `levelUncompressedByteLength /(layerCount * faceCount)` instead of the block-based formula.## Tests2 new regression tests covering single-layer and multi-layerZstd-compressed files with `bytesPlane[0] = 0`. Both fail without thefix and pass with it. Tous 8 KTX2 decoder tests pass.Co-authored-by: Copilot App <223556219+[email protected]>Copilot-Session: aad93aa8-61cd-414f-a6c4-b73b520c9959, GitHub
- Inspecteur v2: sort particle gradients before refresh (#18794)*This PR was created by the create-pr skill.*Inspector v2 renders a sorted copy of particle gradients, but positionedits mutate the particle system's owning array without reordering it.When a stop crosses a neighbor, `forceRefreshGradients()` can thereforeconsume stops in the wrong order.This change sorts the owning gradient array before refresh for Inspectorv2 edit callbacks and adds focused regression coverage. Discovered whilereviewing #18787; this fix is independent and targets `master`.## Validation- `npm test -w @dev/inspector` (80 tests passed)- `npm run compile -w @dev/inspector`- Focused Prettier and ESLint checks for changed files- Repository-wide `format:check` currently reports 25 unrelatedpre-existing files.- The full unit suite also encounters unrelated Windows tree-shakingpath failures, generated shader availability failures, and loadertimeouts;- Inspector v2's complete package suite passes.———Co-écrit par: Vicente Cartas Espinel <[email protected]>Co-écrit par: Copilot <223556219+[email protected]>, GitHub