Babylon.js It is a complete framework for creating 3D games with the help of HTML5 and WebGL based 100% in JavaScript, developed by programmers from Microsoft. It works properly in Firefox and Chrome and is compatible with the following features:
- Graphic scenes complete, light, cameras, materials and textures
- Motor collision
- Scene selection
- Antialiasing
- Engine animations
- Particle systems
- Sprites and 2D layers
- Optimization engines
- Standard materials at the pixel level
- Fog
- Blending alpha
- Alpha testing
- Billboarding
- Full screen mode
- Shadow maps and maps of variation of shadows
- Rendering textures
- Dynamic textures (canvas)
- Video textures
- Cameras (perspectives and orthogonality)
- Cloning of mesh
- Dynamic meshes
- Maps of time
- The scenes of Babylon can become in. OBJ, .FBX, .MXB
- Exports the Blender
Below is a video course well very well explained in Spanish fromOscar Uh Pérez (Develoteca) that gives us all the skills needed to put the hands in the dough.
Also I leave some interesting tutorials of Julian Chenard to start with Balylon.js in the following link: http://www.pixelcodr.com/
More tutorials: 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,662 forks.
25,666 stars.
23 open issues.
Recent commits:
- fix(OBJ): Guard empty vertex buffers when normals/uvs/colors are absent (#18597)When an OBJ file has no `vn` entries, the parser produces an emptynormals array. Empty arrays are truthy, so the old check`!this._handledMesh.normals` passed a zero-length buffer to the GPU,causing:> `Vertex buffer is not big enough for the draw call`**Fix:** Changed truthiness checks to `.length` checks for `normals`,`uvs`, and `colors` in `solidParser.ts`, so empty arrays are treated asabsent and normals are recomputed from geometry.**Test:** Added visualization test `OBJ empty normal` (`#26R8NS#15`)with reference snapshot `objEmptyNormal.png`.———Co-authored-by: Raymond Fei <[email protected]>, GitHub
- fix(SPLAT): Fix GSplat PLY misclassified as point cloud when both RGB and f_dc colors present (#18593)A valid Gaussian Splat PLY containing **both** `red/green/blue` (uchar)and `f_dc_0/1/2` (float) color properties was loaded as a point cloudinstead of a splat, so it rendered as plain points with no splatting.### CauseIn `splatFileLoader.ts`, the splat-detection check used a strictequality on the color-property count:“`jsconst hasMandatoryProperties = propertyCount == splatProperties.length && propertyColorCount == 3;“`When a file carries both color encodings, `propertyColorCount` is 6, so`== 3` fails and the file falls through to `Mode.PointCloud`. (Someexporters write both a precomputed RGB and the SH DC color.)### FixChanged the color check to `>= 3`:“`jsconst hasMandatoryProperties = propertyCount == splatProperties.length && propertyColorCount >= 3;“`Since the gate is `&&`-ed with `propertyCount == 11` (all mandatorysplat geometry properties), the relaxed color count only ever applies tofiles that are already full splats, with point-cloud detection isunaffected.Co-authored-by: Raymond Fei <[email protected]>, GitHub
- Fix VideoTexture not updating under WebGPU FAST snapshot rendering (#18591)> 🤖 *This PR was created by the create-pr skill.*Resolves the forum request [VideoTexture support for snapshotrendering](https://forum.babylonjs.com/t/videotexture-support-for-snapshot-rendering/63634).## ProblemOn WebGPU, a `VideoTexture` froze on its first frame as soon as **FAST**snapshot rendering was enabled — the video stopped updating on screeneven though the underlying `<video>` kept playing.## Root causeA `VideoTexture` copies the current video frame into a regular internaltexture (the one materials actually bind), and that per-frame copy isdriven from the material **bind** path (`WebGPUEngine._setTexture` calls`VideoTexture.update()`). Under FAST snapshot rendering the scene skips`_evaluateActiveMeshes` and replays recorded render bundles, somaterials are never re-bound, `update()` is never called, and the boundtexture stays frozen on the snapshot frame.A second, related issue affected **mipmapped** video textures (thecommon case — the classic video sample uses `generateMipMaps = true`):`updateVideoTexture()` generated the mipmaps on the engine's main renderencoder, and `_generateMipmaps()` calls `_endCurrentRenderPass()` whenit targets that encoder, which corrupts the recorded snapshot bundle andfroze the video even once the per-frame copy was running again.## Fix- **`Materials/Textures/videoTexture.pure.ts`** — while FAST snapshotrendering is active, drive the per-frame video update from a`scene.onBeforeRenderObservable` hook (registered WebGPU-only, when theexternal texture exists), so the video keeps playing even though thebind path is skipped. Recreating the internal (bound) texture on videoresize triggers `snapshotRenderingReset()` so the recorded bundlere-binds the new texture. The hook is removed on dispose.- **`Engines/WebGPU/Extensions/engine.videoTexture.pure.ts`** — whensnapshot rendering is enabled, generate the video mipmaps on adedicated, immediately-submitted command encoder instead of the mainrender encoder. Normal (non-snapshot) rendering keeps the original pathunchanged.## TestingPlayground (select the **WebGPU** engine):https://playground.babylonjs.com/?webgpu#NSMB74#2Toggle FAST snapshot rendering with the on-screen button (it alsoauto-enables ~1.5s after load). With the fix the video keeps playing inboth states.Validated locally against the dev build with real WebGPU (Playwright +pixel readback):- FAST snapshot ON, non-mipmapped video → updates.- FAST snapshot ON, mipmapped video → updates (previously frozen).- Negative control (per-frame hook removed) → reproduces the freeze.- Normal (non-snapshot) rendering → unchanged.———Co-authored-by: Copilot <223556219+[email protected]>, GitHub
- Decouple camera inertia glide cutoff from camera.speed (#18589)## ProblemThe inertial glide **stop threshold** (the epsilon cutoff that snaps aresidual offset to zero) was scaled by `camera.speed` on channels whosemovement magnitude does **not** scale with `speed`. Raising `speed`therefore truncated the inertia tail early without making the cameramove any faster.This is a longstanding behavior (`TargetCamera` has scaled that cutoffby `speed` since the epsilon was made configurable in #17197, and `speed* Epsilon` predates that). The recent framerate-independent camera workdid not introduce it, but made it far more visible at high refresh rates— every other part of the decay is now framerate-independent, so thiscutoff is the odd one out. Reported on the forum:https://forum.babylonjs.com/t/camera-bugs-related-to-delta-time/61001/19(FreeCamera mouse-look ease-out gets cut as `camera.speed` increases;worst at 240 Hz).## FixStop the `speed`-scaled cutoff from truncating channels whose movementmagnitude does **not** scale with `speed`:- **ArcRotateCamera** — no channel scales with `speed` (`movement.speed`stays 1; inputs use `angularSensibility` / wheel precision /`panningSensibility`). Removed `speed` from the radius getter and thelegacy radius/panning cutoffs, matching the alpha/beta cutoffs (whichthe framerate-independence port had already decoupled).- **TargetCamera / FreeCamera** — translation magnitude *does* scalewith `speed` (via `_computeLocalCameraSpeed`), so its panning cutoffstays scaled (keeps glide duration speed-invariant). Rotation does**not** scale with `speed`. Rather than just unscaling it, the legacyper-frame rotation cutoff was **removed entirely**: `_rotationEpsilon`no longer affects rotation glide termination. The movement systemalready ends the rotation glide via its own framerate-independentvelocity epsilon, and layering the old per-frame-delta snap on topreintroduced framerate dependence (the snap tests a per-frame delta,which shrinks at high refresh rates), producing the visible "cut" thatwas worst at high speed and high frame rate (forum #61001). Deferringentirely to the velocity epsilon gives the same smooth ease-out at every`speed` and refresh rate.## Compatibility- **ArcRotateCamera radius/panning** — at the default `camera.speed = 1`behavior is **identical** (`1 * epsilon === epsilon`); only non-default`camera.speed` is affected, and only by no longer truncating the inertiatail.- **TargetCamera / FreeCamera rotation** — `_rotationEpsilon` no longerparticipates in rotation glide termination (the knob still exists but isinert for this purpose). Because termination now comes from the movementsystem's velocity epsilon instead of a per-frame snap, the rotation taileases fully out rather than snapping; at `speed = 1` this means amarginally longer, smoother ease-out rather than byte-identical output.This is the intended fix for the framerate-dependent "cut", not aregression.## TestsAdded regression tests asserting the glide-out is invariant to`camera.speed` (verified failing before the fix, passing after). TheArcRotate speed-invariance helpers build a fresh camera per run andassert the glide actually terminated (rather than hitting the frame-capsafety valve), so they cannot produce false positives. All camera unittests pass.———Co-authored-by: Georgina Halpern <[email protected]>Co-authored-by: Copilot <223556219+[email protected]>, GitHub
- GS streaming lod part3 (#18588)not last part., GitHub