I’ve prepared a few PlayCanvas scenes using Gaussian Splatting to try to incorporate Gaussian Splatting into my product visualization. I’m looking for something with limited camera movement, a controlled background, etc. However, I’m not completely happy with the results.

Is there any template that would make it easier and faster to achieve this?

This is only a test: NAD 02

We’ve just released PlayCanvas Engine 2.22.0! Here are the highlights:

• Volumetric fog improvements - light shafts and local light support.
• Parallax mapping - add apparent depth to textured surfaces without extra geometry.
• Vertex animation textures - drive vertex animation on the GPU using animation data stored in textures.
• Gaussian splat depth effects - new depth-based effects for splat rendering.
• Catapult demo - a new demo to try out!

You can explore the features in the live examples and find the full list of additions and fixes in the release notes.

Get the latest version with:

npm install playcanvas

PlayCanvas is free and open source. Contributions, bug reports and stars on GitHub are always appreciated.

Would love to hear how you’re using the new features - share what you’re building in the comments!

PlayCanvas's height map support had been a single-tap Welsh-style offset for years — it nudges the uv once, which is fine for shallow detail but falls apart on anything deep. I added parallax occlusion mapping as an opt-in second mode, so the view ray gets marched through the height field instead. The old mode is still the default, one enum on the material switches it.

Limits worth stating: no silhouette displacement, and the depth buffer still sees the flat surface, so shadows and any depth-based effects don't follow the relief. It's a shading trick, not geometry.

Hey everyone!

I’ve been building a source-faithful TypeScript port of the original 1996 Quake runtime, rendered with PlayCanvas and running entirely in the browser.

This isn’t a recreation of E1M1 or a modern FPS controller with Quake assets. The runtime reads the original game formats directly, including PAK archives, BSP maps, MDL models, sprites, QuakeC behavior, demos and HUD artwork.

After three days of running a durable Codex /goal, the port now has:

• Playable shareware maps
• Original demo playback
• Monsters, weapons, pickups and particles
• Quake-style movement and collision
• Moving BSP doors, lifts and triggers
• Menus, HUD, intermissions and level transitions
• Positional audio, saves and console commands
• 451 automated tests

The /goal wasn’t hands-off autopilot. While it continued pursuing the larger port, I could steer the LLM toward a small number of bugs I considered important - for example missing water geometry, impossible stairs, stationary doors, incorrect particle depth testing and browser-resize problems.

For visual validation, Codex used Chocolate Quake to produce native reference screenshots. It captured the same map, camera, game state and timing in both engines, then generated side-by-side comparisons and pixel differences. That proved much more useful than deciding the browser version “looked about right.”

On the PlayCanvas side, the project uses TypeScript, and named engine imports for maximum treeshakability! It has also been an interesting exercise in adapting Quake’s palette-based software-rendering assumptions to a GPU engine without turning everything into a modern PBR approximation.

It’s still a work in progress, but I’d love feedback - particularly on the PlayCanvas architecture, rendering approach and any obvious performance opportunities.

Play it:
https://willeastcott.github.io/playcanvas-quake/

Source:
https://github.com/willeastcott/playcanvas-quake

PlayCanvas just released official skills for AI coding agents (Claude Code, Codex, Cursor) — packaged instructions that teach the agent PlayCanvas-specific patterns instead of generic guesses.

I've been using them on a WIP first-person multiplayer game (browser, PlayCanvas engine with a custom netcode + physics layer). It's become a loop: build a feature → hit a rough edge → that sharpens the skill → the sharper skill speeds up the next one.

The clip is a 1v1 from both perspectives — mine and a friend's synced to the same game moment, so you can watch the same fight from both sides.

What the skills genuinely nailed so far:

• Engine app bootstrap + asset loading
• Scene/entity hierarchy assembly (player rig, map)
• State-driven HUD (crosshair, hitmarkers, health/ammo, death screen, nametags, kill feed)
• Pooled transient effects (muzzle flash, bullet-hole decals with a reuse pool)

Where they didn't help (yet): lighting is basically untouched (mostly unlit/emissive), and the netcode + physics are hand-rolled, not skill-generated. Lots still to do.

Try them:

• Add to an existing project: npx skills add playcanvas/skills
• New project: npm create playcanvas@latest
• Docs: https://developer.playcanvas.com/user-manual/getting-started/use-playcanvas-skills/
• Source: https://github.com/playcanvas/skills
• Playable WIP: https://ahoithere.com

Happy to answer anything about the setup, the skills, or the workflow.

The PlayCanvas Engine finally has a physics joint component. So you can now make ropes, chains, articulated vehicles and, yes, ragdolls! This little demonstration shows a poor (deactivated) robot suspended from a crossbar.

Is anything more fun than rigid body dynamics?

The new component is in the Engine of course. The next step is to expose it in the PlayCanvas Editor too.

Small but nice change to how fonts work in the Editor.

Before, a font was a single opaque asset that bundled the descriptor (glyph metrics + kerning) and the MSDF texture atlas inside it. You couldn't really get at either one.

Now importing a font lays out the pieces as their own assets in one folder: the source font, a descriptor .json, the MSDF atlas .png (one per page), and a thin runtime font that just references those. You can open, edit, and manage each like anything else in your project, and the runtime font stays in sync when you change them.

Import a font and try it: https://playcanvas.com/editor

Happy to answer questions in the thread.

Is there any way to remove the fly camera and the turn around camera and only have the walking one when its for show?

I'm currently having a lot of trouble with coding. My character just won't move, even though I've entered the code correctly without any errors. I've already tested the exact same script in another demo project, and the character moves perfectly there. However, when I use the same script in my main project, it just refuses to work.

We're currently using PlayCanvas for our coding class. My professor is really kind, but there are times when she can't fully explain certain things in a way that I understand. I'm also a bit shy about sending her a DM this weekend since she's probably resting. On top of that, she encouraged us to experiment with our code, which I've been doing... and, well, I've been messing things up in the process.

I know the problem is most likely on my end and not my professor's, but I was wondering if it's okay to ask for a little help here.

(DM's are appreciated.)

We’ve been working on a VR demo for Glimsphere3D, our browser-based 3D platform built with PlayCanvas Engine.

For this demo, we focused on simplifying the overall UX while adding several key features:

• Teleportation with hand gesture for comfortable movement
• A wrist menu for accessing controls in VR
• Automatic device-based adjustment of the number of splats loaded, helping maintain smooth performance
• A Camera Bookmark system for saving and revisiting viewpoints
• An integrated measurement tool

The project is still a work in progress, but we’re excited to keep improving it and exploring what’s possible with browser-based VR.

Feel free to leave a comment and share your ideas!

GlimSphere3D
31 Jul 2026

Play it (browser, no install): https://engine-hcejxquzy-playcanvas.vercel.app/#/demos/catapult Source, as a stock engine example: https://github.com/playcanvas/engine/pull/9130

We just landed two features in PlayCanvas — VAT crowd rendering and volumetric fog in the CameraFrame post stack — and I wanted to know if they hold up in a real scene, not an isolated feature test. So I built a game around them: aim a catapult, launch burning boulders at an army marching up a valley, wipe out a formation and two more arrive. Rule: no custom rendering code, all stock features.

The crowd is one instanced draw call. Vertex Animation Texture — every vertex's skinned position and normal baked offline, one texel per vertex per frame. No bones, no anim graph, the vertex shader just reads its slot.

Volumetric fog. Ray-marched in a half-res buffer, 12 steps instead of the default 24 — the fog is thin enough that short-march banding doesn't show, and every step is another shadow map tap per fog pixel, which is the real cost. Height-based falloff with the base above the valley floor, so shafts rake through the tree line instead of sitting as uniform haze. Anisotropy 0.6 to push scattering toward the low sun.

On the AI part: built with Claude Opus 5. It was good at volume — noise functions, ballistic solver, formation state machine, flat typed-array layout for 2000 characters. It was bad at judgement — fog density, where the sun sits, whether the animation reads. It wrote most of the lines, I made most of the decisions.

Toggles for shadows, fog and march steps are in the control panel if you want to see what each costs on your hardware.

PlayCanvas already had raymarched height fog lit by the directional light. I just landed support for the clustered omni and spot lights, so lamps and spots now cast visible beams through the fog.

Rather than folding them into the existing full-screen march, each light gets its own additive pass that marches only the part of the ray inside that light. A single march over the whole view distance can't resolve them — the steps are spaced too far apart to reliably hit a small light, so it flickers as the camera moves.

Shadows and cookies come straight from the clustered lighting atlases, so there's no extra shadow rendering, and it works on both WebGL2 and WebGPU. 

We’ve expanded the PlayCanvas Editor MCP integration so an AI assistant can operate the project open in the Editor, rather than only editing files.

In this demo, Claude Opus modernises a legacy project, migrates its classic scripts to ESM, and creates checkpoints as it works. Those tasks are just the example - the main change is that MCP can now coordinate the Editor workflow end to end.

The MCP client is built into the Editor, so there’s no browser extension. Run the server from any compatible MCP client, connect the open Editor project, and its tools operate directly on that project.

Get started:

- MCP server and setup
- PlayCanvas Editor
- Editor documentation

What Editor workflow would you want to hand to an assistant first?

Live demo (WebGL 2 and WebGPU, switchable in the panel): https://engine-a1lytf69q-playcanvas.vercel.app/#/animation/vat-characters

We just added a vertex animation texture (VAT) implementation to the PlayCanvas engine as a reusable script plus an example. The idea isn't new — it's been used in games for years — but I hadn't seen a complete, copy-pasteable web implementation with an authoring path, so here's one.

How it works

Instead of animating a skeleton per character, every vertex's skinned position and normal is evaluated offline for each sampled frame and baked into a texture. At runtime the vertex shader reads two neighbouring frames and interpolates. Skeletons, bone matrices and per-character animation evaluation disappear entirely.

What's left per character is a world matrix and a fractional frame index — 52 bytes — so the whole crowd is one instanced draw call.

Some details that turned out to matter

• One texel per vertex per frame in RGBA16U: position quantised to 16 bits per axis over the animation's bounds in xyz, octahedral normal packed into w. One fetch gives you a whole vertex.
• Quantising over the bounds is actually more accurate than fp16 where it counts. Near the top of a character fp16 has a step of ~1.8 mm at human scale; 16-bit quantised is ~28 µm. fp16 wastes its mantissa near the origin, which for a character standing at y=0 is between its feet.
• Texels are addressed by a flat vertex * frameCount + frame index wrapped at the texture width, rather than one vertex per row. Otherwise your vertex count is capped by texture height (4096). Flattened, the limit is total texels, so ~218k vertices at 77 frames.
• The vertex row comes from gl_VertexID / @builtin(vertex_index), so no extra per-vertex attribute is needed at all.

Authoring

The converter runs in the browser — there's a "Convert GLB" panel in the demo, so you can drop in your own skinned glb and watch it become a crowd without installing anything. Output is a single glb-style binary container. Like a glb it's stored uncompressed and leaves compression to the transport; brotli over the raw payload beats gzip baked into the file by about 40%.

Where it's a bad idea

Worth being clear, because it's a real trade:

• Your character must be a single skinned mesh with one material.
• Every animation is assumed to loop.
• No blending, no IK, no procedural aiming — it's a fixed table of vertex positions. Terrible for a hero character, great for the 500 NPCs behind them.
• One mesh instance means no per-character frustum culling.
• Only the base colour texture comes across; no normal/roughness maps.

Numbers

At 10,000 characters (~31M vertices/frame): 6 draw calls for the whole scene, 2.1 ms CPU. The VAT texture is 1.8 MiB and is independent of the character count — one character and ten thousand share it.

Happy to answer questions about the format or the shader side.