Esenthel Forum - Showcase

Weather

Thu, 23 Jul 2026 16:23:42 +0000

Video:

https://streamable.com/jzrk6s

AI written summary:

New Rendering Pillar: Sky, Clouds, Fog & Weather

I've merged a full atmosphere/weather stack into my fork. It's five independent
systems that share one physically-based sky, plus a unified wind bus that ties the
whole scene together. Everything below is opt-in and default-OFF - if you
enable none of it, your project renders exactly as before (bit-identical, verified
against the stock Sky tutorial). It's Vulkan-first: where a system's shaders
or compute support aren't present, it falls back to the classic path automatically.

The five systems at a glance

Physical Sky Atmosphere (Hillaire 2020) - Sky.atmosphericPhysical() / SkyAtmo
Dynamic Environment Capture (sky-derived ambient + reflections) D.envMapDynamic(true) / EnvCapture - Vulkan only
Volumetric Clouds V2 (Nubis-lineage GPU raymarch) - Clouds.v2.create()
Froxel Volumetric Fog (Wronski/Hillaire) - D.volumetricFog(true) / VolFog
Weather + Unified Wind Bus - Weather.enable() / Wind

...plus a linear (start/end-distance) global fog mode you can use on its own.

What each system does

Physical Sky Atmosphere
A Hillaire-style atmosphere with Rayleigh, Mie and ozone scattering, multiple
scattering with ground bounce, a physical sun disc, and stars that fade out with sky
luminance. It also drives aerial perspective - distant geometry picks up the
correct atmospheric tint. Presentation knobs (sky radiance, saturation, sun-disc size,
star fade) grade the result without rebuilding the scattering LUTs, so tweaking the
look is cheap.

Code:

Sky.atmosphericPhysical(true);

Dynamic Environment Capture
Instead of a static cubemap, this captures one cube face per frame from the physical
sky into an HDR cube with prefiltered mips, feeding ambient light, reflections and the
water cube. Reflections and ambient warm-shift at dusk on their own. (Vulkan only;
disabling it restores the static env map.)

Code:

D.envMapDynamic(true);

Volumetric Clouds V2
A real GPU cloud raymarcher - Perlin-Worley + Worley noise, Henyey-Greenstein phase,
powder and multi-scatter - with amortized temporal reconstruction and a deterministic
per-pixel ray phase so the clouds stay stable instead of boiling. A clear sky costs
almost nothing (CPU early-out); a full overcast deck is a few ms at 3/4 trace res.
Coverage, type, density and wind are all driven per-frame with zero shader
rebuilds.

Code:

Clouds.v2.create();

Clouds.v2.crispness(0.3); // trim thin wisps into crisper shapes

Froxel Volumetric Fog
A camera-frustum froxel fog volume with height fog and sun in-scatter lit through
the cascade shadow map - so you get real light shafts / god rays, not a flat tint.
Transparent surfaces sample the same volume at their own depth, so there are no fog
halos around alpha geometry. Coexists with the classic analytic fog.

Code:

D.volumetricFog(true);

Weather + Unified Wind Bus
Presets (CLEAR ... STORM ... SNOW / FOG / CUSTOM) blend over timed transitions
and drive cloud coverage/type/density, fog, and sun/ambient/sky as multipliers on
your authored values - all restored exactly when you disable it. A single Wind
bus feeds grass, cloth, water, particles and cloud advection from one source. On top of
that: camera-locked rain/snow, a global wetness pass (up-facing surfaces get more
reflective), lightning flash + delayed thunder, and rain/wind audio.

Code:

Weather.enable();

Weather.preset(WEATHER_STORM);

Tutorials - new "23 - Weather" category

Five new tutorials under Tutorials/Source/23 - Weather/. They're not gated
on Vulkan the sky degrades to the classic gradient when its shaders are absent, so
they build and run on every backend.

Tutorial_23_SkyAtmosphere - the physical sky/atmosphere on its own: sun disc, stars, aerial perspective, and the grading knobs.
Tutorial_23_SkyAmbient - dynamic environment capture: watch reflections and ambient shift as the sun moves through the day.
Tutorial_23_VolumetricClouds2 - the cloud raymarcher, with test scenes and a live crispness control.
Tutorial_23_FroxelFog - volumetric fog and sun shafts / god rays.
Tutorial_23_Weather - the whole thing together: toggle CLEAR vs STORM and watch clouds, fog, rain, wet ground and lightning respond in one scene.

Build any of them the usual way:

Code:

cmake --build cmake-build-debug --target Tutorial_23_Weather

Notes

Every system is default-OFF existing projects are untouched until you opt in.
Vulkan gives the full effect; other backends fall back gracefully.
Weather is the only system that hooks core per-frame code (a wetness hook + a wind-update hook), and both short-circuit when Weather is disabled.

Full design + frame-composition write-ups are in the repo:
docs/sky-fog-weather-design.md and docs/clouds-v2-handoff.md.

In this fork:
https://github.com/DrewGilpin/EsenthelEngine

Android Vulkan

Tue, 14 Jul 2026 16:23:26 +0000

AI summary:

The engine now builds and runs on Android arm64, using the exact same Vulkan 1.3 backend as the PC path. There is no GLES renderer, no cut-down mobile fork, and no separate shader set. The renderer that draws your desktop frame is the renderer that draws the phone's.

It renders, takes touch input, handles rotation, survives being backgrounded, plays positional audio, loads mobile-compressed textures, and composites an HTML/CSS HUD over a streamed 3D world with a playable character.

And rather than claim "it works on Android", I ran it on a device farm. 176 device/OS combinations on real hardware. The full results — including everything that fails, and why — are in this post.

What's in it

Vulkan 1.3 + descriptor indexing (bindless) as the baseline — the same requirement as PC. WSI via vkCreateAndroidSurfaceKHR.
Touch input, including a virtual joystick (left thumb moves, right thumb turns).
Display rotation and resume from background.
Positional audio — openal-soft is now the Android sound provider, so the whole environmental audio pillar (EFX reverb, HRTF, occlusion) lights up on a phone.
ASTC / EAC textures — proper mobile formats, with a headless publish step: TitanEditor --publish=android.
RmlUi — the HTML/CSS UI stack cross-compiles for Android and is fully interactive by touch.
A real game demo — streamed Game::World, textured terrain, a playable character, RmlUi HUD, in landscape.

The deliverable is a shared libEsenthelProject.so loaded by a NativeActivity subclass. Editor and tutorials are gated off for Android.

The engine's render defaults are DESKTOP defaults

This was the biggest perf lesson, and it will bite anyone porting: the engine's defaults are desktop defaults, and on a phone they are ruinous. Six shadow cascades at 2048², SSAO, and an FSR-style upscaler are all perfectly sensible on a GPU with a fan.

Measured with GPU timestamps on an Adreno 740 at 2316x1080: 47 -> 72 fps, from three changes.

Shadows — 6 cascades @2048² down to 3 @1024². Light phase 6.8 -> 3.9 ms.
Ambient — SSAO down to AMBIENT_FLAT.
Density — 75% render scale. Opaque 4.9 -> 3.2 ms, light 3.9 -> 2.4 ms.

And one genuine trap. The default density filter is FILTER_EASU (FSR-style upscaling), and it costs more than the pixels it saves. Rendering at 75% with EASU (49 fps) was slower than rendering at 100% and not upscaling at all (55 fps). Pair any density change with FILTER_LINEAR, or you will conclude — wrongly — that resolution scaling does nothing.

I did not trust that. It was one GPU.

So I measured it on four

"EASU is a trap" is a claim about one GPU's ALU-to-bandwidth balance. Generalising that into a shipping default without checking is exactly the kind of thing that quietly embarrasses you later. So: same world, same fixed camera, same frame counts, four render presets, swept inside a single run on each device.

GPU milliseconds. "Shipped" is 75% + LINEAR. "+EASU" changes ONLY the filter, so the difference between those two columns is the cost of EASU and nothing else.

Code:

GPU           device            shipped   +EASU   native(100%)   EASU costs

-----------------------------------------------------------------------------

Adreno 740    S23 Ultra           5.04    11.32       8.95        +5.5 ms

Adreno 750    Galaxy S24          3.36     5.73       4.89        +2.5 ms

Mali-G710     Pixel 7 Pro         6.11    12.53       8.67        +6.0 ms

Mali-G68      Galaxy A54         18.97    32.95      29.79       +15.1 ms

The trap is universal, and far worse on Mali than on the Adreno where I found it. On every GPU measured, upscaling and then running EASU costs more GPU time than simply rendering every pixel. A Mali-G68 pays +15.1 ms — on a device whose entire 60 fps budget is 16.7 ms. Generalising the Adreno figure would have understated the problem by 3x.

The reassuring half: the shipped default (75% + LINEAR) is the fastest preset on all four GPUs. The setting was right. The evidence for it was thin, and now it isn't.

Read GPU milliseconds, not fps. The Adreno 750 sits at ~70 fps under every preset while its GPU time swings 3.4 -> 6.4 ms. It is panel/CPU-capped, so fps there measures the ceiling, not the render cost. Benchmarking a phone by frame rate alone measures the screen.

The device matrix — 176 combos on real hardware

Code:

Runs             94    Vulkan 1.3, bindless, 0 validation errors

Below baseline   80    Vulkan 1.1 — not ONE exposes dynamic_rendering

Fails             2    Mali-G52 MC2 — no descriptor indexing

Measured        176 / 199 catalogue combos

Phones it RUNS on — 0 validation errors

"fps" is filled in only where I ran the perf sweep; it is a property of the GPU, not the phone. "BC" is whether the GPU can read the engine's BC7 textures natively — see further down, this turns out to matter more than the failure column.

Code:

GPU                    fps   BC   Devices

------------------------------------------------------------------------

Mali-G715               —    no   Pixel 8, 8 Pro, 8a, 9, 9 Pro, 9 Pro XL,

                                  9 Pro Fold, 9a, 10a

Adreno 740              88   yes  Galaxy S23, S23+, S23 Ultra, Tab S9,

                                  Z Flip5, Z Fold5, Xperia 1 V

Adreno 750              69   yes  Galaxy S24, S24+, S24 Ultra,

                                  Z Flip6, Z Fold6

Mali-G710               53   no   Pixel 7, 7 Pro, 7a, Pixel Fold, Pixel Tablet

Mali-G68                25   no   Galaxy A16, A26, A35, A54, Tab S9 FE

Adreno 830              —    yes  Galaxy S25, S25+, S25 Edge, S25 Ultra,

                                  Z TriFold

PowerVR DXT-48-1536     —    no   Pixel 10, 10 Pro, 10 Pro XL, 10 Pro Fold

Samsung Xclipse 940     —    no   Galaxy S24, S24+, S24 FE   (Exynos variants)

Mali-G57 MC2            —    no   Galaxy A15, XCover7, moto g (2025)

Adreno 840              —    yes  Galaxy S26, S26+

Adreno 710              —    yes  Galaxy A36

Mali-G68 MC4            —    no   Galaxy A34, Lenovo Tab P12

Mali-G57                —    no   moto g04, realme C53

Samsung Xclipse 540     —    no   Galaxy A56

Adreno 735              —    yes  motorola razr plus 2024

Mali-G720 Immortalis    —    no   Galaxy Tab S10+

Samsung Xclipse 530     —    no   Galaxy A55

Samsung Xclipse 920     —    no   Galaxy S23 FE  (Exynos variant)

Mali-G78                —    no   Pixel 6

Adreno, Mali, PowerVR and Samsung Xclipse all run it. Every current flagship line — Pixel 6 through 10, Galaxy S23 through S26, the foldables — plus a decent spread of mid-range.

Phones it FAILS on

Code:

Mali-G52 MC2   Galaxy A06, moto g05   driver 49.1.0

               no descriptor indexing — 11 validation errors

Two devices, one GPU class. The engine's materials are bindless, so this is a real product decision — a non-bindless fallback path — not a bug.

Phones BELOW the baseline (Vulkan 1.1 — cannot run it)

Code:

GPU                   Devices

------------------------------------------------------------------------

Adreno 730            Galaxy S22, S22+, S22 Ultra, S23 FE, Tab S8,

                      Tab S8 Ultra, Z Flip4, Z Fold4, OnePlus 10T

Adreno 619            Galaxy A52, Tab A9+, Tab S7 FE, OnePlus Nord CE 2/3

                      Lite, Xperia 10 V, moto g34, CPH2195

Adreno 660            Galaxy S21, S21+, S21 FE, S21 Ultra

Adreno 650            Galaxy Note20, Note20 Ultra, S20 FE, S20 Ultra, Tab S7

Adreno 610            Galaxy A05s, Tab A7, Xperia 10 II, moto g(30),

                      moto g(9) play, moto g play (2021 / 2024)

Mali-G57 MC2          Galaxy A14, A15, A16, A79, moto g (2022)

Mali-G78              Galaxy S21 Ultra, Pixel 6, Pixel 6a

PowerVR Rogue GE8320  Galaxy A03s, A12, A21

Adreno 642L           Galaxy A52s, motorola edge 30

Adreno 710            Xperia 10 VI, moto g96

Mali-G52 / G52 MC2    Galaxy Tab A8, Galaxy A32, Motorola G20,

                      moto g stylus (2023)

Mali-G68              Galaxy A25, Galaxy A53

Mali-G610 MC3         motorola edge 40 neo

Mali-G77 MC9          motorola edge 40

Mali-G72              Galaxy XCover Pro

PowerVR BXM-8-256     moto g54

Adreno 620 / 630      Pixel 5, Pixel 3

Adreno 506            AQUOS sense2 SH-01L

Read that list carefully, because it is stranger than it looks: several phones appear in BOTH tables. Pixel 6. Galaxy A15, A16. Galaxy S23 FE, Galaxy S24. Same model name, opposite verdict.

There are two separate reasons for that, and they are worth keeping apart.

1. Regional silicon. Galaxy S23 FE and S24 ship a Snapdragon in some markets and an Exynos in others — Adreno 730 vs Xclipse 920, Adreno 750 vs Xclipse 940. Those are genuinely different GPUs behind one marketing name. Nothing surprising, but it does mean "does the S24 work?" has no single answer.

2. The driver. This is the real finding.

The baseline is a DRIVER threshold, not hardware

Pixel 6, Galaxy A15/A16 and the Mali-G68 A-series are not regional variants. They are the same silicon, passing or failing purely on which driver version the device shipped with:

Code:

GPU             PASSES on driver          FAILS on driver

--------------------------------------------------------------------

Adreno 710      512.800.35 / 512.800.48   512.615.0 / 512.615.88

Mali-G57 MC2    38.1.0                    32.1.0

Mali-G68        38.1.0                    32.1.0

Mali-G78        38.1.0                    32.1.0 / 38.0.0

The threshold is Mali ≥38 and Adreno ≥512.800. A Pixel 6 on Mali driver 38.1.0 runs the engine; a Pixel 6 on 32.1.0 cannot. Nothing about the phone changed but the driver it shipped with.

Below the threshold the device does not expose Vulkan 1.3 — and crucially, not one below-baseline device exposes dynamic_rendering even as an extension. So supporting them means writing a second render path, not a shim.

And it is not simply a matter of waiting for old phones to age out. I have Galaxy S22s running a current Android 16 that still ship an Adreno 730 driver reporting Vulkan 1.1. The OS is new; the GPU driver is not.

The interesting finding is not in the failure column. Look at the BC column in the first table: 60 of the 94 devices that DO run us have no BC texture support — every Mali, every PowerVR, every Xclipse. The engine's own Engine.pak still ships BC7, so on 64% of our supported devices every texture is silently expanded to RGBA at load. Several times the VRAM. Nothing looks wrong on screen. Only a capability probe can see it, and it is now the biggest open item on the Android side.

Also worth naming: a mid-range Mali-G68 (Galaxy A54) runs the demo at 25 fps even on the mobile preset. If that class of device is in scope, it needs its own settings tier.

One caveat on all of the above: this is the test farm's catalogue, not the market. It over-represents Pixels and Samsungs and whatever Google chose to stock. Read it as a driver/GPU survey, not a market-share estimate.

The farm's PASS column lies

A warning for anyone doing this: a device-farm "pass" on a game-loop test means the activity finished. Nothing more.

An app that fails to load its data pak, exits immediately, and renders absolutely nothing also "passes". That happened here, and I believed it for a while — the pak sat at a path that scoped storage made unreadable, the engine logged "Can't load Pak", quit, drew nothing, and the farm reported Passed across the board.

So every verdict in the tables above comes from the device's own logcat — a capability line the probe prints before any bail-out, so that even hardware we refuse to run on still yields a full data row instead of an empty log. That is why the below-baseline devices have driver versions at all.

Summary

Same Vulkan backend as PC — no GLES, no mobile fork, no separate shaders
94 device/OS combos run it clean across Adreno, Mali, PowerVR and Xclipse — 0 validation errors
The baseline is a driver threshold, not hardware — the same GPU passes on a newer driver
47 -> 72 fps from mobile render settings — and the EASU trap is now measured on four GPUs, not one
Touch, rotation, resume, audio, ASTC/EAC, RmlUi HUD, playable character in a streamed world
Five latent engine bugs found and fixed — all of which desktop had been hiding

Open: the Engine.pak BC7 transcode (64% of supported devices are silently decompressing textures), and a settings tier for mid-range Mali.

More info about the device farm, it was Google Cloud's, all of the scripts and apps needed to run the device farm tests are included in the repo:

The scripts

Code:

scripts/android_gpu_matrix.sh        one device per GPU architecture — does it render correctly?

scripts/android_perf_matrix.sh       4 render presets per device (the EASU harness) — NEW

scripts/android_survey_resume.sh     capability survey, idempotent, launches async

scripts/android_survey_collect.sh    pulls the logcats, prints the report

scripts/android_survey_report.py     summary + per-device table + survey.json

scripts/android_tutorial_sweep.sh    37 tutorials on-device with the validation layer

scripts/android_publish_pak.sh       the ASTC/EAC Project.pak

scripts/android_thirdparty_build.sh  one-time arm64 cross-build

scripts/android_game_demo.sh         build + deploy the game demo

scripts/android_fetch_validation_layer.sh

The apps they ship to the devices

AndroidProbe.cpp (capability probe), AndroidPerf.cpp (the perf sweep I added), AndroidSweep.cpp (tutorial sweep), AndroidGame.cpp (the demo) — all tracked, all with CMake targets.

in this fork:
https://github.com/DrewGilpin/EsenthelEngine

bindless materials, GPU-driven submission, environmental audio, VRAM management

Tue, 14 Jul 2026 15:41:03 +0000

No visible things to show, because the biggest feature add was an improved audio system, and the now the engine fork uses OpenAL on all platforms. Major architectural/perf improvements to the Vulkan renderer.

AI written summary:

It is less photogenic, but this is the part that actually raises the engine's ceiling: bindless material descriptors, GPU-driven draw submission, a texture residency manager, compute skinning, static shadow caching, a 9.4x faster shader build, and a complete environmental audio stack.

Everything below is opt-in and Vulkan-only unless noted. All numbers measured on an AMD Radeon RX 6650 XT.

Two of these were the direct result of an architecture audit: the engine was a DX11-shaped renderer on a modern Vulkan core, missing three standard pillars — bindless descriptors, GPU-driven submission, and parallel command recording. The first two are now in. The third turned out not to be needed, and I will explain why, because that is more interesting than shipping it would have been.

1. Bindless material textures

Previously every material switch re-allocated and rewrote a descriptor set. With many unique materials on screen this dominates: descriptor churn, and pool pressure up to 16384 sets per frame.

Material textures now live in a global set-1 texture table (descriptor indexing, UPDATE_AFTER_BIND, 65536 slots, fence-gated slot recycling), indexed by a small per-material constant. A macro swap in the shader header re-routes every Col/Nrm/Ext/Det/Lum sample, so no shader needed hand-editing — the regenerated pak's set-0 layouts simply contain no material textures at all.

That last detail matters: the churn is gone structurally. There is no runtime flag to forget to enable.

Measured, 512 unique materials:

533 -> 22 descriptor sets per frame
1.95 -> 1.29 ms
+51% fps

Pixel-identical against the committed baseline; clean validation soak.

Demo: Tutorial_17_MaterialStress

Bindless is also the precondition for everything in section 2.

2. GPU-driven rendering: compute culling + indirect draw

The engine culled per object on the CPU, per light, with no occlusion culling at all, and recorded every draw on one thread. multiDrawIndirect was enabled but never actually issued.

There is now a persistent GPU-instanced layer: register N instances once, and a compute kernel culls and compacts them into draw chunks that feed vkCmdDrawIndexedIndirectCount. Zero CPU per-instance work, using the mesh's existing shaders — no new shaders and no pak regeneration.

What is in it:

Frustum culling on GPU — an exact port of the engine's own sphere-vs-frustum test, so results match the CPU path.
Hi-Z occlusion culling, two-phase. The layer occludes itself: standing inside a dense field with no external occluders, 13,074 -> 67 survivors (99.5% culled), and disocclusions are caught in the same frame.
Per-cascade shadow culling — each shadow cascade re-culls on the GPU and indirect-draws survivors.
Automatic world migration — Game::Static and Game::Kinematic objects move onto the layer as they stream in, and off as they stream out. Meshes with LODs become per-LOD banded layers whose distance bands are an exact port of the CPU LOD selection, so the GPU path draws the same LOD the CPU path would, in every view, at every distance.

Measured (262k instances):

Frustum only: 4.24 -> 1.85 ms (2.3x)
Full stack: 8.8 -> 1.54 ms (5.7x)
CPU command recording: 26.6 -> 1.5 ms

Pixel-identical A/Bs — zero false culls.

Demos: Tutorial_17_GpuCull, and Tutorial_14_GpuWorld (a real streamed world with thousands of statics flying in and out of range).

An engine-wide bug this uncovered: under CSM load the per-draw uniform ring silently wrapped mid-frame (65k casters x 4 cascades is roughly 10x the ring budget), corrupting already-bound slots. That was a latent bug for anyone with heavy shadow scenes, not just the new path. The ring now grows on overflow.

And the honest part. The win scales with density. At ~29k cheap statics with shadows on, the CPU path is still ahead (6.8 vs 7.8 ms) — the per-cascade dispatch rounds are a fixed cost that needs volume to amortise. This is a scalability feature, not a free win in every scene, which is why it stays opt-in.

3. The pillar I did not ship

The third missing pillar was parallel command recording — record the G-buffer and each shadow cascade on separate threads into secondary command buffers. It is a standard modern design and it was on the roadmap.

I measured before writing it. The GPU-driven layer had already taken single-threaded CPU recording from 26.6 ms to 1.5 ms. What remains is serial pipeline overhead, not parallelisable draw loops — so a week-scale threading refactor (per-thread secondary CBs, per-context pools, a thread-safe uniform ring) would buy under 1 ms on frames that are GPU-bound anyway.

So it is closed, not done, and I would rather say that plainly than ship a feature to tick a box. Same outcome for a per-frame arena allocator: an LD_PRELOAD counting shim showed steady-state allocation is under 10 mallocs per frame, so there was nothing to win.

4. Environmental audio — the immersion layer

This is the change I am happiest with: the engine had solid audio plumbing (OpenAL Soft, Opus/FLAC, real voice virtualization with priority management) and no immersion layer whatsoever. No reverb. No HRTF. No occlusion. Every space — cathedral, cupboard, open field — sounded identical and anechoic.

OpenAL Soft ships EFX and HRTF for free. The engine simply never asked for them.

Now shipped, with zero new dependencies:

Reverb (EFX) — SND_REVERB, a 26-preset EAX vocabulary. Live 3D sources attach a reverb send automatically; 2D/UI/music stay dry by construction.
Reverb zones — Ball/Box volumes, innermost wins, with a classic two-slot equal-power crossfade. Walking through a doorway fades between spaces smoothly, and retargeting mid-fade stays smooth.
Occlusion and obstruction — physics-raycast, using the Wwise-style split: a wall between you and the source muffles the dry path (obstruction), and full occlusion escalates into the reverb sends too. Shoulder-offset rays, round-robin throttled, smoothed.
HRTF + doppler — proper binaural positioning on headphones.
Decoded-PCM sample bank — cached PCM served through the existing reader, so looping, seeking, muffling and virtualization all keep working while per-play decode cost drops to zero.

Demo: Tutorial_09_EnvironmentalAudio — a stone room, a doorway, and an open field, with R/O/H/B toggling reverb, occlusion, HRTF and the sample bank so you can hear each one switch in and out.

OpenAL across platforms. The environmental stack is OpenAL-only, and Windows historically shipped XAudio/DirectSound. Rather than port the whole thing to XAudio2 XAPO effects, Windows now moves to openal-soft as well — the headers and Win64 import library were already vendored in-repo, so it is a define flip plus the DLL. One sound provider, one environmental stack, everywhere. (Landed; still wants validation on a Windows box, and there is a one-line rollback if it misbehaves.)

Design doc: docs/audio-design.md

One thing I deliberately did not build: ray-traced audio occlusion against the RT acceleration structure. It sounds great in a feature list, and I have the TLAS sitting right there. But collision proxies are acoustically better occluders than render triangles — sound wavelengths are metre-scale and diffract around the detail geometry that a TLAS is full of — the ray counts involved do not need a GPU, and a GPU readback adds latency to a system that must react instantly. It was a marketing bullet, not audible value, so it is struck. Material-based transmission and portal propagation are the real follow-ons.

5. Texture residency / VRAM budget

Every referenced texture was promoted to full resolution and kept there — no residency, no budget, no eviction. Your working set was "every texture the world has ever touched, at full res", which is a hard ceiling for open worlds.

EE_TEX_BUDGET= now enforces an LRU byte budget. Material textures timestamp themselves on bind (the bindless registration hook gives this for free), and a throttled manager demotes the least-recently-used textures one mip step under pressure, promoting them back once there is headroom, with 15% hysteresis so it cannot oscillate.

The neat part: demote and promote are the same operation — a reload through the engine's existing streaming loader with a shrink override. Small pak read, background stream, the standard hot swap. Deferred image destruction plus bindless view re-validation make live swaps safe by construction.

Verified: budget off, or a huge budget, is pixel-identical to stock; a 1 MB budget demotes to fit exactly; raising the budget mid-run recovers to pixel-perfect full quality.

A bug worth knowing about if you write background systems: Time.frame() freezes when the app is not drawing. Anything clocking off it silently stops in an unfocused or minimized window. The manager ticks from the update path instead, so streaming survives alt-tab.

6. Compute skinning (the raster half)

Last post covered GPU-skinned characters for ray tracing. That was half the story — the other half is that skinning was VS-only, so the same linear-blend skin was recomputed in every pass: early-Z, opaque, and once per shadow cascade.

With EE_VK_GPU_SKIN=1, a character deforms once per frame into a real vertex buffer, and every pass afterwards — G-buffer, mirrors, all shadow views, and the RT acceleration structure — draws that same deformed buffer. One deform serves raster and ray tracing.

It also gets exact per-limb motion vectors: the kernel skins by the previous frame's pose into a second position channel, so TAA sees a limb's true motion instead of just the camera's.

Honest number: about -2.4% GPU on an 800-character idle crowd. Vertex skinning is a smaller slice of the frame than you would guess — CPU animation update dominates that scene. The real value here is correctness (RT and motion vectors), not the frame time.

7. Static shadow caching for local lights

D.localShadowCache(max_lights). Every shadowed light previously re-rasterised all its geometry every frame. Now each light keeps a cached static depth atlas and only re-renders dynamic objects per frame; lights with no dynamics bind the cache directly with zero copies. It is camera-motion-proof by construction, because it is all in light space.

Honest perf: -22% at 512px shadow maps, roughly break-even at 1024, and it loses at 2048 in a scene of cheap instanced barrels — copying a 96 MB depth atlas per light beats re-rendering geometry that was nearly free to begin with. The win condition is scenes where per-light static shadow rendering is genuinely expensive. It is opt-in for exactly that reason.

(Chasing an apparent culling leak here turned out to be my own demo: point-light range grows with the square root of power, so those lights were ~90 m across and legitimately touched everything. Engine culling was correct. Emptiness is now decided by one cheap sphere query, so empty lights are truly free.)

8. Shader build: 2h11m -> 13m56s

Boolean shader dimensions (dither, gamma, alpha test, detail, material blend, UV scale, and Forward's nine light dims) were being baked into full permutations, so the pak universe — and the cold build — grew combinatorially.

They are now specialization constants, resolved at pipeline creation. Two compiler-side changes turn a smaller pak into saved time: specialization values are excluded from the shader cache key, and identical compiles are deduplicated within a run.

Cold Vulkan shader regen: 2h11m -> 13m56s (9.4x)
Forward: 39,080 -> 10,664 compiles
Engine.pak: -27 MB (Forward 76.8 -> 37.1 MB, Deferred 29.8 -> 14.4 MB, Blend Light 21.0 -> 9.1 MB)
Output bit-identical; stock content pixel-identical

Part of that came from noticing the forward renderer is compiled out of the runtime entirely — so roughly 17 of the 33 remaining minutes were spent building shaders nothing could ever load. Now gated (and reversible), which also removed 108 MB of unloadable paks from the repo.

9. Async compute, and a batch of small wins

EE_VK_ASYNC_COMPUTE=1 routes the GI ray-traced moments pass onto the dedicated compute queue — it reads the acceleration structure and writes an atlas consumed next frame, so it is genuinely async-clean. Two timelines (a shared one violates execution-order monotonicity), per-slot fences, concurrent sharing for cross-queue resources. About 0.09 ms/frame off the graphics queue, zero validation errors, pixel-parity.

Also landed, each small and each measured:

Static vertex/index buffers no longer take a dedicated allocation — they suballocate through VMA. Every mesh used to burn one vkAllocateMemory, heading for the ~4096 allocation ceiling in a mesh-heavy world.
GI capture dispatches batched — one 3D dispatch per pass instead of one micro-dispatch per probe with a full barrier between each.
Immutable samplers — the five never-recreated samplers are baked into the layouts. The other four are settings-mutable, so baking them would dangle every layout on a settings change; they stay written.
Dynamic vertex ring 32 KB -> 2 MB — kills most mid-frame buffer orphaning.
PhysX TGS solver — opt-in via EE_PHYSX_TGS, cheaper stability.

Correctness

The whole stack went through an adversarial multi-agent review before merge — reviewers instructed to refute each finding against the code rather than confirm it. It found 9 real defects: a use-after-free in the sound bank, two more memory bugs, a GPU-cull shadow-gate hole, a spec violation, and four feature-breaking logic errors — including one where the compute-skinning motion vectors never actually worked and had been silently inert for standard meshes.

Every one of them was behind an opt-in lever, so the default path never regressed. All fixed. A forced synchronization-validation soak reports zero hazards.

I mention it because it is the honest counterweight to a features list: this many opt-in systems will hide broken paths unless something goes looking for them on purpose.

Summary

Bindless materials — 533 -> 22 descriptor sets/frame, +51% fps at 512 materials
GPU-driven rendering — compute cull + Hi-Z + indirect draw, 8.8 -> 1.54 ms at 262k instances
Environmental audio — EFX reverb, zones, occlusion, HRTF, PCM bank; openal-soft on every platform
Texture residency — EE_TEX_BUDGET, LRU mip demote/promote, pixel-perfect recovery
Compute skinning — deform once per frame, exact per-limb motion vectors
Static shadow cache — D.localShadowCache
Spec constants — cold shader build 9.4x faster, pak -27 MB
Async compute — GI moments on the dedicated queue

Design docs are in the repo: docs/audio-design.md, docs/clustered-froxel-lights-design.md, docs/rt-shadows-design.md, docs/rt-reflections-design.md.

In this engine fork:
https://github.com/DrewGilpin/EsenthelEngine

Nanite-like Meshlets

Tue, 14 Jul 2026 14:38:34 +0000

Videos:
Using:
https://www.fab.com/listings/454001c6-07...c098596e2e
https://streamable.com/6djncn

Using:
https://www.fab.com/listings/af3e64be-29...24987162e8
https://streamable.com/1xsc3m

Using an engine generated million tri mesh (so megascans don't have to be included in engine repo):
https://streamable.com/xnr8kv

Screenshots:

AI written summary:

Film-quality source meshes — photogrammetry scans, ZBrush sculpts, Megascans "Raw" assets — can't be drawn directly. A million-triangle rock is mostly sub-pixel triangles, where the hardware rasterizer wastes most of its work (2x2 quad granularity + triangle setup), and where hand-authored LODs pop.

This branch adds virtualized geometry: a mesh is baked into clusters (<=64 vertices / <=124 triangles, each with a bounding sphere + normal cone), the GPU picks a per-view cut through a continuous-LOD DAG every frame, and the number of triangles you draw tracks the screen area the object covers — never how many triangles the artist shipped.

Vulkan only (needs VK_EXT_mesh_shader), and opt-in: with it off, nothing in the classic path changes.

How it works

Bake — MeshRender::buildMeshletDag(). Cluster the mesh, then repeatedly group adjacent clusters, simplify each group with its outer boundary locked (so neighbours stay crack-free), and re-clusterize. It's a DAG, not a chain. 1M triangles -> ~22k clusters, 14-19 levels, about 1.8 seconds. Bake once, save the mesh, done.
Task shader — one thread per (instance, cluster): frustum cull + normal-cone backface cull + error-based LOD cut + two-phase Hi-Z occlusion. One dispatch covers every instance of a mesh, so 400 rocks is one dispatch, not 400.
Mesh shader — emits the surviving cluster's triangles, and can skin its own <=64 vertices (no pre-skin pass, no per-instance deformed vertex buffer — a crowd is still one dispatch).
Visibility buffer — rasterize (cluster | triangle) into one 32-bit target, then resolve materials in a single full-screen pass: exactly one shade per visible pixel.
Compute rasterizer — clusters whose screen footprint is tiny skip the hardware raster entirely; a 64-bit atomic is the depth test. At scan density that's most of the geometry.
Hierarchical pre-pass — cull the DAG's node hierarchy first so the task stage only ever sees survivors.

Why the LOD cut is crack-free: a cluster is used while its own error projects below the pixel budget and its parent group's error does not. Because the group's boundary was locked during simplification, two neighbouring clusters sitting at different LOD levels still share an identical boundary. No stitching, no skirts, no popping.

Turning it on (and off)

Everything lives on the global GpuMeshlet object. Defaults are the ship defaults — the whole system is inert until you set enabled:

Code:

GpuMeshlet.enabled = true;   // master switch          DEFAULT: false (fully inert)

Culling

Code:

GpuMeshlet.cull      = true;   // per-cluster frustum cull            DEFAULT: true

GpuMeshlet.cone_cull = true;   // per-cluster normal-cone backface    DEFAULT: true

GpuMeshlet.hiz       = true;   // two-phase Hi-Z occlusion            DEFAULT: true

GpuMeshlet.precull   = false;  // hierarchical node pre-pass          DEFAULT: false

GpuMeshlet.tri_cull  = false;  // per-triangle cull                   DEFAULT: false (measured SLOWER; the

                               //   compute rasterizer already owns that case)

precull is off by default because it carries a fixed per-mesh dispatch cost that doesn't pay for itself on light scenes. On heavy content it is the single biggest win available — see the numbers below. If your scene is scan-density, turn it on.

LOD

Code:

GpuMeshlet.lod              = true;   // the continuous-LOD DAG       DEFAULT: true

GpuMeshlet.lod_error        = 1.0f;   // screen-space error budget, in PIXELS

GpuMeshlet.shadow_lod_error = 4.0f;   // the budget used for SHADOW views

shadow_lod_error matters more than it looks. A shadow map cannot resolve sub-pixel triangles, so rasterizing them into one is pure waste. Shadow views take a coarser cut — but the cut is still evaluated from the main camera, so shadow geometry can never disagree with what you can see. Set it to 0 to use the main view's budget (the old behaviour).

Rasterization

Code:

GpuMeshlet.visbuffer = false;  // visibility buffer + deferred material resolve

GpuMeshlet.swraster  = false;  // compute rasterizer for tiny clusters (needs visbuffer)

GpuMeshlet.sw_thresh = 16.0f;  // cluster screen size (px) below which compute raster takes over

Shadows / secondary views

Code:

GpuMeshlet.shadow    = true;   // meshlets cast shadows               DEFAULT: true

GpuMeshlet.secondary = true;   // meshlets appear in mirrors / water / GI captures

Streaming (cluster residency — for assets too big to keep resident)

Code:

GpuMeshlet.stream      = false;  // residency management               DEFAULT: false (bit-exact when off)

GpuMeshlet.stream_disk = false;  // spill to disk

GpuMeshlet.stream_pak  = false;  // stream straight out of the .pak

GpuMeshlet.stream_pool = 1024;   // resident cluster budget

World integration

Code:

GpuMeshlet.world = false;   // Game::Static objects auto-migrate to the meshlet path

Or drive it yourself: GpuMeshlet.add(render, matrix, material) per instance, or worldAdd(mesh, matrix) which returns false if the per-frame unique-mesh budget (128 meshes) is exhausted — in which case you draw it classically. Overflow degrades, it never silently drops geometry.

Debug palette (visibility-buffer path only — it recolors the real cluster/triangle IDs, not a proxy mesh)

Code:

GpuMeshlet.debug      = 0;  // 0 off, 1 triangle, 2 cluster, 3 triangle screen SIZE, 4 instance

GpuMeshlet.debug_wipe = 0;  // split-screen X in pixels (0 = whole screen)

Stats: GpuMeshlet.drawnClusters(), GpuMeshlet.precullClusters().

Virtual Shadow Maps (the companion feature)

Cascaded shadow maps re-render every caster every frame at a resolution that's wrong almost everywhere. VSM treats the sun's shadow as a virtual texture: a 128x128 grid of pages per clipmap level over a 4096^2 physical atlas, where only the pages the screen actually asks for are rendered — and they are cached across frames.

Code:

VsmShadows(true);              // enable (or EE_VSM=1)

VsmInvalidate(Ball);           // tell the cache a world volume changed

VsmStats(resident, rendered);  // rendered == 0 means fully cached

VsmPendingPages();             // >0 == still refilling

It's delivered as a full-screen sun-visibility mask, into the same socket the ray-traced sun shadows use — so it needed zero shader-pak changes.
Clipmap level is chosen by texel density (~1 atlas texel per screen pixel), not distance — which is also what bounds the page count.
Pages are rendered by the engine's own traversal, so a page gets every caster: terrain, classic objects, and meshlets alike.
The cascades only render while the cache is refilling. In the steady state VSM carries the sun shadow alone and the entire cascade render + resolve is skipped.
Movement is tracked automatically for both meshlet and classic casters (skinned ones are bounded by their bones — a character's matrix can sit still while the pose moves). Spawn / despawn / streaming are handled too. VsmInvalidate() is only for geometry that changes without moving (a terrain edit, a swapped mesh).

Env knobs: EE_VSM=1, EE_VSM_LEVELS (4), EE_VSM_CSM (auto / 0=never / 1=always), EE_VSM_PAGE_BUDGET (24), EE_VSM_COLD_BUDGET (128), EE_VSM_CLASSIC=0 (disable the classic-caster scan), EE_VSM_DEBUG (1-9), EE_VSM_LOG=1.

Measured (400 instances, GPU_TIMER_LIGHT): cascades 3.01 ms -> VSM 2.71 ms, sharper and cached. A moving caster re-renders 12 pages, not 567.

Tutorials

Five, all under Tutorials/Source/14 - Game Basics/. They run on engine/procedural assets — no downloads needed.

Tutorial_14_Meshlets — the teaching one. A classic-drawn sphere next to a meshlet-drawn sphere as an A/B control, with every toggle live: [C] frustum, [N] cone, [H] Hi-Z, [W] an occluding wall, [S] shadows, [L] the LOD DAG, [-/=] the error budget, [G] instance count, [T] false-color clusters. Watch the drawn-cluster count collapse as you put the wall up.
Tutorial_14_MeshletWorld — the Game::Static world path (GpuMeshlet.world) plus VSM. This is what a real game scene looks like.
Tutorial_14_SkinnedMeshlets — mesh-shader skinning. A crowd of animated characters, still one dispatch, crack-free under animation.
Tutorial_14_HeroMeshlets — hero density: a procedurally displaced 1M-triangle rock, instanced into the distance so one frame spans the whole LOD range.
Tutorial_14_MeshletShowcase — the presentation demo. Split-screen photoreal | false-color (the canonical shot), a fly-in, a 200-instance field, and the debug palette. Defaults to its own procedural 1M-triangle rock, and will import a real scan if you point it at one:

Code:

# one scan (OBJ or FBX; 8K PBR maps are found automatically next to the mesh)

EE_SHOWCASE_MESH=/path/Rock_Raw.fbx  EE_SHOWCASE_YAW=180  ./Tutorial_14_MeshletShowcase

# a whole Megascans kit: every sub-folder's scan becomes its OWN asset

EE_SHOWCASE_DIR=/path/quarry  EE_SHOWCASE_COUNT=45  EE_MESHLET_PRECULL=1  ./Tutorial_14_MeshletShowcase

Each tutorial exposes its knobs as env vars for A/B'ing without a rebuild — EE_MESHLET_VIS, EE_MESHLET_SW, EE_MESHLET_LOD_ERR, EE_MESHLET_PRECULL, EE_MESHLET_SHADOW_ERR, EE_MESHLET_TRI_CULL, EE_MESHLET_STREAM, and so on. (These are demo-side conveniences; the engine API is the GpuMeshlet flags above.)

Numbers

Measured on an AMD RX 6650 XT at 3072x1296, on real Megascans scans:

Stone wall scan — 1,000,000 tris (28k clusters): draws 71k (5.7%), 2.7 ms opaque.
Mine tunnel scan — 7,996,040 tris (194k clusters, 23 DAG levels): draws 144k (1.8%), 2.3 ms opaque.
Slate quarry — 45 distinct million-triangle scans = 48,977,263 triangles of unique geometry, 200 instances = 217,936,240 scene triangles: draws 363k (0.167%), 12.9 ms opaque.

And what precull does to that quarry scene (16 unique scans, 200 instances, ~212M scene triangles):

Code:

gpuOpaque    gpuLight    fps

  precull OFF      34.9 ms     115.0 ms    6.6

  precull ON        9.6 ms      25.5 ms   28.1

Pixel-identical output. If you're running scan-density content, turn precull on.

Caveats — read these

Vulkan only. Needs VK_EXT_mesh_shader. There is no DX12 or GL path yet; the classic renderer is untouched and still handles everything else.
Opt-in. Default-off, top to bottom. Nothing changes until GpuMeshlet.enabled = true.
128 unique meshes per frame. Past that, worldAdd() returns false and the mesh keeps its classic draw — it degrades, it doesn't drop.
precull is default-off and tri_cull is default-off (the latter measured slower — the compute rasterizer already covers its best case).
Materials work on every path, including normal mapping with zero stored tangents (the resolve derives the tangent frame analytically) and alpha-tested cutouts. Non-opaque techniques fall back to the classic path.

Full write-up: docs/meshlets-design.md and docs/vsm-design.md. The README has expandable sections for both.

In this fork:
https://github.com/DrewGilpin/EsenthelEngine

RT sun shadows, RT specular reflections, Clustered/froxel lighting

Fri, 10 Jul 2026 02:39:06 +0000

RTGI+RT SHADOWS+RT Reflections

No GI, CSM Shadows,

AI written summary:

I've been extending the engine's Vulkan renderer with three new lighting features:

Clustered/froxel lighting

All three are opt-in and disabled by default. They are also pure runtime toggles, so no shader pak regeneration is needed to use them.

The two ray-tracing features share a single scene acceleration structure, meaning the cost of “going RT” is paid once.

Everything below was measured on an AMD Radeon RX 6650 XT.

The Shared Foundation: One Scene TLAS, Zero Registration

Both RT features use the ray-query acceleration structure originally introduced for dynamic GI.

The best part is that nothing needs to be manually registered. Enable:

GIRayTrace.auto_scene = true;
The renderer then feeds every opaque mesh it draws into the acceleration structure automatically. Streamed world areas enter the RT scene as they load, with no additional application code.

The RT world is the retained union of everything the camera has seen. Looking away from an object does not remove it from shadow, reflection, or GI rays. Meshes leave the acceleration structure only when they are actually destroyed.

Acceleration-structure rebuilds are recorded directly into the frame command buffer, so there is no per-rebuild GPU stall.

Animated characters are supported too.

GIRayTrace.addSkinnedOccluder(mesh, skel);
This GPU-skins the character into its current world pose every frame and builds a per-frame BLAS. The character then:

Costs only a fraction of a millisecond per character

One deliberate design choice is that dynamic characters receive GI but do not contribute to it.

A deforming body inside a sparsely updated probe field causes the surrounding indirect lighting to strobe. To avoid this, the GI probes trace against a second, static-only TLAS.

This is standard DDGI practice, and it eliminated a very visible “the lighting on my character keeps jumping” artifact.

Ray-Traced Sun Shadows

For each pixel, the renderer traces one or more rays toward the sun against the scene TLAS:

[]Hit = shadowed []Miss = illuminated

The detail that makes this a drop-in replacement is that the engine's existing sun-application stage already consumes a pre-resolved full-screen visibility mask.

The RT pass simply writes that mask. The light shaders remain completely unchanged.

When RT shadows are enabled, the renderer skips the entire conventional shadow-map pipeline:

Shadow-mask blur

Advantages over shadow maps

No aliasing, cascade seams, or peter-panning.

A thin floating bar can cast a clean, visibly detached shadow that a shadow map cannot reproduce reliably at any practical cascade resolution.
True contact-hardening soft shadows.

Multiple rays are cone-sampled across the sun's disc using a Fibonacci spiral. The pattern is rotated per pixel and temporally jittered so TAA converges the penumbra.

The result is a shadow that remains sharp at the contact point and becomes progressively softer as the distance between the occluder and receiver increases.
Cost comparable to CSM.

Because RT shadows skip cascade rasterization entirely, the net lighting-phase cost can land near parity with conventional shadow maps in typical scenes.

An eight-ray, half-resolution soft-shadow pass measured approximately 0.89 ms, roughly the same cost as the CSM path it replaced.

Full resolution is the default. Half resolution can undersample thin, moving occluders such as animated characters.

Ray count is the primary performance-versus-quality control.

RtShadows(true);

RtShadowQuality(0.03f, 4);
The first quality parameter controls sun-disc softness. A softness value of zero produces hard shadows. The second parameter controls the number of rays per pixel.

Demo: Tutorial_14_RTShadows

- / =

An on-screen HUD displays GPU cost

The initial implementation supports the sun only.

Ray-Traced Specular Reflections

The reflection pass traces one:

reflect(eye, normal)
ray per pixel against the same scene TLAS.

Reflection hits are fully lit and textured using:

The hit material's actual albedo texture

The result is written using the engine's existing SSR-buffer format.

That allows the existing lit-color composite stage to fold the ray-traced result into the scene with no changes to the combine shader. The normal roughness-aware reflection fade is retained.

Where it beats SSR

Screen-space reflections can only reflect geometry that is already visible on screen.

The RT path can reflect:

[]Content behind the camera []Objects around corners []Off-screen world geometry []The sky

It also avoids the characteristic smearing and disappearing reflections that occur when the camera moves or reflected geometry leaves the screen.

At a demo resolution of 3072 × 1296, the measured light-phase cost was approximately 0.17–0.24 ms.

That was inexpensive enough that I did not add a half-resolution mode.

RtReflections(true);
Demo: Tutorial_14_RTReflections

The scene contains a mirror floor and chrome ball. Press R to switch between ray-traced reflections and the traditional SSR-plus-cubemap path for a direct comparison.

Combined Ray-Tracing Showcase

Tutorial_14_RTShowcase runs all three ray-traced systems together:

Specular reflections

All three systems share the same automatically constructed TLAS.

The demo runs in a streamed world containing an animated character. Each feature can be toggled independently:

R — ray-traced reflections

Clustered / Froxel Lighting

Clustered lighting addresses a different renderer bottleneck.

The classic deferred per-light path renders each light with a separate draw call. When many point lights overlap, the renderer may read the G-buffer and blend lighting into the same pixel once for every affecting light.

The clustered path targets unshadowed point lights such as:

[]Torches []Projectiles []Muzzle flashes []Other scenes containing large numbers of dynamic lights

A compute pass bins lights into a froxel grid containing:

[]32 × 18 screen-space tiles []24 exponential depth slices

A full-screen pass then shades all lights affecting a pixel in one operation using the exact same BRDF as the classic deferred-light path.

The clustered output was verified for pixel parity against the per-light path.

Measured GPU_TIMER_LIGHT results with overlapping, unshadowed point lights:

5% faster

13% faster

256 lights: approximately 19% faster

The performance advantage grows with light count.

The honest framing is that the existing per-light renderer is already depth-bounded. It is not a naive full-screen-per-light baseline.

Clustered lighting is therefore a scalability feature rather than a free performance win in every scene, which is why it remains opt-in.

Cases that are not handled by the clustered path automatically fall back to the classic renderer:

Sub-rectangle views

This keeps rendering parity from being placed at risk.

ClusteredLights(true);
Demo: Tutorial_14_ClusteredLights

The demo presents a twilight field containing 256 overlapping lights.

Up / Down

The light-phase GPU timer is displayed on screen

Additional Notes

All three systems are currently Vulkan-only.
The two ray-tracing features require ray-query-capable hardware.
On other rendering backends, every API call is a safe no-op. The tutorials still run, but the renderer remains on the classic paths.
The complete stack recently went through an adversarial, multi-pass code review and a synchronization-validation soak.
Synchronization validation reported zero hazards.
Sub-render re-entrancy, resource lifetime across streamed worlds, and thread safety of the retained RT scene received particular attention.

Design Documents

The repository contains detailed design documents for each system:

[]docs/rt-shadows-design.md []docs/rt-reflections-design.md []docs/rt-skinned-occluders-design.md []docs/clustered-froxel-lights-design.md

In this repo:
https://github.com/DrewGilpin/EsenthelEngine

Global Illumination (GI)

Wed, 08 Jul 2026 12:44:32 +0000

It's a subtle lighting feature, but in dark scenes it can make a difference.
Intensity of GI must be increased to really see it especially if there is an ambient light source.
RT hardware accelerated GI has much better performance than pure software (rasterized) GI.

GI ON, intensity cranked so effect is obvious:

GI OFF:

GI ON , yellow arrow is sun direction:

GI OFF:

Left Side GI ON / Right Side GI OFF split screen:

AI Generated Summary:

Fully Dynamic Global Illumination for Esenthel — No Baking, No Authoring

I added a complete real-time diffuse Global Illumination system to the engine’s deferred renderer.

The headline: zero authoring — no baked lightmaps, no hand-placed probes, and no precompute step.

You flip one switch and neutral surfaces start picking up colored bounce light from the walls, terrain, and objects around them. Time-of-day is fully dynamic. The system is Vulkan-only because it needs the compute path, and it is off by default. Existing scenes render byte-for-byte identically until an app explicitly opts in.

There are two interchangeable producers that fill the lighting probes:

[]Rasterized cube capture — works on any GPU and is always available as the fallback.
[]Hardware ray-traced capture — optional ray-query path for GPUs that support it.

How it works

DDGI-style probe grid

A camera-centered 3D grid of irradiance probes follows the camera. The deferred light pass swaps the old flat ambient term for trilinearly interpolated probe irradiance.
Toroidal scrolling

As the camera moves, the probe volume scrolls toroidally, addressed by integer cell index, instead of re-capturing everything. This prevents a re-capture storm when moving through the world.

This also makes it floating-origin and large-world safe because the GI volume effectively rebases for free.
Cascades

Range comes from nested cascades at geometrically increasing spacing. Three cascades cover roughly 24 m to 216 m, with a cross-cascade seam blend so there is no hard visible ring at the cascade boundaries.
DDGI-standard atlases

Each probe captures visibility, either rasterized into a small cube or ray-traced, then compute integrates the result into octahedral irradiance and Chebyshev depth-moment atlases.

The depth moments suppress light leaking through thin walls, and a surface-normal bias helps as well.
Decoupled capture vs. relight

Geometry capture and lighting relight are separated. Both are hard-capped per frame.

The expensive geometry capture is time-sliced and budgeted, so the cost stays bounded. A static scene captures nothing, so it is free when you are not moving. Irradiance converges through temporal blending.
Free time-of-day relight

An optional producer bakes a lighting-independent cube once and relights it each frame with per-bounce sun shadowing. Moving the sun costs no re-capture.
Analytic re-seeding

Scrolled-in probe slots are analytically re-seeded, which kills stale-bounce ghosting during fast movement.
Half-resolution evaluation

Half-res evaluation plus depth-aware bilateral upscale keeps the light-pass cost down.
Optional SSGI

A screen-space near-field bounce layer can be enabled on top of the probe GI for close-range contact GI.

Hardware ray-traced path — opt-in, additive

When ray-query hardware is present and a scene acceleration structure is registered, probe capture can be ray-traced instead of rasterized. This gives correct per-direction occlusion and bounce with no cube-face seams.

RT occlusion moments

GI.raytrace replaces the depth-cube producer with ray-traced occlusion moments. The light pass is unchanged.
RT bounce radiance

GI.raytrace_radiance traces the diffuse bounce itself using cosine-weighted hemisphere gathering with Fibonacci-spiral rays.

It supports textured and average-color albedo. Terrain with no UVs samples the texture’s mean color. It uses the correct hit-surface normal, NdotL, sun shadow rays, radiosity-style multi-bounce, and a per-frame sky-only cube so miss rays sample the real rendered sky.

It reaches pixel parity with the rasterized producer at the same intensity on both Cornell and world scenes.
Zero-registration mode

GIRayTrace.auto_scene = true lets the renderer feed every opaque mesh it draws into the acceleration structure automatically.

Streamed world areas enter the TLAS as they draw and drop out as they stream away, with no app code required. Rebuilds are recorded into the frame command buffer, so there is no GPU stall.

The system is fully hardware-gated and TLAS-gated. If RT is off, unsupported, or unregistered, it falls back to rasterized capture. The software DDGI path is untouched.

Verified working on both AMD RADV and NVIDIA.

Demos

Vulkan build, under Tutorials/Source/14 - Game Basics/

Tutorial_14_DynamicGI
The basics: a neutral scene picking up colored bounce light, with live time-of-day. This is the color-bleed proof.

Tutorial_14_WorldGI
GI over a real streamed Game::World with terrain and props, plus point-light and time controls.

Tutorial_14_LargeWorldGI
GI running under the large-world floating origin. This proves it survives rebases without re-warming.

Tutorial_14_GIShowcase
The “all the knobs” demo. A Cornell room with split-screen A/B.

Controls include:

[]V — split-screen A/B
[]- / = — intensity
[]1 / 2 / 3 — cascade count
[]R — relight
[]B — Chebyshev
[]A — TAA
[]N — SSGI
[]Y — RT moments
[]U — RT radiance
[]Sun, light, and wall toggles

Tutorial_14_RTWorldGI
The payoff: ray-traced GI over a playable streamed world via the zero-registration auto-scene hook.

Controls include:

[]WASD — move
[]G — GI on/off, showing near-black ambient vs. bounced sunlight
[]U — RT radiance vs. rasterized capture
[]Y — RT moments
[]T — time-of-day
[]- / = — intensity

How it is turned off and on

Everything defaults off at the engine level. These are the relevant defaults on the global GI object in Engine/H/Graphics/GI.h, plus GIRayTrace:

GI.enabled
Default: false
Turns on the whole system. Off means legacy flat ambient.

GIRayTrace.auto_scene
Default: false
Turns on zero-registration RT scene feeding.

GI.raytrace
Default: false
Turns on ray-traced occlusion moments.

GI.raytrace_radiance
Default: false
Turns on ray-traced bounce radiance.

GI.relight
Default: false
Turns on the free-time-of-day relight producer.

GI.ssgi
Default: false
Turns on screen-space near-field bounce.

GI.capture_shadows
Default: false
Turns on sun-shadowed lit-cube capture.

GI.chebyshev
Default: true
Turns on leak suppression when GI is enabled.

GI.half_res
Default: true
Turns on half-res evaluation and upscale.

GI.auto_light
Default: true
Derives sun and sky lighting from the live scene.

Canonical app opt-in path

An app opts in from InitPre or Init:

GI.enabled = true;
GI.intensity = 2.0f;
GIRayTrace.auto_scene = true;
GI.raytrace_radiance = true;

GI.enabled is the master switch. Nothing renders GI without it.

GI.intensity controls the indirect multiplier, where 1 is physical.

GIRayTrace.auto_scene is optional and lets the renderer register the scene for ray tracing automatically.

GI.raytrace_radiance is optional and enables ray-traced bounce radiance. It falls back if unsupported.

There are also EE_GI environment-variable overrides, such as:

EE_GI=1
EE_GI_RAYTRACE_RADIANCE=1
EE_GI_INTENSITY=...

Those exist mainly for headless A/B testing. They are not the intended shipping path.

Beyond the app switch, GI is gated on backend support. GI.active() requires the Vulkan compute path. The RT path is additionally gated on ray-query hardware.

So on a non-Vulkan backend, or a GPU without ray-query support, the relevant paths simply no-op or fall back.

Net result: if you do not opt in, nothing about your scene changes.

Build and run one demo

cmake --build cmake-build-release-vulkan --target Tutorial_14_GIShowcase -j $(nproc)

EE_NO_MSG_BOX=1 ./Tutorials/Tutorial_14_GIShowcase

Documentation

Full design notes and knob reference are in:

[]The README’s Dynamic Global Illumination section
[]docs/gi-raytracing-design.md

Available in this engine fork:
https://github.com/DrewGilpin/EsenthelEngine

Improved Water

Mon, 22 Jun 2026 21:29:11 +0000

Video:

https://streamable.com/wfnoh9

Pics:

AI written summary:

Water Rendering Overhaul — Foam, Depth Color, Caustics, Gerstner Swell

I've spent some time giving the water system a proper pass.

The engine's water was already strong: scrolling normal maps, Fresnel, planar + cubemap + SSR reflection, depth refraction with leak detection, density absorption, underwater fog, capsule ripples, and large-world support.

This work fills in the pieces that were missing or weak:

Shoreline foam
Depth-graded surface color
Procedural caustics
Whitecap foam
A real Gerstner wave model with choppiness and wave-speed control

Everything is driven by new per-material parameters on WaterMtrl, all exposed in the Titan Editor → Water Material editor.

The subtle effects — foam, depth color, and caustics — are on by default at low intensity, so existing water looks a little better out of the box without re-authoring.

The heavier Gerstner swell is opt-in:

Code:

Wave Count > 0

What's New

Depth-Graded Surface Color

The surface now blends from a Shallow Color in thin water to the base Color in deep water, using the water-column depth the shader already computes.

This works especially well for carved 3–100 m procedural lakes/rivers and beaches.

Params:

Shallow Color
Depth Color Distance — metres over which it blends; 0 = off

Animated Shoreline Foam

A foam band now appears where the water column gets thin — shorelines, around rocks, and anywhere water meets geometry.

The animation is fully procedural value noise, so no texture asset is required. It churns organically instead of reading as a static pattern.

Params:

Foam Color
Foam Amount — 0 = off
Foam Depth — band width in metres

Procedural Caustics

A cheap two-layer cellular caustic network is projected onto the submerged background and faded by depth.

It is strongest in clear shallows and disappears in deep or opaque water. There is no texture binding, and it is effectively free where the water is deep.

Params:

Caustic Scale — 0 = off
Caustic Intensity

Gerstner Swell — Ocean Technique

The Ocean technique now supports real summed-wave vertex displacement with analytic normals.

Set:

Code:

Wave Count > 0

to switch the Ocean plane from the legacy texture-bump waves to a proper Gerstner wave sum.

Up to 8 waves are synthesized from a few high-level controls.

Includes:

Choppiness — horizontal crest displacement for peaked tops and flatter troughs, which is the defining Gerstner term.
Wave Speed — multiplier on physical deep-water dispersion. 1 = realistic; lower values produce lazy swell, higher values produce faster chop.
Per-wavelength distance fade — long swells carry to distance while short chop settles out.
Global horizon envelope — flattens displacement before the horizon so the far ocean does not alias into shimmer or grid moiré.

Params:

Wave Count
Wave Length
Wave Amplitude
Wave Choppiness
Wave Wind — direction
Wave Speed

Whitecap / Crest Foam

Slope-based foam now builds on steep wave faces as the sea picks up.

It is biased onto the downwind, breaking face of the wave rather than appearing symmetrically on both sides.

Demo

Tutorial_14_OceanWater shows everything running on the global sea over a sloped, bumpy seabed rising to a beach.

Everything is runtime-tunable:

Z / X — calm ↔ storm; ramps wave count, length, amplitude, choppiness, and whitecaps
O / P — wave speed
, / . — rotate wind
F / C — toggle foam / caustics
Mouse swing + wheel — camera look and zoom

Available in this repo:
https://github.com/DrewGilpin/EsenthelEngine

GPU Mesh Shader Grass GoT Style

Fri, 19 Jun 2026 11:32:44 +0000

Best seen in video not pictures:

https://streamable.com/hu3bzs

Grass density can be set per terrain material in Titan Editor:

AI written summary:

GPU Grass (Ghost-of-Tsushima-style) for Titan Engine — feature + tutorial

I've added a GPU-driven grass system to my Esenthel/Titan fork and wanted to share it. It generates grass entirely on the GPU each frame using Vulkan mesh shaders, writing straight into the deferred G-buffer — so the engine's normal lighting, shadows, SSR, and fog apply for free. It's a parallel path that bypasses the shader/material system (the shader compiler has no mesh/task stage), and it's purely additive — the legacy CPU GrassObj foliage still works untouched.

What it does

- Deferred, lit grass on the GPU — VK_EXT_mesh_shader; blades generated per frame, no vertex/index buffers. Vulkan-only (inert on GL/DX, which keep the legacy grass).
- Terrain-following + per-material density — a camera-centered control texture samples terrain height + a density built from terrain slope × the material's grass_density. Blades drape the heightfield, thin on slopes, and grow only where you author them.
- World-anchored + smooth LOD — blades are seeded by absolute world position (no "swim" as the field re-centers), and density fades smoothly with distance instead of popping.
- Interaction:
- trample(pos, radius, strength) — footstep flatten that springs back; a decoupled, world-anchored field uploaded dirty-region only.
- blast(pos, radius, strength) — one-shot radial knockdown shockwave that springs back.
- Exclusion zones — addZoneCircle / addZoneBox(center, half, yaw, soft) → handle, removeZone: persistent analytic CUT footprints (e.g. building placements) where grass is removed with a soft edge, plus a per-patch "fully enclosed → skip" early-out.
- Wind — analytic flow field with traveling gust fronts + a slow sway.

Opt-in by material

Grass density is a per-material attribute (Material::grass_density, 0..1) with an editor "Grass Density" slider. It defaults to 0, so GPU grass is opt-in: enabling the system on an existing world shows nothing until you raise density on the grass materials. Author it toward 1 on grass/dirt, leave it 0 on rock/sand/snow/paths. (This deliberately avoids retro-fitting grass onto every existing material.)

The demo — Tutorial_14_GpuGrass

A character standing in a GPU-grass field on real terrain. Controls:

- WSAD — walk (leaves a trample trail)
- B — blast knockdown
- G — toggle a building CUT zone at the character
- F — force full density everywhere (handy on a world whose materials aren't authored yet)
- Mouse — orbit, Wheel — zoom, Esc — quit

Note: because density is opt-in, the demo shows no grass until you either set a terrain material's Grass Density > 0 in the editor or press F — there's an on-screen hint for this.

Implementation notes / caveats

- Vulkan-only, gated on VkMeshShaderSupported.
- Shaders (grass.task/.mesh/.frag + grass_common.hlsli) are HLSL compiled to SPIR-V by the vendored DXC at engine build time — a parallel path, not via EERegen, so no shader tooling needed at build.
- Drawn from RendererClass::opaque() (RT_DEFERRED) via VkDrawGrass; its own self-contained UBO + descriptor set (not a ShaderVK); reverse-Z + negative-height viewport matched to the deferred config.
- Grass is tagged PSM_TRANSLUCENT and excluded from SSAO (tblades otherwise make screen-space AO shimmer at distance).

In this repo:
https://github.com/DrewGilpin/EsenthelEngine

Terrain Anti-Tiling: distance dual-scale + stochastic "by-example" no asset pipeline

Fri, 19 Jun 2026 03:57:20 +0000

Terrain Anti-Tiling: distance dual-scale + stochastic “by-example” (no asset pipeline)

Before anti-tile:

After anti-tile:

Works best when looking out over the terrain, looking straight down at terrain it doesn't help as much.

Written by AI:

Repeating ground textures betray themselves two different ways, and they need two different fixes:

The far-field grid — from a hill or a grazing camera, the regular periodicity of the texture reads as a checkerboard receding to the horizon.
The close/mid feature repeat — that one distinctive grass clump / rock / crack showing up again every few meters right in front of you.

Two complementary techniques in the deferred terrain shader (

Code:

Engine/Source/Shaders/Deferred.cpp

) address each. Both run on the single- and multi-material terrain paths, up to 5 blended materials, and both are gated to terrain only (

Code:

#if HEIGHTMAP && SET_POS

), so buildings, props, and characters are completely untouched.

1. Distance-based dual-scale: kills the far grid

Sample the same ground texture at two UV scales and blend in the lower-frequency, larger-tile one with camera distance:

Code:

tex = lerp(near, RTex(Col, uv * TileFarScale), fade(distance));

Near the camera you get full detail. Far away, the tight repeat dissolves into a coarser, non-aligned pattern. This is the standard Unreal-landscape-style trick, and it is mip-safe for free, because the two samples use implicit derivatives, so no

Code:

SampleGrad

is needed.

2. Stochastic “by-example”: kills the near/mid feature repeat

This is Heitz–Neyret’s by-example noise, minus the histogram LUT, which means it needs no precomputed assets and no per-texture bake.

Triangular / “hex” grid — 3 samples, no axis-aligned blend seams.
Per-cell random offset only, no mirror — the mirror in the cheaper grid variants is what causes those directional scratches/scuffs on grass. Dropping it removes them.
Variance-preserving blend — naive averaging washes out contrast, so instead of

Code:

sum(w_i * c_i)
, we blend the deviation from the mean and renormalize by

Code:

1 / sqrt(sum(w_i^2))
. The mean is read from the texture’s smallest mip, approximately its average color, so we recover contrast with zero precomputation.
Code:

SampleGrad
keeps mipmapping correct.

The result: a single tiling texture stops repeating and reads as a natural, non-periodic surface — no scratches, no muddy blend blobs.

How to use it

Everything is driven by a single

Code:

TerrainTile

shader cbuffer, set from the public shader-param API:

Code:

SPSet("TerrainTileEnable", 1.0f);  // distance effect

SPSet("TileFarScale", 0.22f);

SPSet("TileFadeStart", 5.0f);      // ...TileFadeRange, TileFarMax

SPSet("TerrainStochastic", 1.0f);  // stochastic de-tiling

It is off by default. The cbuffer is zero-initialized, so nothing changes unless your app sets the params. The editor and all other content render exactly as before.

The params only exist once the terrain shader has loaded, so set them each frame before drawing the world.

Code:

SPSet

safely no-ops until then. There is no engine-wide default yet; you opt in from your render loop.

Parameters

Code:

TerrainTileEnable
— 0/1, distance dual-scale on/off.
Code:

TileFarScale
— coarse UV multiplier. Smaller means bigger far tiles and a stronger frequency break.
Code:

TileFadeStart
— meters: distance where the coarse blend begins.
Code:

TileFadeRange
— meters: distance over which it ramps to

Code:

TileFarMax
.
Code:

TileFarMax
— max fraction of the coarse sample blended in at far distance.
Code:

TerrainStochastic
— 0/1, stochastic de-tiling on/off.
Code:

StochMaxDist
— performance limit: only de-tile within this distance.

Code:

<=0
means no limit.
Code:

StochMinWeight
— performance limit: skip materials whose blend weight is below this. means de-tile all.

Performance limits: opt-in, runtime

Multi-material stochastic can hit up to 5 materials × 4 taps = 20 albedo taps, so there are two runtime knobs:

Code:

StochMaxDist
— only run the stochastic taps within this distance. The far grid is handled by the distance blend anyway, so far pixels drop straight back to 1 tap.
Code:

StochMinWeight
— skip stochastic for a material whose per-pixel blend weight is below a threshold, so a barely-visible layer does not cost 4 taps.

Both default to “no practical limit.”

Large-world / floating-origin

Terrain UVs are world-continuous, built from the absolute area index, so far out in a big world they grow large.

A

Code:

Frac(sin(...))

hash loses precision there and the de-tiling starts aliasing, so the stochastic cell hash is a PCG2D integer hash on the integer cell ID, exact at any magnitude.

The pattern stays locked to the ground and is transparent to floating-origin rebasing. UVs deliberately do not rebase. Shifting them would move the non-integer-aligned stochastic grid and pop the pattern every rebase.

Tutorials

Code:

Tutorial_14_TerrainTiling

Code:

Tutorials/Source/14 - Game Basics/36 - Terrain Tiling.cpp

The live A/B demo. It loads a textured world and lets you toggle and tune everything in real time:

T — distance anti-tiling on/off.
Y — stochastic de-tiling on/off.
1–8 — distance params: strength, fade start, fade range, coarse scale.
G / H — stochastic max distance, for performance.
J / K — stochastic min weight, for performance.
9 — reset all to defaults.
Hold RMB — look.
Mouse wheel — zoom.
ESC — quit.

The HUD shows every value live, and the

Code:

EE_TILE*

env vars let you drive it headless for A/B captures:

Code:

EE_TILE

EE_TILE_STOCH

EE_TILE_CAM_*

EE_TILE_FARMAX

EE_TILE_STOCHDIST

Since the effect lives in the shader, it shows up on any terrain. The other world tutorials are good places to see it on different content once an app enables the params:

Code:

Tutorial_14_World
Code:

Tutorial_14_WorldWithCharacter
Code:

Tutorial_14_ProceduralWorld

Caveats / future work

The only thing the full Heitz histogram LUT would add over this is slightly sharper blend zones. It carries a per-texture asset-bake cost, so it is left out. The variance-preserving approximation looks clean in practice.
One residual issue: the triangular-grid barycentric weights lose a little float precision at extreme UV. The cell hash is exact, so the de-tiling holds; only the blend transitions get marginally coarser very far out.
Backends: Vulkan and GL shader paks are regenerated. DX still needs a Windows tree to recompile, only tested on Linux+Vulkan.

in this repo: https://github.com/DrewGilpin/EsenthelEngine

Shader Cache, Azgaar Map Import, Large Worlds Editor, Procedural Terrain, Portals

Sat, 13 Jun 2026 03:39:07 +0000

Please note I have only been testing Linux Vulkan RADV in my repo, not sure if any of this runs on other platforms/renderers/drivers.

Added a large set of features focused on large-world support, procedural terrain, and streaming.

Titan Editor can now import and edit blended worlds that combine procedural terrain with hand-authored tiled areas. A 250 km x 250 km procedural world is under 100 MB on disk, compared to over 3 TB for an equivalent fully tiled world at the same resolution.

The engine now supports 64-bit large worlds through rebasing and tile-relative storage. Object rendering and PhysX simulation remain accurate and stable at world coordinates like 250,000,250,000 , just as they are near 0,0.

Azgaar (https://azgaar.github.io/Fantasy-Map-Generator/) procedural map import now supports biome data, lake generation, river carving, and water mesh generation. Runtime procedural terrain also supports ring-LOD generation so distant terrain can stream and render efficiently.

Titan Editor fully supports 64-bit worlds by rebasing the editor view and storing all relevant world data relative to tiles.

Portal support was also added. Portals are placed through waypoints in Titan Editor and allow real-time movement to disconnected areas of the large world without a loading screen. As the player approaches a portal, the engine pre-streams tiled areas and generates procedural areas on the destination side so the transition is ready before crossing.

AI Generated repo review of engine changes:

1. Linux-native shader toolchain + EERegen

Vendored DXC v1.9.2602 on Linux, with SPIRV-Cross built from source. Vulkan and GL shader paks can now be regenerated natively on Linux without a Windows machine.
EERegen: a single headless tool that performs shader compilation and Engine.pak / Editor.pak rebundling in one process. This replaces the old two-tool chain of shader-compile build + Engine Builder GUI.
Added a content-hash shader variant cache. Warm regen time dropped from roughly 40 minutes to about 30 seconds. Editing one HLSL file now rebuilds only its affected variants.
Fixed a DXC RelaxedPrecision / OpPhi issue that was causing 544 compile failures in Motion Blur and Temporal shaders.

2. Compiler bug fixed: -fshort-wchar removed

Clang's loop-idiom recognizer was rewriting the engine's string-length loop into a glibc wcslen call built for 32-bit wchar_t. This caused path truncation and memory over-reads at -O2.

The -fshort-wchar flag was removed, which fixed the issue.

3. Vulkan backend fixes and improvements

Fixed 15 tracked Vulkan issues, including:

Device loss from cube-texture views bound to 2D descriptor slots.
Crashes from in-flight buffer/image destruction, fixed with a new deferred-destruction system.
Scene corruption under heavy draw load caused by per-draw UBO ring wrapping. This was replaced with a byte-budget ring.
Eye-adaptation black frame caused by cross-stage image slot collisions.
Per-draw descriptor allocation was O(draws). Switched to dynamic UBO offsets.
Terrain “sparkle” caused by the BRDF LUT being deleted on every render-target reset.
Added per-pipeline descriptor sets.
Added a disk-persistent pipeline cache.
Reduced sync-validation errors from 10 to 0.
Added env-gated abort-on-error debugging tools.

4. Upstream Esenthel sync

Merged upstream main back in, regenerated affected shader paks, and fixed a .gitattributes issue that was causing bogus whole-file merge conflicts.

5. Large World: 64-bit floating origin

Added runtime floating-origin support in Game::World.
Added camera rebase support.
Added tile-relative area storage.
Added water, decal, and navmesh support for large worlds.
Added local-frame pathfinding wrappers.
Added editor support for large worlds, including jitter-free terrain editing and object placement far from origin.
Updated undo/redo so it survives rebasing.
Added world-coordinate display panels.
Added tile-relative game export.
Added an area relocate/convert tool for existing worlds.

6. Procedural terrain + Azgaar world import

Titan Editor supports Import of Azgaar Maps and seamless blending of Procedural+Tiled areas
Added runtime streamed procedural terrain generation.
Generation is multithreaded and prioritizes areas nearest the camera.
Added a far-LOD geo-clipmap backdrop ring so terrain reaches the horizon.
Added climate-driven biomes with per-biome terrain shapes: flat, rolling, rugged, and dunes.
Added three blended ground materials to reduce visible tiling.
Added terrain multi-texturing by slope and altitude.
Added object scatter for trees and rocks, including static collision.
Added sea level and ocean support.
Added rivers carved from Azgaar map data with mitred winding channels.
Added above-sea-level lake basins.
Water and terrain now render at full detail to the horizon.
Added Azgaar Fantasy Map Generator import. Heightmap and biome control maps drive the generated world.
Added an in-game minimap using M, with player position, facing arrow, and click-to-teleport.
Added editor tools: Procedural Terrain dialog, Biome Editor, and Rivers & Lakes dialog.
Procedural config is included with the exported world.
Added per-area navmesh tiles for generated terrain.
Added a tutorial: “Procedural World”. 250 km x 250 km Azgaar Map Demo.

7. Portals

Added portal authoring in the editor.
Added runtime portal crossing.
Added a secondary-streaming-foci API so the destination side can pre-stream before the player crosses.
Added tutorial “21 - Portals” with a sample world.
Portal crossing is seamless, with no flash.
The streaming ring on the departed side is preserved during crossing.
Added a streaming-status HUD.

Honorable mentions

RmlUi improvements: icon: texture loading from the engine image cache, plus same-texture draw batching.
Fixed stale input-action state on popped or masked input maps.
Added memory hardening from ASAN runs, including out-of-bounds guards and completion of the global new/delete family.
Made sizeof(Image) renderer-independent.

Source is in this fork: https://github.com/DrewGilpin/EsenthelEngine

Lag compensation

Wed, 22 Apr 2026 01:28:27 +0000

I had Claude Code improve and bring into the engine the lag compensation I use in my project, it makes FPS and Chivalry/Mount and Blade weapon trail swing games playable and fair even with some clients having 200+ ms pings (overseas players). I use ENET in my case but I kept it transport layer agnostic here.

Networking: Lag Compensation + Physics Rollback
Transport-agnostic server-authoritative simulation layer (lag-compensation branch)

A commercial-grade networking substrate built from scratch under *Engine/Net/*. Two independent tiers of temporal correction, built using shipped-game references:

Tier 1 — selective hitbox rewind (Photon Fusion 2 / Source / CS:GO model). Each server tick, every replicated actor contributes a flat list of hitbox samples into a 256-tick ring buffer (~4.27 s @ 60 Hz). Spatial queries take a *(tick, frac)* pair, linearly interpolate the two bracketing snapshots, and test against the interpolated hitboxes. The live gameplay scene is never touched — perfect for hitscan / melee where you only need “where was this limb when the client fired”.
Tier 2 — full PhysX rewind + resimulation (UE5 networked-physics model). Snapshots pose / linear + angular velocity / kinematic / sleeping flags for every tracked *Actor* each tick; on demand restores them and drives *Physics.stepOnce(dt)* forward to catch up to the current tick. A *RollbackGuard* (TLS depth counter) is held active for the resim window so gameplay / animation / audio code that checks *RollbackGuard::active()* can suppress side-effects (event fire, notifies, SFX) during replay.

All modules are unconditionally compiled — no CMake flag, no opt-out, no extra link cost (the dependency surface is zero — pure C++, no third-party libraries). The transport layer is abstract: the engine ships *LoopbackTransport* (in-process queue) and *FakeLatencyTransport* (wraps any transport with configurable latency / jitter / loss), plus sketches for *ENetTransport* and a multi-hop *ForwardingTransport* in *Engine/H/Net/NetTransport.h* header comments. User projects subclass *INetTransport* and forward to ENet / Steam Sockets / WebRTC / whatever fits their deployment.

Module layout:

*Net/NetTick.h/cpp* — *TickSeq* (*ULong*) + *NetTick{seq, frac}* shared tick + sub-tick type
*Net/NetClock.h/cpp* — NTP-style clock sync; rolling 5-sample median-of-offset + RTT + jitter; monotonic server timeline
*Net/NetTransport.h/cpp* — *INetTransport* abstract + *LoopbackTransport* + *FakeLatencyTransport* + ENet / multi-hop sketches
*Net/NetObject.h/cpp* — *INetReplicated* interface, *NetBase* convenience, *NET_REGISTER_CLASS* factory, *HitboxSample*, *NetWriter* / *NetReader* byte-buffer codecs with opt-in *putUIntPacked* (varint) / *putPosQ16* (quantized position, 6 B vs 12 B) compression helpers
*Net/InputCommand.h/cpp* — *InputCommand* POD + *InputBuffer* (client redundancy — re-sends last N unacked cmds) + *InputQueue* (server per-connection, wrap-safe *UShort* seq compare)
*Net/NetReplicator.h/cpp* — spawn / despawn / snapshot build + apply / input routing / ping-pong / per-connection relevance callback hook
*Net/LagCompensation.h/cpp* — Tier 1 256-tick hitbox ring; *ray* / *sweep* / *sweepArc* / *overlap* / *fetchInterp* CPU-analytic queries (sphere + capsule + box) with *(tick, frac)* OR *(real_time)* addressing for clustered servers
*Net/RollbackGuard.h/cpp* — thread-local depth counter; *RollbackGuard::active()* callable from gameplay / anim code
*Net/NetRollback.h/cpp* — Tier 2 snapshot / restore *Actor* state, *Physics.stepOnce*-driven resim, 8-tick default cap (user-configurable), *InputReplayFn* hook, *AnimCaptureFn* / *AnimRestoreFn* hooks for bone-sourced hitboxes

~3,200 lines of new engine code across 18 files, zero third-party links, zero *#ifdef*s outside platform branches.

Quick start (single-process, both sides in one *Update()* — this is how every category-20 tutorial is structured):

Code:

// --- Replicated actor ---

struct Target : NetBase

{

Vec pos;

NetClassID netClassId()C override { return 0x54475431u; /* 'TGT1' */ }

void netSerialize  (NetWriter &w, UInt fields)C override { w.putVec(pos); }

void netDeserialize(NetReader &r, UInt fields)  override { pos = r.getVec(); }

void netHitboxes(Memc &out)C override

{

HitboxSample &s = out.New();

s.shape = HITBOX_SPHERE;

s.group = 0x0001;

s.half_ext.set(0.3f, 0.3f, 0.3f);

s.xform.identity(); s.xform.pos = pos;

}

};

NET_REGISTER_CLASS(Target, 0x54475431u);

// --- Server ---

NetReplicator SvrRep;  NetClock SvrClk;  LagComp SvrLag;

SvrClk.initServer(60);

SvrRep.serverInit(&transport, &SvrClk);

each_tick:

SvrRep.serverDrainInputs();       // apply client inputs via INetReplicated::netApplyInput

// ...gameplay simulation...

SvrLag.recordTick(SvrRep, tick, Time.curTime());

if(tick % 3 == 0) SvrRep.sendSnapshots(tick);   // 20 Hz @ 60 tick

on_client_fire(from, to, client_tick):

LagHit h;

if(SvrLag.ray(client_tick, 0.0f, from, to, h))

apply_damage(h.owner, h.owner_idx);

// --- Client ---

NetReplicator CliRep;  NetClock CliClk;  InputBuffer CliInputs;

CliClk.initClient(60);

CliRep.clientInit(&transport, &CliClk, /*server_conn*/1);

each_frame:

CliRep.sendPingMaybe();           // periodic NTP sync

CliRep.update(Time.curTime());    // drains spawn/despawn/snapshot/pong

Vec input = sample_keyboard();

pawn->predict(input);             // local prediction on owned pawn

CliInputs.push(input, buttons, CliClk.tick());

CliInputs.sendTo(CliRep);         // redundant — includes last N unacked

CliInputs.ack(CliRep.lastAckedSeq());

on_fire(from, to):

// Ship the compensation tick with the fire cmd so the server can rewind

// to exactly what this client was seeing.

fire_cmd.compensation_tick = CliRep.lastSnapshotTick();

Tier 2 (physics rewind) — only when you actually need resim; most games won't:

NetRollback SvrRoll;
SvrRoll.init(1.0f/60.0f, /*max_resim=*/8);
for(Actor *a : dynamic_physics_actors) SvrRoll.track(*a);

on_physics_step_completed(tick):
SvrRoll.recordTick(tick);

on_authoritative_correction(target_tick):
SvrRoll.rewindAndResimulate(target_tick, currentTick, replayInputs, user);

Physics engine touch points — two small, surgical additions; everything else is pure add-on:

*Physics.stepOnce(Flt dt)* — direct *simulate* + *fetchResults* with no accumulator, no *simulation_step_completed* callback. This is what drives Tier 2 resim. Safe only between frames (after *stopSimulation()* or inside *WorldManager::physics_update()*).
*Time.rollbackDt(Flt dt)* — thread-local override for *Time.d()*. When *> 0*, *Time.d()* returns it instead of the real frame delta. Set automatically by *NetRollback::rewindAndResimulate* per resim tick to the recorded *dt_used*, so animation code (*Motion::updateAuto*, *AnimatedSkeleton::animate*) replays at the exact dt the forward sim used — deterministic bone poses during rewind.

Animation sync hooks for bone-driven hitboxes — if your game's hitboxes are attached to *AnimatedSkeleton* bones (limbs parented to bone slots), both forward-sim animation and rollback-resim animation must reproduce the same per-tick bone poses. Two engine hooks pair them:

Forward sim — set *Time.rollbackDt(icf.timeDeltaPhysics)* before animating each player tick, so *Motion::updateAuto* uses the physics dt instead of the variable frame dt. Restore with *Time.rollbackDt(0)*.
Rollback resim — pass *NetRollback::setAnimCallbacks(cap, rest, user)*. *AnimCaptureFn* serialises every tracked *Motion* (via *Motion::save* or direct field writes) into a small opaque blob per tick (~64 B per motion × N motions × 256 ticks — fits easily). *AnimRestoreFn* does the inverse before the user's *InputReplayFn* fires, so replayed animation code starts from the correct *Motion.time* / *Motion.blend*. Pair this with *if(RollbackGuard::active()) return;* at the top of anim-event consumers (weapon clash SFX, hit sparks) so they don't re-fire during replay.

Includes 7 more tutorials.

in this fork:
https://github.com/DrewGilpin/EsenthelEngine

RmlUi

Mon, 20 Apr 2026 13:58:58 +0000

Claude Code was able to one-shot RmlUi integration into Esenthel.

I'm not a web-dev person, but with Vibe Designing coming soon
( e.g. https://claude.ai/design ) , I think there is value in having a UI
system defined by a declarative language like HTML/CSS.

This also makes it much easier for users to mod or skin the UI if they
want. But really, it's about making it easier for the AI to do it.
Claude Code really seems to struggle with building Esenthel GUIs
programmatically that look good and have the correct font size, etc.,
but with HTML/CSS this problem doesn't exist.

I haven't profiled this, the implementation has not been optimized,
and I'm sure there is a performance penalty. That said, RmlUi is
highly regarded and is designed for games; it is not a full WebKit.

An integration of RmlUi v6.2 (MIT) as
a retained-mode HTML/CSS UI library that coexists with Esenthel's built-in
Gui system without touching it. Both run in the same frame — the native
widget set is still available for lightweight 3D-integrated controls, while
RmlUi handles HTML/CSS/animation-heavy UI (menus, HUDs, settings screens,
chat windows). A single RmlUi render backend lives inside the Engine static
library and drives RmlUi's vertex stream through the engine's existing 2D
batcher, so every renderer backend (DX11, DX12, Vulkan, OpenGL) gets RmlUi
for free with zero backend-specific code.

Game HUD tutorial

Using Esenthel GUI elements and RmlUi elements side-by-side tutorial

Quick start:

Code:

#include "Gui/RmlUi.h"                            // EE::RmlUi::* facade

// In a single .cpp where you author Rml event listeners, DOM manipulation,

// etc. — wrap the RmlUi includes so Esenthel macros and X11 defines don't

// collide with RmlUi's template parameters and enum names:

#include "../../ThirdPartyLibs/begin.h"

#undef T1  #undef T2  #undef T3  #undef T4  #undef T5

#undef T6  #undef T7  #undef T8  #undef T9  #undef T10  #undef T11

#undef Always  #undef NotUseful

#include 

#include "../../ThirdPartyLibs/end.h"

static Rml::Context         *Ctx=null;

static Rml::ElementDocument *Doc=null;

Bool Init()

{

    EE::RmlUi::Init();                                                 // install render + system interfaces

    EE::RmlUi::LoadFontFace("Data/RmlUi/LatoLatin-Regular.ttf");

    Ctx=EE::RmlUi::CreateContext();                                    // sized to D.resW()/D.resH()

    Doc=Ctx->LoadDocument("Data/RmlUi/demo.rml");

    if(Doc)Doc->Show();

    return true;

}

void Shut()   { EE::RmlUi::Shut(); }

Bool Update() {

    if(Kb.bp(KB_ESC))return false;

    Gui.update();

    EE::RmlUi::PumpInput(Ctx);                                         // Ms/Kb -> context

    EE::RmlUi::Update   (Ctx);                                         // events, animations, dirty geometry

    return true;

}

void Draw()   {

    Renderer(RenderScene);                                             // optional 3D world

    Gui.draw();                                                        // Esenthel Gui above 3D

    EE::RmlUi::Render(Ctx);                                            // RmlUi on top of everything

}

Shipped features:

Single-TU backend — Engine/Source/Gui/RmlUi.cpp is the only engine
source file that includes RmlUi headers. It subclasses
Rml::RenderInterface and Rml::SystemInterface, owns the 1×1 white
fallback texture, and exports the EE::RmlUi:: facade used by app code.
Macro pollution is neutralised locally: Esenthel's template-shortcut
macros T1..T11 (from Engine/H/_/defines.h, they collide with
robin_hood.h's template parameters) and X11's Always / NotUseful
(not stripped by Engine/H/_/headers.h) are undefined inside the
ThirdPartyLibs/begin.h / end.h bracket just for this one TU.
API-agnostic rendering — RenderGeometry feeds RmlUi's pixel-space
vertex stream into the engine's existing 2D path. Per-vertex
conversion goes through D.pixelToScreen(Vec2) (canonical helper; no
hand-rolled Y-flip). D.alpha(ALPHA_MERGE) handles RmlUi's
premultiplied RGBA (which it emits since v5). Scissor goes through
D.clip(&engine_rect) / D.pixelToScreen(RectI). Works identically on
DX11, DX12, Vulkan, OpenGL.
Untextured-path fallback — RmlUi calls RenderGeometry with
texture=0 for solid-colour geometry. The backend binds a pre-built
1×1 opaque-white Image so the textured shader path effectively
degenerates to plain vertex colour. This avoids needing a separate
colour-only code path.
FreeType sharing — RmlUi's default FreeType font engine is pointed
at Esenthel's prebuilt EE_FreeType static lib via
FREETYPE_INCLUDE_DIRS / FREETYPE_LIBRARY cache vars in
ThirdPartyLibs/RmlUi/CMakeLists.txt, so one copy of FreeType ships in
the final link. EE_RMLUI_USE_BUNDLED_FREETYPE=ON is an escape hatch
if the prebuilt's config flags ever diverge from what RmlUi expects.
Texture upload — LoadTexture routes to Image.Import, accepting
every format Esenthel's asset pipeline supports (BMP/PNG/JPG/JXL/WEBP/
AVIF/HEIF/TGA/TIF/DDS/PSD/ICO/HDR). GenerateTexture uploads raw
RGBA8 via a soft image, lock/write, row-copy, unlock, and GPU upload
(used for the font atlas and procedural decorator textures).
Dual-mode input pump — EE::RmlUi::PumpInput(ctx) polls
mouse position, mouse buttons, and wheel every frame, walks all
256 KB_KEY values firing key down/up events on edge changes, and
pumps text characters out of Kb.k.c. When the focused RmlUi element
is an input field or textarea the key queue is drained so fast typing
never drops characters; otherwise the head of the queue is peeked
non-destructively so the built-in Gui still sees the same keys on the
same frame.
Opt-in via CMake — option(EE_RMLUI "... " ON) in the root
CMakeLists.txt, default ON on Linux x64 + Windows x64, fatal on iOS
/ Android (deferred until those platforms are tested). With
EE_RMLUI=OFF every integration TU is empty, the
rmlui_core / rmlui_debugger targets are not added to
the build graph, and the tutorial targets are skipped in
Tutorials/CMakeLists.txt.
Built from source — RmlUi v6.2 is vendored at
ThirdPartyLibs/RmlUi/lib/ and compiled via subdirectory inclusion so
rmlui_core + rmlui_debugger become Engine interface link deps.
No prebuilt library like the other third-parties, because upstream
ships clean CMake and the library is small. ABI-visible flags are
forced onto both targets so they match Engine's ABI.
Debugger overlay — rmlui_debugger is linked automatically when
EE_RMLUI=ON. Call Rml::Debugger::Initialise(ctx) once, then
Rml::Debugger::SetVisible(true) (or bind to a key) to pop up the live
inspector — Event Log, Element Info, Outlines, Data Models tabs.
Thin facade — Engine/H/Gui/RmlUi.h exposes only the
EE::RmlUi:: lifecycle and helper functions. It forward-declares
Rml::Context, ElementDocument, RenderInterface, and
SystemInterface, so app translation units that just drive lifecycle
do not pay to parse all of <RmlUi/Core.h>. App translation units
that want event listeners, DOM mutation, or typed element access can
include <RmlUi/Core.h> themselves.

Non-invasive integration — zero changes to Engine/Source/Gui/Gui.cpp,
Gui.draw, Gui.update, no new state in DisplayClass, no new
alpha mode, no new shaders. The pre-existing VI + D 2D path is the
only rendering surface used; the existing 2D shaders are the only ones
touched. The tutorial harness (Tutorials/TutorialAuto.{h,cpp},
Tutorials/stdafx.h) is unchanged. EE_RMLUI=OFF builds are
pixel-identical to pre-integration builds (verified against
Tutorial_05_Bars, Tutorial_04_BatchedDrawing,
Tutorial_12_RenderToTexture).

RCSS gotcha — RmlUi's transition/animation parser recognises tween
names as defined in Source/Core/PropertyParserAnimation.cpp. Unlike
standard CSS, it does not accept bare linear or the CSS keyword
ease; use linear-in-out and cubic-in-out (or any of the
supported {back,bounce,circular,cubic,elastic,exponential,linear,quadratic,quartic,quintic,sine}-{in,out,in-out}
variants). Multi-transitions are comma-separated.

Deferred work:

Custom Rml::FontEngineInterface on top of Esenthel's Font class, so
.pak-packaged fonts could feed RmlUi. Upstream's default FreeType
engine is sufficient for now; TTF files ship alongside the tutorials.
Rml::FileInterface on EE::File — would let RmlUi resolve
.rml / .rcss / texture paths through engine .pak archives. The
stdio fopen default is used currently; tutorials ship plain files
under Tutorials/Data/RmlUi/.
Data Binding (MVC layer via Rml::DataModelConstructor) — supported by
the linked rmlui_core but not yet demonstrated by a tutorial.
Lua bindings (rmlui_lua) — disabled in the wrapper (RMLUI_LUA_BINDINGS=OFF);
enabling would require wiring an Esenthel Lua runtime into the engine
first.
Windows smoke sweep via run_smoke_test.ps1. Linux is covered
(all five tutorials + three regression targets pass).

Available in this repo:
https://github.com/DrewGilpin/EsenthelEngine

Improved Destruction

Mon, 20 Apr 2026 02:21:50 +0000

Fracture Destruction System (improve-destruction-v3 branch)

A production-grade destructible-object system located at Engine/Source/Physics/Fracture*.cpp plus Engine/Source/Game/Objects/Fractured.cpp.

The existing DestructMesh / Game::Destructible implementation from Tutorial 23 is left untouched. The new system ships alongside it under new type names.

Core idea:

A FractureMesh asset pre-bakes a mesh into chunks, a cluster hierarchy, and a connection graph that records which chunks share faces, with per-edge breaking strain.

A Game::Fractured runtime object owns the per-instance state. At runtime, it exists as either a single intact-cluster Actor (cluster proxy) or an array of per-chunk Actors connected by breakable PhysX joints.

Damage accumulates per node, or on the cluster as a whole. Once the threshold is crossed, the object transitions from INTACT to SHATTERED by destroying the proxy and spawning per-chunk actors.

Mass is force-set from bake-time chunk volume so the convex-hull proxy’s mass overestimate does not cause a visible pop at the moment of breakup.

Strain then propagates along the connection graph, so a hit on one chunk weakens its neighbours. This reproduces “spider cracks” style breakage without requiring a full spatial-field solver.

Shipped features:

Five bake patterns

shared-boundary jitter

Cluster proxy (FractureSettings::build_cluster_proxy) — the bake computes a single convex hull over all chunks and stores it on the root Cluster, plus the sum of per-chunk volumes as mass_sum. At spawn, the Fractured object creates one kinematic Actor using this proxy instead of N per-chunk actors. 500 intact crates cost 500 bodies, not 10,000.
Localised release cascade — when damage crosses cluster_break_threshold, Fractured::releaseRootCluster(impact_pos, velocity_delta) destroys the proxy and spawns per-chunk actors, inheriting the proxy’s linear and angular velocity and force-setting each chunk’s mass to the bake-time volume estimate. A distance-falloff kick is then applied only to chunks within 1.5 m of the impact (mass-scaled, velocity-capped at 4 m/s), so a hit near the bottom of a wall does not catapult distant chunks and make anchored sections rubber-band through joints.
Deferred release — applyPointDamage is called from inside PhysX’s onContact callback; destroying and creating actors there corrupts the scene and crashes the next PxRigidActor::is<>() cast. Instead, threshold crossing sets a pending flag plus the impact position and velocity, and the next update() tick flushes the release outside any callback.
Connection-graph strain propagation — Fractured::propagateStrain walks live_edges each frame when damage_dirty. Damage above the weakest-link elastic limit (0.9 * break_threshold) bleeds across edges; smaller hits dissipate via damage_decay_tau without creeping. Broken joints are removed by BFS; any connected component that does not reach an anchor becomes dynamic.
Bake-time anchors — FractureSettings::anchor_volume marks chunks whose centroid is inside the box with FRAC_FLAG_ANCHORED_AT_BAKE. They spawn kinematic, or the cluster proxy spawns kinematic if any member is anchored. Runtime Fracture::setAnchor(obj, chunk_index, anchored) can flip the anchor state live.
Damage API —
Fracture::applyRadialDamage(pos, radius, strength, impulse, type)
applyContactDamage(a, b, contacts, n, type)
breakNode(obj, node_index, dir, type)
setAnchor(...)

All accept a DAMAGE_TYPE enum (KINETIC, EXPLOSIVE, PIERCING, THERMAL, CUSTOM) scaled by a global damage_type_scale[5] table, so game code can do things like make grenades 1.5x stronger against concrete with a single tweak.
Multi-subscriber BreakEventCallback — Fracture::addBreakEventCallback is void-return and never consumes the event. addBreakEventCallbackB is bool-return; returning true consumes the event and stops the chain. Legacy setBreakEventCallback is preserved as a single-slot wrapper.
Debris pool — Fracture::setVfxPoolCap, setSfxVoicesCap, debrisActiveCount, plus low-energy sleep and debris-pool caps in updateDebrisHeuristics. Chunks at rest for debris_sleep_timeout seconds are put to sleep so PhysX stops simulating them.
Save / Load — FractureMesh::save(path) and load(path) round-trip the whole asset (chunks, cooked PhysX convex hulls, cluster, and connection graph) through a versioned CC4('F','R','A','C') binary format.
FractureMesh::adjustStorage(universal, physx, bullet) matches the PhysBody contract and allows the asset to be reloaded on a different backend. A cache (Cache FractureMeshes("Fracture Mesh")) is preserved so UID-addressed baked assets can live inside pak files like any other engine asset.

[]Instance sharing — many Game::Fractured instances can point at the same FractureMesh. Geometry and cooked hulls are shared; only runtime state (damage, actor transforms, live joints) is per-instance.

Non-invasive integration:

Zero changes to DestructMesh, Game::Destructible, or Tutorial 23.

PhysX’s Physics.reportContact is not hijacked. The host app registers its own contact callback and can optionally call Fracture::applyContactDamage from inside it.

Contact damage is PhysX-only, since Bullet does not deliver contact events in this engine. Radial damage works on both backends.

Deferred work:

Multi-level hierarchical fracture (more than 2 levels deep, with per-level break thresholds and cluster-tree view-level LOD). The data model already supports it via Cluster::parent and Cluster::children; the runtime currently walks one level.
Runtime on-the-fly fracture (CSG against an unbaked mesh). Pre-bake only is the shipping path.
View-distance simulation LOD (far objects deferred until the player enters a bubble). The cluster proxy is the foundation; bubble activation logic is planned as a later follow-up.
Multi-platform cooked-hull round-trip. Saved files are currently PhysX-specific; cross-platform support needs adjustStorage(universal=true, ...) before save.
Titan Editor UI for anchor-volume painting, per-chunk material picking, and interactive fracture preview. This branch is intentionally code-only.
Auto-dispatch BreakPreset VFX/SFX from a material tag, so Tutorial 31’s 40-line OnBreak puff could collapse to 5 lines. The scaffolding is already in place (multi-subscriber callbacks, damage types), but the preset registry is deferred.

in this fork:
https://github.com/DrewGilpin/EsenthelEngine

Cloth Physics

Sat, 18 Apr 2026 12:56:10 +0000

Cloth Physics (XPBD)
A first-party CPU cloth solver built into the engine at Engine/Source/Physics/Cloth.{h,cpp} + Engine/Source/Physics/Cloth Solver.{h,cpp}, sitting behind the existing Cloth / ClothMesh public API. Replaces NVIDIA's deprecated PhysX 3.x cloth (removed in PhysX 4+) with an XPBD (Extended Position-Based Dynamics) implementation — stable, deterministic, tunable, and owned entirely by the engine.

Core idea — each cloth is a set of mass-weighted particles connected by constraints. Per simulate(dt) the solver substeps (default 8) Jakobsen-style: semi-implicit-Euler predict → XPBD Gauss-Seidel constraint solve (Δλ = (-C - α̃λ)/(w_i+w_j+α̃), α̃ = compliance/dt²) → collision projection against author-placed balls/capsules → derive velocity from position delta. Pinned particles (inv_mass == 0) follow skeleton bones each sub-step via smooth prev↔cur lerp so fast character motion doesn't yank the cape.

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See README.md for more info.

Behavior Trees, Animation Graph, IK

Sat, 18 Apr 2026 00:06:09 +0000

Behavior Trees (Bt*, animation-state-machine branch)
A data-oriented behavior tree framework for AI decision-making, built into the engine at Engine/H/Game/AI/BehaviorTree.h + Engine/Source/Game/AI/BehaviorTree.cpp. Designed for attachment to Game::Chr subclasses: build a tree of BtNode objects once in Chr::create(), call bt.tick(Time.d()) from Chr::update() each frame.

Animation Graph (Ag*) and IK (animation-state-machine branch)
A production-grade composable pose-graph animation system, built into the engine at Engine/H/Animation/AnimGraph.h + Engine/Source/Animation/AnimGraph.cpp. Sits on top of the existing AnimatedSkeleton::animate() primitives without modifying them, stylistically parallels the BehaviorTree framework on the same branch (Bt* prefix, namespace Game{}, non-virtual update() wrapper + protected doUpdate() dispatch, tree-walking virtuals for viz).

IK On:

IK Off:

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See the README.md for more info.

Frame profiler and Input Action System

Fri, 17 Apr 2026 01:51:30 +0000

In-Engine Frame Profiler
A lightweight CPU scope profiler with an on-screen stats overlay, built into the engine at Engine/H/Misc/Profiler.h + Engine/Source/Misc/Profiler.cpp. Works on all backends (DX11, DX12, Vulkan, GL). Zero overhead when disabled (~1 ns per PROFILE_SCOPE site -- one predictable branch on a cached bool).

Tutorial_04_FrameProfiler (Tutorials/Source/04 - Graphics/Frame Profiler.cpp

Input Action System (rebindable, savable, stacked)
An Unreal/Unity-style action abstraction over Esenthel's raw polling API, built into the engine at Engine/H/Input/Input Action.h + Engine/Source/Input/Input Action.cpp. 100% additive -- no changes to Kb/Ms/Joypads/Touches. Works on all backends and platforms.

Tutorial_05_InputRebinding (Tutorials/Source/05 - Gui/20 - Input Rebinding.cpp)

In this repo: https://github.com/DrewGilpin/EsenthelEngine

DirectX 12 Ultimate rendering backend

Tue, 14 Apr 2026 12:12:36 +0000

In this repo: https://github.com/DrewGilpin/EsenthelEngine

DX12 seems working nicely on Windows 11 nVidia A2000 GPU.

Lines added (by Claude Code) 11,566

See README.md for info on the added DX12 specific tutorials.

Vulkan rendering backend with hardware ray tracing

Thu, 09 Apr 2026 22:18:40 +0000

In this repo: https://github.com/DrewGilpin/EsenthelEngine

Claude Code did ~97% of the work. Added some Vulkan specific tutorials:

Tutorial_17_RayTracing — Hardware ray tracing
The marquee Vulkan-vs-OpenGL feature. Renders a small scene (ground plane + 3 colored boxes) entirely via vkCmdTraceRaysKHR running on the GPU's RT cores — no rasterization at all. Includes:

BLAS (bottom-level acceleration structure) built from raw vertex/index buffers
TLAS (top-level) with one instance of the BLAS
4-shader raytracing pipeline: raygen + primary miss + shadow miss + closest hit
Shader binding table built per Vulkan spec alignment rules
Hardware ray-traced primary rays + hardware ray-traced shadow rays from a directional light, with Lambert shading using flat geometric normals computed in the closest-hit shader via SSBO lookups into the vertex/index buffers
OpenGL has no hardware RT path at all — the legacy GL RT extensions are NV-only and dead. The OpenGL build of this tutorial compiles cleanly but only renders the "Ray tracing: N/A on OpenGL" HUD line.

GPU requirements: any GPU exposing VK_KHR_ray_tracing_pipeline, VK_KHR_acceleration_structure, and VK_KHR_deferred_host_operations. Verified working on AMD Radeon RX 6650 XT (RDNA2) under Mesa RADV; should work on any RTX 20-series+ NVIDIA, RDNA2+ AMD, or Arc Alchemist+ Intel GPU.

Tutorial_17_AsyncCompute — Particle sim on a dedicated compute queue
Demonstrates Vulkan's async-compute feature: a 4096-particle gravity simulation runs on a separate compute queue (when the GPU exposes a queue family with VK_QUEUE_COMPUTE_BIT but NOT VK_QUEUE_GRAPHICS_BIT) while the engine's frame rendering happens in parallel on the graphics queue. OpenGL has no equivalent — it is strictly single-queue.

The HUD reports whether the GPU has a dedicated compute family. The compute shader is hand-written GLSL (particle_update.comp), pre-compiled once to SPIR-V via glslangValidator and checked in as a C header (particle_update_spv.h) so the build needs no shader tooling installed.

Tutorial_17_Benchmark — Renderer throughput benchmark
Renders 50 animated characters in a 10×5 grid with vsync disabled, an atmospheric sky, the FPS counter, and the active API name. On Vulkan it also shows a per-phase GPU time breakdown (Prepare / GBuffer / Light / Sky / Blend / Post) measured via real vkCmdWriteTimestamp query pools. Useful for measuring relative renderer throughput between OpenGL and Vulkan builds on the same hardware.

The GPU timer API (Engine/H/Graphics/GpuTimer.h: GpuTimerEnable, GpuTimerMs, GPU_TIMER_PHASE) is exposed engine-wide so any tutorial can read per-phase GPU times. On DX11/GL it compiles to stubs that return 0.

See README.md for more info.

ChatGPT Codex and GitHub Actions Example Repo

Sun, 08 Jun 2025 05:21:58 +0000

It has been awhile and my previous tutorials/examples using Visual Studio+WSL for Linux dev is a bit outdated, as CLion has improved dramatically on Linux and is now the best IDE imo. So I have made a demo repo of how to use CMake+GitHub Actions to do cross-platform Titan/Esenthel Engine development with full CI in GitHub and also completely build-able by ChatGPT Codex's containers. The engine binaries packaged with this also allow for completely headless linux apps. The example is non-trivial as it also shows ENet, spdlog, and Google Test integration.

GitHub Repo

Medium Article

Tank simulation demo

Mon, 11 Nov 2024 04:15:04 +0000

Let me introduce my gun simulation prototype, featuring:

- An edit mode for each tank component (chassis, mount, barrel, wheels)
- A test mode that displays a procedural physics simulation of tank movement and its main gun/turret control

Download: https://mega.nz/file/bd0XmaLK#LGpboIzX5f...HDdE9vI9bA

Press H to open Help

Enjoy!