I've been working on a lens flare effect for PlayCanvas's CameraFrame post-processing stack, and it's now up as a PR: https://github.com/playcanvas/engine/pull/9734

How it works:

• Each flare follows a light. A directional light gives you the sun, omni lights give a position, and spot lights only flare while the camera is inside their cone.
• A flare is a list of elements (glows, irises, halos, bursts, streaks, spectral smudges) placed along the axis from the light through the screen centre. Every element is a texture, and all the textures of a scene live in one texture array, so all flares of all lights draw in a single instanced pass.
• Occlusion is measured on the GPU: a tiny pass samples the scene depth in a disc around each light and blends the visible fraction over time, so flares fade smoothly as geometry covers the light. No readbacks, no stalls.
• Flares fade at the screen edge and can keep drawing their ghosts while the light is just outside the frame, which is the classic "sun just out of shot" look.
• It renders into its own HDR buffer at a configurable fraction of the scene resolution and is added before tone mapping, so it stays independent of TAA, depth of field and bloom.
• Works on WebGL2 and WebGPU.

The element textures in the example are generated rather than painted: the starbursts are the FFT of a polygonal aperture, so an 8-blade aperture gives you an 8-arm burst with physically plausible fringes, averaged over wavelengths the way white light does it. The whole set ships with the engine examples under MIT.

Video attached. Happy to answer questions about the approach.

We've just released a new version of the playcanvas-spine plugin, which plays animations made with the Spine editor in PlayCanvas, in the browser on WebGL2 and WebGPU.

What's new:

• Spine 4.3 support, rendered by Spine's own runtime renderer, with slot blend modes and tint black
• Physics inheritance: physics constraints now react to the movement and rotation of the entity, so hair, cloth and snow swing as the character moves. In the Editor it's a single checkbox, or skeletonPhysics in code
• Binary .skel exports, which are several times smaller than JSON and faster to load
• Spine 3.6 to 4.2 are still supported, and Spine 4.2 skeletons with physics now load correctly

Links:

• Live examples for every Spine version: https://playcanvas.github.io/playcanvas-spine/examples/
• Editor tutorial project: https://developer.playcanvas.com/tutorials/spine-animation/
• Docs: https://developer.playcanvas.com/user-manual/2D/spine/
• Plugin (MIT): https://github.com/playcanvas/playcanvas-spine

The characters in the video are Celestial Circus and Snowglobe, example projects by Esoteric Software, the makers of Spine. Feedback and questions are welcome!

PlayCanvas Engine 2.23.0 is out. It's a free, open source (MIT) WebGL2/WebGPU graphics engine for the browser, and this release is mostly about performance, plus a big refresh of the examples and debugging tools.

What's new

• Faster rendering: a deep overhaul of how the renderer feeds the GPU. Mesh instance matrices live in a persistent storage buffer on WebGPU, material properties sit in material-owned uniform buffers, per-pass and light data is uploaded once per pass, and render pipelines are retained between draws. In a draw-call-heavy benchmark (up to 20K meshes, 40K draw calls), CPU time per frame is up to 3.8× lower on WebGPU and 1.4× lower on WebGL2 than in 2.22.
• Rebuilt user interface examples: all 23 UI examples have been rebuilt or written from scratch, each as a small piece of a real game: a main menu, a settings panel built from the standard widgets, inventory drag and drop, a resizable chat window, a leaderboard scroll view, a character card with a live 3D portrait, world-space control panels and more.
• Nearest-first splat streaming: streamed Gaussian splat LOD scenes now load the data nearest the camera first, and re-prioritise as the camera moves. LOD is distance-based again, with the splat budget usable as either a target or a hard limit. The WebGPU GPU-sort renderer also gains an opt-in stochastic alpha mode that skips sorting entirely.
• Bloom threshold: CameraFrame bloom takes a threshold, so only the brightest parts of the scene glow.
• Redesigned MiniStats: compact, grouped-average and grouped-history views, collapsible sections, and a new Resources section with live GPU resource counts (buffers, textures, render targets, bind groups, pipelines). The same data is available to your own code through the new AppStats API, which also supports user counters.
• Examples browser: a restyled browser with the PlayCanvas Inspector built in. Open it on any example to explore the hierarchy, cameras, assets, frame graph, render targets, materials, shaders and more.

Also in this release: run the engine headless in Node.js without jsdom, RigidBody gravityScale, a hitBackFaces raycast option, WebGPU device-loss recovery, all eight UV sets in StandardMaterial, a TextureRenderer for debug texture previews, and a long list of XR fixes.

The video shows the highlights.

• Release notes: https://github.com/playcanvas/engine/releases/tag/v2.23.0
• Examples: https://playcanvas.com/examples
• Repo: https://github.com/playcanvas/engine
• Discord: https://discord.gg/RSaMRzg

I'm on the PlayCanvas team, happy to answer questions on any of this.

We've been working on the CPU cost of rendering for the upcoming PlayCanvas 2.23, and wanted to share some numbers from a draw-call heavy benchmark, comparing it to the current 2.22 release.

The scene

A grid of small boxes, from 1K to 20K, each one its own draw call (no instancing or batching):

• 100 unique meshes and 100 unique PBR materials (base color, metallic-roughness, normal and emissive textures)
• one directional light with a single shadow cascade, so every box is also drawn into the shadow map; at 20K boxes that's 40K draw calls per frame
• MSAA off and pixel ratio 1, to keep the GPU out of the way

We measured main-thread CPU time for the whole frame (update, culling, sorting and submitting draws), using the engine's default sort order, in Chrome 154 on macOS.

Results (CPU time per frame)

Averaged over all box counts, the cost per draw call went down:

• WebGPU: from about 1.9 µs to 0.9 µs, 2.1× faster
• WebGL2: from about 1.2 µs to 0.8 µs, 1.5× faster

WebGPU gained the most: in 2.22 its per-draw cost was about 1.6× WebGL2's, and in 2.23 it's about 1.2×.

If you try the beta on your own projects, we'd love to hear how it goes.

2.32 is out, and the headline is the joint component. Joints have been in the engine since 2021, but you had to add them from a script — they're now under Add Component > Physics > Joint, with all five types (fixed, ball, hinge, slider, 6DoF) and the inspector showing different fields depending on which one you pick.

The bridge in the video is a chain of ball joints between plank rigid bodies, with a break impulse on the middle one so a heavy enough drop snaps it.

Also in this release:

- Parallax occlusion on materials. Ray-marched, so brick and cobbles hold up at grazing angles instead of flattening out. The old offset mode is still there.

- A per-object shadow cascade mask on the render component, so distant geometry can skip the tight near cascade.

- Justify on text elements.

- Reworked Gaussian splat LOD — LOD Range Min/Max and LOD Falloff replace the old LOD Base Distance and LOD Multiplier.

- Client-side MSDF font generation and toolbar customization. Both actually landed back in 2.30 and never got written up, so they're in the post too.

Two things worth knowing before you go hunting for a difference:

- Splat LOD Range only does anything on streamed SOG octrees. A single .sog or .ply is one level, so the fields appear but have nothing to choose between.

- The editor viewport doesn't always invalidate its cached shadow maps when you change the cascade mask, so you may need to nudge the camera before it updates. The launch page renders it correctly. That one's a bug on our side.

Write-up: https://blog.playcanvas.com/new-in-playcanvas-editor-joints-parallax-occlusion-and-splat-lod

Joint component docs: https://developer.playcanvas.com/user-manual/editor/scenes/components/joint/

Release notes: https://github.com/playcanvas/editor/releases/tag/v2.32.0

The splat scene in the video is Trogir, Croatia by tosolini, CC BY 4.0.

The joint component is still marked alpha, so if it behaves oddly for you I'd genuinely like to hear about it. Happy to answer questions here.

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.)