Progress on RTGI for WebGPU
- added MSME
- added weighted probe ray resampling
- better sky sampling via cones
- added MSME
- added weighted probe ray resampling
- better sky sampling via cones
2
6
103
Fluid simulation on WebGPU
live version: meep.company-named.com/examples/preva…
The fluid sim is cascaded with a global fallback running on the GPU with dynamic obstacles. There are 4 obstacles here including the "ground" box.
The particles are GPU driven, they just sample the fluid volume
live version: meep.company-named.com/examples/preva…
The fluid sim is cascaded with a global fallback running on the GPU with dynamic obstacles. There are 4 obstacles here including the "ground" box.
The particles are GPU driven, they just sample the fluid volume
5
15
175
Fire in WebGPU
live link: meep.company-named.com/examples/bonfi…
* Fluid simulation
* Volumetric lighting (particles receive all light contribution)
* Order Independent Transparency
* GPU-driven particle simulation
live link: meep.company-named.com/examples/bonfi…
* Fluid simulation
* Volumetric lighting (particles receive all light contribution)
* Order Independent Transparency
* GPU-driven particle simulation
4
1
17
Tree generator - WebGPU
* reworked skinning to be more physically accurate
* added stubs and knots
* added roots
* minor improvements to branch and leaf placement - better adherence to tree biomechanics
And yes, the tree is rigged and skinned and the animation is 100% procedural d sim
* reworked skinning to be more physically accurate
* added stubs and knots
* added roots
* minor improvements to branch and leaf placement - better adherence to tree biomechanics
And yes, the tree is rigged and skinned and the animation is 100% procedural d sim
16
22
355
did more work on the tree generator for WebGPU
* more biomechanically accurate branching, fewer very long thin branches
* branch growth takes gravity and material into account now
* branches use full collision resolution, previously it was statistically improbable, now it's scence parameter to leaves, so we can cover different phases of growth, especially useful for autumn and for young leaves (spring)
* leaf cards are now generated with variants, so leaves don't all look the same
* placement optimization, much fewer cards and branches required for the same overall coverage/volume, ~50% fewer triangles overall
I don't think realism is something I will chase relentlessly on this, as this is intended for real-time applications, to generate foliage for games and interactive experience, not so much for botanical simulations. But having a principled generator costs nothing at runtime, so I'm going as far as it makes sense to.
Right now a tree takes anywhere from 50ms to about 1s to generate, depending on the size and other configuration parameters, which is entirely reasonable for my goals.
* more biomechanically accurate branching, fewer very long thin branches
* branch growth takes gravity and material into account now
* branches use full collision resolution, previously it was statistically improbable, now it's scence parameter to leaves, so we can cover different phases of growth, especially useful for autumn and for young leaves (spring)
* leaf cards are now generated with variants, so leaves don't all look the same
* placement optimization, much fewer cards and branches required for the same overall coverage/volume, ~50% fewer triangles overall
I don't think realism is something I will chase relentlessly on this, as this is intended for real-time applications, to generate foliage for games and interactive experience, not so much for botanical simulations. But having a principled generator costs nothing at runtime, so I'm going as far as it makes sense to.
Right now a tree takes anywhere from 50ms to about 1s to generate, depending on the size and other configuration parameters, which is entirely reasonable for my goals.
Foliage in WebGPU
* tree generation
* wind simulation
3
1
35
Can't say off the top of my head, a lot of what I see visually suggests we followed many of the similar ideas. I can see some unacceptable artifacts, but I'm sure those can be ironed out.
The big things that I can see from perspective of my tool:
+ better branching
+ better attachments ding (branches and the trunk flare out)
+ knotting (trees are not tubes)
+ bark aging (not the same texture across the entire tree)
But honestly, thank you for pointing this project out to me, it looks pretty impressive. And the it seems to have support for creepers which I don't.
The big things that I can see from perspective of my tool:
+ better branching
+ better attachments ding (branches and the trunk flare out)
+ knotting (trees are not tubes)
+ bark aging (not the same texture across the entire tree)
But honestly, thank you for pointing this project out to me, it looks pretty impressive. And the it seems to have support for creepers which I don't.
1
0
2
@drhindsight Not an expert in firearms, but here's a real weapon called "Dakota T-76 Longbow".
Names are hard, man!
Names are hard, man!
1
0
2
Activision's CALDERA scene in WebGPU in the Browser
- 216,122,609 source triangles
- 487,465 instances
- 116,513 unique meshes
- 216,122,609 source triangles
- 487,465 instances
- 116,513 unique meshes
5
0
32
Added ballistic audio simulation to my cute game.
There are 114 guns in the game, so I wanted them to sound a bit different.
Being an engineer, the solution is, of course: engineering.
There are 3 sounds that make up a shot:
* muzzle blast (propellant)
* ballistic crack al action (the gun parts)
So, each gun gets a set of 3 sounds, each having a bunch of filters applied based on weapon's:
* muzzle velocity (no different ammo types per gun in my game)
* bore size
* barrel length
* muzzle device ("none" is an option too)
* action type
* propellant type
* propellant mass
Way to over-engineer things, but it costs nothing at runtime and guns have distinct "voices" as a result.
There are 114 guns in the game, so I wanted them to sound a bit different.
Being an engineer, the solution is, of course: engineering.
There are 3 sounds that make up a shot:
* muzzle blast (propellant)
* ballistic crack al action (the gun parts)
So, each gun gets a set of 3 sounds, each having a bunch of filters applied based on weapon's:
* muzzle velocity (no different ammo types per gun in my game)
* bore size
* barrel length
* muzzle device ("none" is an option too)
* action type
* propellant type
* propellant mass
Way to over-engineer things, but it costs nothing at runtime and guns have distinct "voices" as a result.
0
0
15
Moved my game from #threejs to meep engine.
Before and after.
Still a bunch of things to tweak and adjust, but worked surprisingly well
Before and after.
Still a bunch of things to tweak and adjust, but worked surprisingly well
2
0
12
WebGPU water
* authored with geometry, conforms to any space and scale
* unlimited number of water "bodies"
* rendering is entirely screen-space, so you only pay for pixels you can see
* authored with geometry, conforms to any space and scale
* unlimited number of water "bodies"
* rendering is entirely screen-space, so you only pay for pixels you can see
5
2
112
Foot IK (WebGL)
From a prototype long ago, when working on the game "Might is Right".
It's a top-down RPG, so foot IK isn't the first thing you think about, but it's in there
From a prototype long ago, when working on the game "Might is Right".
It's a top-down RPG, so foot IK isn't the first thing you think about, but it's in there
0
0
8
Was motivated to work on Virtual Shadowmap implementation.
1 mm per texel at finest level (configurable)
16 cascades
Covers about 268.4 km by 268.4km
In WebGPU the technique is held back by lack of multi-view rendering, but it's pretty good for static scenes.
1 mm per texel at finest level (configurable)
16 cascades
Covers about 268.4 km by 268.4km
In WebGPU the technique is held back by lack of multi-view rendering, but it's pretty good for static scenes.
1
0
68
Working on volumetrics for the engine's path tracer (WebGPU)
first two marbles are glass, highly scattering fog-like volume and a cube of water with a solid red block.
first two marbles are glass, highly scattering fog-like volume and a cube of water with a solid red block.
0
0
21
Screen-space refractions in WebGPU
Transparency via common AVBOIT pipeline, including particles, transparent geometry and trails here.
based on @JCGT_announce 2025 paper "Ultrafast Screen-Space Refractions and Caustics via Newton’s Method" by Chase Mayer, Ulf Assarsson and steps
48 fallback steps
Transparency via common AVBOIT pipeline, including particles, transparent geometry and trails here.
based on @JCGT_announce 2025 paper "Ultrafast Screen-Space Refractions and Caustics via Newton’s Method" by Chase Mayer, Ulf Assarsson and steps
48 fallback steps
0
1
32
Added support for shadows to my WebGPU virtual geometry system. This here is 3.46 Billion source triangles, we have the main view and 3 shadow cascades.
3
0
34
WebGPU tower defense prototype
- reworked building mechanics
- added visual previews of enemy paths
- a bit more styling for spawning portals
- reworked weapons models and animations
- overhaled the UI
Heavily inspired by Sanctum 2, loved playing that game years ago
- reworked building mechanics
- added visual previews of enemy paths
- a bit more styling for spawning portals
- reworked weapons models and animations
- overhaled the UI
Heavily inspired by Sanctum 2, loved playing that game years ago
1
0
22
Managed to load materials for Zorah into my engine. Honestly effort is not worth the pay-off, but it's fun to see
2
0
29
18,885,367,310 triangles in WebGPU
The Zorah asset, Virtual Geometry
Chased down remaining conversion issues, so the entire asset is now loaded
I had the goal of loading the entire asset and having it be interactive in WebGPU, and I consider that goal to have been achieved now
The Zorah asset, Virtual Geometry
Chased down remaining conversion issues, so the entire asset is now loaded
I had the goal of loading the entire asset and having it be interactive in WebGPU, and I consider that goal to have been achieved now
7
7
116
More progress on Virtual Geometry in WebGPU.
Solved most of the frame hitches and a bunch of visual artifacts.
Again, Zorah scene with 10B triangles. Credit to @nvidia and the @UnrealEngine team at @EpicGames
Solved most of the frame hitches and a bunch of visual artifacts.
Again, Zorah scene with 10B triangles. Credit to @nvidia and the @UnrealEngine team at @EpicGames
5
9
153
Zorah scene (10B triangles) in the browser
Custom WebGPU Virtual Geometry engine.
Missing about 8% of the objects (conversion issues).
Still work in progress
Custom WebGPU Virtual Geometry engine.
Missing about 8% of the objects (conversion issues).
Still work in progress
7
6
120
Virtual Geometry in WebGPU. Playing around with Zhora assets.
Thanks @nvidia for releasing the assets as part of open source samples.
Thanks @nvidia for releasing the assets as part of open source samples.
4
6
81
Working on Virtual Geometry (WebGPU). Added streaming on the reader side.
Why it's important, the Lucy model is 27M source triangles and ~850Mb of raw cluster data, loading and parsing all of that at once is quite slow, but streaming is pretty much instant. We only fetch what we of clusters to be evicted to keep RAM usage bounded.
Especially important on the web, where network speed is a factor.
Why it's important, the Lucy model is 27M source triangles and ~850Mb of raw cluster data, loading and parsing all of that at once is quite slow, but streaming is pretty much instant. We only fetch what we of clusters to be evicted to keep RAM usage bounded.
Especially important on the web, where network speed is a factor.
3
4
84
Looks really interesting, but no, it's a custom ISA and tooling.
And yes, the VM's assembly is authored from a graph. The idea is pretty dumb but it works very well. The entire particle system runs on the GPU, and I mean all of it. There is no per-emitter dispatch on the CPU side, all emitters are simulated with a single dispatceason really.
The fact that we only need one shader for the VM is a massive bonus for WebGPU, as every shader need to be re-compiled on every application launch (page load).
Perf looks pretty good so far, though I need to run more tests.
And yes, the VM's assembly is authored from a graph. The idea is pretty dumb but it works very well. The entire particle system runs on the GPU, and I mean all of it. There is no per-emitter dispatch on the CPU side, all emitters are simulated with a single dispatceason really.
The fact that we only need one shader for the VM is a massive bonus for WebGPU, as every shader need to be re-compiled on every application launch (page load).
Perf looks pretty good so far, though I need to run more tests.
1
0
1
Been working on a new particle engine for a while, finally integrated it.
Thanks to
@MichalDrobot for his AVBOIT presentation,
@mirror2mask for organizing the SIGGRAPH Advancements talks.
@mirror2mask & @ChrisTchou for the ideas for particle system architecture from their Destbeck for the the infamous graphics presentation
And I'm sure there are dozens more, thanks guys, you've very appreciated
Thanks to
@MichalDrobot for his AVBOIT presentation,
@mirror2mask for organizing the SIGGRAPH Advancements talks.
@mirror2mask & @ChrisTchou for the ideas for particle system architecture from their Destbeck for the the infamous graphics presentation
And I'm sure there are dozens more, thanks guys, you've very appreciated
1
0
18
Working some more on the Q3 WebGPU port
* minor bugfixes
* perf improvements
* VFX fixes on weapons, like detaching tracers or flashes being wrong color or too bright
* a bunch of improvements to Bot logic (not seen here)
* toned down exposure compensation, was too blown out
Q2Usr2b
* minor bugfixes
* perf improvements
* VFX fixes on weapons, like detaching tracers or flashes being wrong color or too bright
* a bunch of improvements to Bot logic (not seen here)
* toned down exposure compensation, was too blown out
Q2Usr2b
2
2
24