Babylon.js es un framework completo para crear juegos 3D con la ayuda de HTML5 y WebGL basado 100% en JavaScript, desarrollado por programadores de Microsoft. Funciona adecuadamente en Firefox y Chrome y es compatible con las siguientes características:
- Gráficas completas de escenas, luz, cámaras, materiales y texturas
- Motor de colisiones
- Selección de escenas
- Antialiasing
- Motor de animaciones
- Sistemas de partículas
- Sprites y capas 2D
- Motores de optimización
- Materiales estándar a nivel pixel
- Niebla
- Blending alpha
- Pruebas alpha
- Billboarding
- Modo de pantalla completa
- Mapas de sombras y mapas de variación de sombras
- Rendereo de texturas
- Texturas dinámicas (canvas)
- Texturas de video
- Cámaras (perspectivas y ortogonalidad)
- Clonación de mesh
- Meshes dinámicos
- Mapas de altura
- Las escenas de Babylon puede convertirse en .OBJ, .FBX, .MXB
- Exporta a Blender
A continuación tenéis un vídeo curso bien completo muy bien explicado en español de Oscar Uh Pérez (Develoteca) que nos da todos los conocimientos necesarios para meter las manos en la masa.
Tambien os dejo unos tutoriales interesantes de Julian Chenard para empezar con Balylon.js en el siguiente enlace: http://www.pixelcodr.com/
Más tutoriales: http://www.babylonjs-playground.com/
Repository
Babylon.js is a powerful, beautiful, simple, and open game and rendering engine packed into a friendly JavaScript framework.
https://github.com/BabylonJS/Babylon.js
3,725 forks.
26,329 stars.
22 open issues.
Recent commits:
- 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 <[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-authored-by: Branimir Karadzic <[email protected]>Co-authored-by: Copilot <[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-authored-by: Branimir Karadzic <[email protected]>Co-authored-by: Copilot <[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-authored-by: Branimir Karadzic <[email protected]>Co-authored-by: Copilot <[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 <[email protected]>Copilot-Session: 7b64bf64-2ec3-499d-bf8a-c8cc0b066e4f, GitHub