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,725 fourches.
26,329 étoiles.
22 questions ouvertes.
commits récents:
- Add dependency review workflow (#19149)> 🤖 *This PR was created by the create-pr skill.*## SummaryAdds `.github/workflows/dependency-review.yml`. On every pull request itcompares the dependency graph of the base and head commits. If the PRadds a dependency with a known **high or critical** vulnerability, thecheck fails.The goal is to make the `dependency-review` check a required statuscheck on `master`. A **disabled** ruleset ("Require dependency review")is prepared separately. A maintainer can enable it once this workflowhas been merged and is running reliably.## Workflow details- **Trigger**: `pull_request` for every PR, with no path filters.There's no `merge_group` trigger because the repo doesn't use a mergequeue.- **Runner**: GitHub-hosted `ubuntu-latest`, with a 10-minute timeout.- **Permissions**: the workflow sets `permissions: {}`, and the job onlygets `contents: read`. There are no secrets, PATs, or write scopes, andno `pull_request_target`.- **Pinned actions**, using verified full commit SHAs:- `actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1` (v7.0.1),with `persist-credentials: false`-`actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294`(v5.0.0)- **Policy**: `fail-on-severity: high`, `fail-on-scopes: runtime,development, unknown`, `license-check: false`. There's no`continue-on-error`, no warn-only mode, and no allow-lists.- **Lower-severity visibility**: the action leaves advisories below thefail threshold out of its report. A non-blocking step reads thedependency-graph compare API and lists any newly added **low/moderate**advisories in the job summary, with a count-only warning annotation.That step never fails the job.- The workflow installs nothing and runs no repository scripts, builds,or tests.## Scope and limitations- It only checks **dependency changes introduced by a PR**. It doesn'tscan or fix the existing vulnerability backlog.- It relies on GitHub Advisory Database data. It **doesn't detectmalware** and can't catch vulnerabilities that haven't been disclosedyet.- Coverage: the repo uses npm only (root `package-lock.json` andworkspace `package.json` files), and the dependency graph covers all ofthem.- Fork PRs need maintainer approval before workflows run, per theexisting Actions setting, so the check shows up after approval.## Validation- `actionlint` passes.- I dry-ran the lower-severity report script against the real compareAPI (`fc791e4c…d58297f7`). It reported 3 low/moderate advisories andexited with 0.- I haven't published a deliberately vulnerable dependency change. Thehigh/critical failure path is the action's documented behavior.Co-authored-by: Copilot App <223556219+[email protected]>, GitHub
- Native: support alpha-to-coverage (#19148)Babylon Native ignored `setAlphaToCoverage`: `ThinEngine`'simplementation only records the flag when there is no `_gl`, so nothingreached the native engine. Scenes using alpha-to-coverage (for examplethe "Alpha-to-coverage transparent overlap" visual test, `#M4GBLK#0`)rendered with ordinary blending instead.Changes:- `ThinNativeEngine` overrides `getAlphaToCoverage` and`setAlphaToCoverage`. The setter skips redundant calls and encodes`COMMAND_SETALPHATOCOVERAGE` only when the native runtime exposes it, soolder runtimes keep working.- `nativeInterfaces.ts`: adds the optional `COMMAND_SETALPHATOCOVERAGE`.- Unit tests for the new command encoding.The native side is in BabylonJS/BabylonNative (link below). That PR alsoexports `ALPHA_REPLACE_COLOR`, which `nativeHelpers.ts` already useswhen the runtime provides it; until then it falls back to`ALPHA_COMBINE`.Tested with BabylonNative on macOS (Metal): the alpha-to-coverage visualtest now matches its reference (it was 27% off), and all 851 enabledvisual tests still pass.———Co-écrit par: Branimir Karadzic <[email protected]>Co-écrit par: Copilot <223556219+[email protected]>Copilot-Session: 5a2ca4f4-15a2-4ad1-8a64-9dad061e773dCopilot-Session: 7b64bf64-2ec3-499d-bf8a-c8cc0b066e4f, GitHub
- Gaussian Splatting: back streaming atlases with render targets on Native (#19144)**Depends on #19142** (stacked on it; merge #19142 first). The firstcommits in this PR belong to #19142.## Summary`_createMrtAtlas`, `_createShMrtAtlas` and `_createRotMrtAtlas` returnedearly whenever the engine had no WebGL context and wasn't WebGPU. Thatcheck is meant to skip NullEngine, but it also skipped Native, whichdoes support multiple render targets.Streaming parts in a compound mesh therefore had no atlas to decode intoon Native. The work buffer's MRT passes found a null target, and thestreamed parts never appeared.The check is now a single `_supportsRenderTargetAtlas()` helper thatalso accepts Native when the engine advertises MRT support(`getCaps().drawBuffersExtension`). NullEngine is still skipped,including when it runs inside a Native runtime.## Verification- Ran the BabylonNative validation suite on macOS with Metal andJavaScriptCore, using a locally built bundle. **Gaussian Splatting LODCOMPOUND** goes from 75% different to 0.29%. It also needs a BabylonNative fix that treats scissor as global state across framebuffer binds(BabylonJS/BabylonNative#2075), because the work buffer enables thescissor before binding the atlas. The full suite has no regressions.- Unit test: with `_native` defined before import and a NullEnginescene, `reserveStreamingPart` keeps its bookkeeping and creates no MRTatlas.No reference images or tolerances changed.———Co-écrit par: Branimir Karadzic <[email protected]>Co-écrit par: Copilot <223556219+[email protected]>Copilot-Session: 5a2ca4f4-15a2-4ad1-8a64-9dad061e773dCopilot-Session: 7b64bf64-2ec3-499d-bf8a-c8cc0b066e4f, GitHub
- Native: sort Gaussian splat ranges and compound parts with sortSplatIndices (#19141)## SummaryBabylon Native has no sort worker. `Native.sortSplats` sorts every splatwith the mesh world matrix, which breaks two cases:- With a range filter (LOD), splats outside the active ranges weresorted too, and the active ones were not sorted correctly.- Compound parts were sorted with the mesh world matrix instead of theirown part matrix.When `Native.sortSplatIndices` is available, `GaussianSplattingMeshBase`now uses it. Like the sort worker, it sorts only the active sourceranges and applies each part's world matrix. `Native.sortSplats` isstill used with older Babylon Native builds that don't have the newfunction.The native function is added in BabylonJS/BabylonNative#2074.## Verification- Added unit tests to `gaussianSplatting.nativeDisableDepthSort.test.ts`covering the dispatch, the range intervals and the per-part matrices.10/10 pass.- Ran the BabylonNative validation suite on macOS with Metal andJavaScriptCore, using a locally built bundle. Together with the partialSH upload fix, **Gaussian Splatting LOD**, **Compound IncrementalUpdate** and **Compound No SH then Full SH** now pass. The full suitehas no regressions.No reference images or tolerances changed.———Co-écrit par: Branimir Karadzic <[email protected]>Co-écrit par: Copilot <223556219+[email protected]>Copilot-Session: 5a2ca4f4-15a2-4ad1-8a64-9dad061e773dCopilot-Session: 7b64bf64-2ec3-499d-bf8a-c8cc0b066e4f, GitHub
- Support ALPHA_MIN/ALPHA_MAX on NativeEngine (#19139)## Problem`getNativeAlphaMode` threw `Unsupported alpha mode: 18/19` for`ALPHA_MIN` and `ALPHA_MAX`, so any feature that uses them failed onBabylon Native.For example, `iblShadowsVoxelRenderer` uses `ALPHA_MAX`. Because ofthis, the Gaussian Splatting IBL-shadow validation tests are excluded inBabylon Native.## FixWebGL and WebGPU implement these modes as ONE/ONE blend factors plus aMIN/MAX blend equation. NativeEngine now does the same:- `getNativeAlphaMode` maps `ALPHA_MIN`/`ALPHA_MAX` to the native`ALPHA_ONEONE_ONEONE` mode.- `setAlphaMode` sets the matching equation via `setAlphaEquation`, andrestores `ADD` when switching away from MIN/MAX.## Testing- New unit test in `thinNativeEngine.test.ts`. It fails without the fix(`Unsupported alpha mode: 19`).- Babylon Native (Win32 Vulkan), with the bundle patched equivalently:all 7 "Gaussian Splatting … IBL Shadows" validation tests pass. Pixeldifferences are 0.007%–0.58% against a 2.5% threshold. One native-sidefix was also needed and is being sent to Babylon Native separately.Co-authored-by: Copilot <223556219+[email protected]>Copilot-Session: 7b64bf64-2ec3-499d-bf8a-c8cc0b066e4f, GitHub