<![CDATA[Esenthel Forum - All Forums]]> https://esenthel.com/forum/ Sun, 21 Jun 2026 03:03:44 +0000 MyBB <![CDATA[GPU Mesh Shader Grass GoT Style]]> https://esenthel.com/forum/showthread.php?tid=11827 Fri, 19 Jun 2026 11:32:44 +0000 https://esenthel.com/forum/showthread.php?tid=11827 Best seen in video not pictures:


https://streamable.com/hu3bzs




[Image: Screenshot-From-2026-06-19-07-09-33.png]

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

[Image: Screenshot-From-2026-06-19-07-25-00.png]

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]]> Best seen in video not pictures:


https://streamable.com/hu3bzs




[Image: Screenshot-From-2026-06-19-07-09-33.png]

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

[Image: Screenshot-From-2026-06-19-07-25-00.png]

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]]> <![CDATA[Terrain Anti-Tiling: distance dual-scale + stochastic "by-example" no asset pipeline]]> https://esenthel.com/forum/showthread.php?tid=11826 Fri, 19 Jun 2026 03:57:20 +0000 https://esenthel.com/forum/showthread.php?tid=11826 Terrain Anti-Tiling: distance dual-scale + stochastic “by-example” (no asset pipeline)

Before anti-tile:
[Image: Screenshot-From-2026-06-18-23-39-08.png]

After anti-tile:
[Image: Screenshot-From-2026-06-18-23-38-58.png]

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:

  1. 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.
  2. 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]]> Terrain Anti-Tiling: distance dual-scale + stochastic “by-example” (no asset pipeline)

Before anti-tile:
[Image: Screenshot-From-2026-06-18-23-39-08.png]

After anti-tile:
[Image: Screenshot-From-2026-06-18-23-38-58.png]

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:

  1. 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.
  2. 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]]> <![CDATA[[Bug] TitanEditor EditMaterial::fixOldReflect makes old materials metallic → dark]]> https://esenthel.com/forum/showthread.php?tid=11825 Fri, 19 Jun 2026 02:33:33 +0000 https://esenthel.com/forum/showthread.php?tid=11825
AI solved it, I'm not sure if this is because of some other change I made in the engine or not but here was the solution..

[Bug] TitanEditor EditMaterial::fixOldReflect makes old materials metallic → renders dark (esp. on terrain)

Summary

When an old material (one saved with a single reflect value, before the reflect_min/reflect_max model) is loaded into TitanEditor, EditMaterial::fixOldReflect() can wrongly set reflect_max = 1, turning a dielectric material into a metallic one. On terrain (multi-material rendering) this makes the material render much darker than its texture, because the high reflectivity reads the packed metal channel and metals have ~no diffuse albedo.

Affected code

Editor/.../Shared/Elements/Material.cpp — EditMaterial::fixOldReflect(flt reflect):

void EditMaterial::fixOldReflect(flt reflect)
{
if(metal_map.is())
{
reflect_min=MATERIAL_REFLECT;
reflect_max=reflect;
}else
{
reflect_min=reflect;
reflect_max=1; // <-- bug
}
}

Introduced in commit 60929bf7708b2ff18e92032411928947bf4b74ca (2022-02-21), when the reflect_min/reflect_max model was added — so it's long-standing, not platform-specific.

Root cause

An old single-reflect material had constant reflectivity (it predates per-texture metalness). The no-metal-map branch sets reflect_max = 1, and on publish Material::reflect(min, max) computes:

reflect_add = min; reflect_mul = (1 - min) * max;

So reflect(0.04, 1.0) → reflect_mul ≈ 0.96. The intent appears to be "harmless when there's no metal map," but the multi-material / terrain shader samples the metal channel of the packed base_2 (Ext) texture regardless of whether a separate metal_map was assigned. With reflect_mul ≈ 0.96, reflectivity becomes 0.04 + 0.96 × base_2.metal, i.e. metallic wherever that channel is bright → the surface renders dark. The engine's own old-material Material::loadData conversion, by contrast, uses reflect_mul = 0 (pure dielectric), so the editor was inconsistent with the engine.

Observed effects / how it presents (very confusing!)

- A material's tile preview looks correct/light (single-material path doesn't sample that metal channel), which masks the problem.
- Painted onto terrain it renders dark, and it's per-material (paint the dark material anywhere → dark; the light one → light).
- A raw copy of an old material stays correct (still the old single-reflect format, dielectric). Editing it (tweaking any slider) republishes it through fixOldReflect → it becomes metallic → goes dark and stays dark, even though the color (1,1,1,1) and all visible sliders look normal. The only tell is ReflectivityMax = 1.000 in the material editor.

Reproduction

1. Take an old-format material that has packed base textures and no separate metal_map, with low/constant reflectivity.
2. Assign it to terrain — looks fine.
3. Edit any slider (forces a republish through fixOldReflect).
4. It renders noticeably darker on terrain; the tile preview still looks light.

Fix

Make the no-metal-map branch dielectric (matching the engine and how a normal dielectric material loads, where reflectMax() == 0):

}else
{
reflect_min=reflect;
reflect_max=0; // dielectric: old single-'reflect' materials have constant reflectivity; 0 => reflect_mul=0 (matches Material::loadData)
}]]>
AI solved it, I'm not sure if this is because of some other change I made in the engine or not but here was the solution..

[Bug] TitanEditor EditMaterial::fixOldReflect makes old materials metallic → renders dark (esp. on terrain)

Summary

When an old material (one saved with a single reflect value, before the reflect_min/reflect_max model) is loaded into TitanEditor, EditMaterial::fixOldReflect() can wrongly set reflect_max = 1, turning a dielectric material into a metallic one. On terrain (multi-material rendering) this makes the material render much darker than its texture, because the high reflectivity reads the packed metal channel and metals have ~no diffuse albedo.

Affected code

Editor/.../Shared/Elements/Material.cpp — EditMaterial::fixOldReflect(flt reflect):

void EditMaterial::fixOldReflect(flt reflect)
{
if(metal_map.is())
{
reflect_min=MATERIAL_REFLECT;
reflect_max=reflect;
}else
{
reflect_min=reflect;
reflect_max=1; // <-- bug
}
}

Introduced in commit 60929bf7708b2ff18e92032411928947bf4b74ca (2022-02-21), when the reflect_min/reflect_max model was added — so it's long-standing, not platform-specific.

Root cause

An old single-reflect material had constant reflectivity (it predates per-texture metalness). The no-metal-map branch sets reflect_max = 1, and on publish Material::reflect(min, max) computes:

reflect_add = min; reflect_mul = (1 - min) * max;

So reflect(0.04, 1.0) → reflect_mul ≈ 0.96. The intent appears to be "harmless when there's no metal map," but the multi-material / terrain shader samples the metal channel of the packed base_2 (Ext) texture regardless of whether a separate metal_map was assigned. With reflect_mul ≈ 0.96, reflectivity becomes 0.04 + 0.96 × base_2.metal, i.e. metallic wherever that channel is bright → the surface renders dark. The engine's own old-material Material::loadData conversion, by contrast, uses reflect_mul = 0 (pure dielectric), so the editor was inconsistent with the engine.

Observed effects / how it presents (very confusing!)

- A material's tile preview looks correct/light (single-material path doesn't sample that metal channel), which masks the problem.
- Painted onto terrain it renders dark, and it's per-material (paint the dark material anywhere → dark; the light one → light).
- A raw copy of an old material stays correct (still the old single-reflect format, dielectric). Editing it (tweaking any slider) republishes it through fixOldReflect → it becomes metallic → goes dark and stays dark, even though the color (1,1,1,1) and all visible sliders look normal. The only tell is ReflectivityMax = 1.000 in the material editor.

Reproduction

1. Take an old-format material that has packed base textures and no separate metal_map, with low/constant reflectivity.
2. Assign it to terrain — looks fine.
3. Edit any slider (forces a republish through fixOldReflect).
4. It renders noticeably darker on terrain; the tile preview still looks light.

Fix

Make the no-metal-map branch dielectric (matching the engine and how a normal dielectric material loads, where reflectMax() == 0):

}else
{
reflect_min=reflect;
reflect_max=0; // dielectric: old single-'reflect' materials have constant reflectivity; 0 => reflect_mul=0 (matches Material::loadData)
}]]> <![CDATA[Shader Cache, Azgaar Map Import, Large Worlds Editor, Procedural Terrain, Portals]]> https://esenthel.com/forum/showthread.php?tid=11824 Sat, 13 Jun 2026 03:39:07 +0000 https://esenthel.com/forum/showthread.php?tid=11824 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

[Image: Screenshot-From-2026-06-12-21-24-05.png]

[Image: Screenshot-From-2026-06-12-21-24-39.png]

[Image: Screenshot-From-2026-06-12-21-25-50.png]

[Image: Screenshot-From-2026-06-12-21-27-49.png]

[Image: Screenshot-From-2026-06-12-21-28-00.png]

[Image: Screenshot-From-2026-06-12-23-08-05.png]

[Image: Screenshot-From-2026-06-12-23-08-23.png]

[Image: Screenshot-From-2026-06-12-23-09-07.png]]]> 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

[Image: Screenshot-From-2026-06-12-21-24-05.png]

[Image: Screenshot-From-2026-06-12-21-24-39.png]

[Image: Screenshot-From-2026-06-12-21-25-50.png]

[Image: Screenshot-From-2026-06-12-21-27-49.png]

[Image: Screenshot-From-2026-06-12-21-28-00.png]

[Image: Screenshot-From-2026-06-12-23-08-05.png]

[Image: Screenshot-From-2026-06-12-23-08-23.png]

[Image: Screenshot-From-2026-06-12-23-09-07.png]]]> <![CDATA[June 2026]]> https://esenthel.com/forum/showthread.php?tid=11823 Tue, 02 Jun 2026 06:01:04 +0000 https://esenthel.com/forum/showthread.php?tid=11823 -updated Sound system to operate on VecD positions (64-bit float for high precision huge worlds)]]> -updated Sound system to operate on VecD positions (64-bit float for high precision huge worlds)]]> <![CDATA[[UI Editor] Feature requests]]> https://esenthel.com/forum/showthread.php?tid=11822 Thu, 28 May 2026 09:41:25 +0000 https://esenthel.com/forum/showthread.php?tid=11822
I'd like to propose two additions to the GUI editor window:

1. Multi-Selection Editing
When multiple UI elements are selected, params that are unique per element (Name, Description, and Text) should be greyed out and non-editable. Params that are common across the selection should remain editable. Where selected elements have differing values for a shared param, display "–" as a placeholder to indicate the values are not uniform amongst the selected elements

This would significantly reduce friction when working on complex interfaces. Currently, when adjusting shared properties like scale or size requires selecting all elements, applying the change, deselecting, then selecting an individual element to verify if the param is correct, and repeating. Multi-selection editing would eliminate that process.

2. Configurable Insert Templates for UI Elements
Add a right-click context menu to entries in the standard UI element list. This menu would open a template configuration window where the default parameters for that element type can be set (width, height, text alignment, text size, and skin override).

Buttons are currently inserted with a default width of 0.270, height of 0.060, text alignment 0, text size 1, and an empty skin override. These defaults probably won't match the design of a custom button, meaning every newly placed button requires manual adjustment (although the skin could be configured in an application element). With configurable templates, a developer could define defaults that match their project's design once, rather than correcting values on each new element placed in different GUI's.

Thanks for considering these! Would love to hear feedback!]]>
I'd like to propose two additions to the GUI editor window:

1. Multi-Selection Editing
When multiple UI elements are selected, params that are unique per element (Name, Description, and Text) should be greyed out and non-editable. Params that are common across the selection should remain editable. Where selected elements have differing values for a shared param, display "–" as a placeholder to indicate the values are not uniform amongst the selected elements

This would significantly reduce friction when working on complex interfaces. Currently, when adjusting shared properties like scale or size requires selecting all elements, applying the change, deselecting, then selecting an individual element to verify if the param is correct, and repeating. Multi-selection editing would eliminate that process.

2. Configurable Insert Templates for UI Elements
Add a right-click context menu to entries in the standard UI element list. This menu would open a template configuration window where the default parameters for that element type can be set (width, height, text alignment, text size, and skin override).

Buttons are currently inserted with a default width of 0.270, height of 0.060, text alignment 0, text size 1, and an empty skin override. These defaults probably won't match the design of a custom button, meaning every newly placed button requires manual adjustment (although the skin could be configured in an application element). With configurable templates, a developer could define defaults that match their project's design once, rather than correcting values on each new element placed in different GUI's.

Thanks for considering these! Would love to hear feedback!]]> <![CDATA[May 2026]]> https://esenthel.com/forum/showthread.php?tid=11819 Tue, 05 May 2026 05:03:20 +0000 https://esenthel.com/forum/showthread.php?tid=11819 -fixed physics tutorials not compiling due to updated Box constructor
-added more Edge2 functions
-"Behind" shader now correctly processes "Blend" Materials]]> -fixed physics tutorials not compiling due to updated Box constructor
-added more Edge2 functions
-"Behind" shader now correctly processes "Blend" Materials]]> <![CDATA[Lag compensation]]> https://esenthel.com/forum/showthread.php?tid=11816 Wed, 22 Apr 2026 01:28:27 +0000 https://esenthel.com/forum/showthread.php?tid=11816
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<HitboxSample> &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:

  1. 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)*.
  2. 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.
[Image: Screenshot-from-2026-04-21-21-12-54.png]

in this fork:
https://github.com/DrewGilpin/EsenthelEngine]]>
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<HitboxSample> &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:

  1. 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)*.
  2. 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.
[Image: Screenshot-from-2026-04-21-21-12-54.png]

in this fork:
https://github.com/DrewGilpin/EsenthelEngine]]> <![CDATA[RmlUi]]> https://esenthel.com/forum/showthread.php?tid=11815 Mon, 20 Apr 2026 13:58:58 +0000 https://esenthel.com/forum/showthread.php?tid=11815
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
[Image: nWMwv7tq]


Using Esenthel GUI elements and RmlUi elements side-by-side tutorial
[Image: 3cB1Nk65]


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 <RmlUi/Core.h>
#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 &lt;RmlUi/Core.h&gt;. App translation units
    that want event listeners, DOM mutation, or typed element access can
    include &lt;RmlUi/Core.h&gt; 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]]>
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
[Image: nWMwv7tq]


Using Esenthel GUI elements and RmlUi elements side-by-side tutorial
[Image: 3cB1Nk65]


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 <RmlUi/Core.h>
#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 &lt;RmlUi/Core.h&gt;. App translation units
    that want event listeners, DOM mutation, or typed element access can
    include &lt;RmlUi/Core.h&gt; 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]]> <![CDATA[Improved Destruction]]> https://esenthel.com/forum/showthread.php?tid=11814 Mon, 20 Apr 2026 02:21:50 +0000 https://esenthel.com/forum/showthread.php?tid=11814 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.

[Image: Screenshot-from-2026-04-19-22-14-24.png]

[Image: Screenshot-from-2026-04-19-21-51-13.png]

Shipped features:
    []Five bake patterns (FRACTURE_PATTERN_) —
    PLANAR_SLICES uses random plane cuts and mirrors the classic DestructMesh algorithm.
    UNIFORM_VORONOI and CLUSTERED_VORONOI use iterative SplitMeshSolid with perpendicular-bisector planes; the older CSG-based spike was dropped because it was numerically unstable.
    RADIAL produces true pie-slice wedges radiating from an impact_point through the wall’s thickness axis.
    BRICK uses a dedicated axis-aligned 6-plane-per-cell path (BakeBrickChunks) with shared-boundary jitter: adjacent bricks read the same boundary entry for their shared seam, so jitter never produces gaps between neighbours.
  • 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<FractureMesh> 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]]> 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.

[Image: Screenshot-from-2026-04-19-22-14-24.png]

[Image: Screenshot-from-2026-04-19-21-51-13.png]

Shipped features:
    []Five bake patterns (FRACTURE_PATTERN_) —
    PLANAR_SLICES uses random plane cuts and mirrors the classic DestructMesh algorithm.
    UNIFORM_VORONOI and CLUSTERED_VORONOI use iterative SplitMeshSolid with perpendicular-bisector planes; the older CSG-based spike was dropped because it was numerically unstable.
    RADIAL produces true pie-slice wedges radiating from an impact_point through the wall’s thickness axis.
    BRICK uses a dedicated axis-aligned 6-plane-per-cell path (BakeBrickChunks) with shared-boundary jitter: adjacent bricks read the same boundary entry for their shared seam, so jitter never produces gaps between neighbours.
  • 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<FractureMesh> 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]]> <![CDATA[Cloth Physics]]> https://esenthel.com/forum/showthread.php?tid=11813 Sat, 18 Apr 2026 12:56:10 +0000 https://esenthel.com/forum/showthread.php?tid=11813 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.

[Image: Screenshot-from-2026-04-18-08-13-11.png]

[Image: Screenshot-from-2026-04-18-08-15-29.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See README.md for more info.]]> 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.

[Image: Screenshot-from-2026-04-18-08-13-11.png]

[Image: Screenshot-from-2026-04-18-08-15-29.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See README.md for more info.]]> <![CDATA[Behavior Trees, Animation Graph, IK]]> https://esenthel.com/forum/showthread.php?tid=11812 Sat, 18 Apr 2026 00:06:09 +0000 https://esenthel.com/forum/showthread.php?tid=11812 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.

[Image: Screenshot-from-2026-04-17-19-48-04.png]


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

[Image: Screenshot-from-2026-04-17-19-49-22.png]

IK On:
[Image: Screenshot-from-2026-04-17-16-02-10.png]

IK Off:
[Image: Screenshot-from-2026-04-17-16-02-24.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See the README.md for more info.]]> 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.

[Image: Screenshot-from-2026-04-17-19-48-04.png]


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

[Image: Screenshot-from-2026-04-17-19-49-22.png]

IK On:
[Image: Screenshot-from-2026-04-17-16-02-10.png]

IK Off:
[Image: Screenshot-from-2026-04-17-16-02-24.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine
See the README.md for more info.]]> <![CDATA[Frame profiler and Input Action System]]> https://esenthel.com/forum/showthread.php?tid=11811 Fri, 17 Apr 2026 01:51:30 +0000 https://esenthel.com/forum/showthread.php?tid=11811 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

[Image: Screenshot-from-2026-04-15-12-49-24.png]

[Image: Screenshot-from-2026-04-15-12-49-34.png]


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)

[Image: Screenshot-from-2026-04-16-21-41-02.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine]]> 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

[Image: Screenshot-from-2026-04-15-12-49-24.png]

[Image: Screenshot-from-2026-04-15-12-49-34.png]


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)

[Image: Screenshot-from-2026-04-16-21-41-02.png]

In this repo: https://github.com/DrewGilpin/EsenthelEngine]]> <![CDATA[DirectX 12 Ultimate rendering backend]]> https://esenthel.com/forum/showthread.php?tid=11810 Tue, 14 Apr 2026 12:12:36 +0000 https://esenthel.com/forum/showthread.php?tid=11810 https://github.com/DrewGilpin/EsenthelEngine

DX12 seems working nicely on Windows 11 nVidia A2000 GPU.

Lines added (by Claude Code) 11,566

[Image: dx12meshshaders.png]

See README.md for info on the added DX12 specific tutorials.]]> https://github.com/DrewGilpin/EsenthelEngine

DX12 seems working nicely on Windows 11 nVidia A2000 GPU.

Lines added (by Claude Code) 11,566

[Image: dx12meshshaders.png]

See README.md for info on the added DX12 specific tutorials.]]> <![CDATA[Vulkan rendering backend with hardware ray tracing]]> https://esenthel.com/forum/showthread.php?tid=11809 Thu, 09 Apr 2026 22:18:40 +0000 https://esenthel.com/forum/showthread.php?tid=11809 https://github.com/DrewGilpin/EsenthelEngine

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


[Image: raytracing.png]

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.



[Image: async-compute.png]

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.




[Image: gputimer.png]

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.]]> https://github.com/DrewGilpin/EsenthelEngine

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


[Image: raytracing.png]

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.



[Image: async-compute.png]

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.




[Image: gputimer.png]

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.]]> <![CDATA[Wheel controller/collider]]> https://esenthel.com/forum/showthread.php?tid=11808 Mon, 06 Apr 2026 03:16:14 +0000 https://esenthel.com/forum/showthread.php?tid=11808 <![CDATA[April 2026]]> https://esenthel.com/forum/showthread.php?tid=11806 Fri, 03 Apr 2026 04:20:49 +0000 https://esenthel.com/forum/showthread.php?tid=11806 -reduced stack memory usage for World Editor heightmap building (to fix crashes on Linux)
-replaced ThreadMayUseGPUData / ThreadFinishedUsingGPUData with a helper class GPUDataUse for auto lock and release]]> -reduced stack memory usage for World Editor heightmap building (to fix crashes on Linux)
-replaced ThreadMayUseGPUData / ThreadFinishedUsingGPUData with a helper class GPUDataUse for auto lock and release]]> <![CDATA[March 2026]]> https://esenthel.com/forum/showthread.php?tid=11805 Sat, 07 Mar 2026 06:37:33 +0000 https://esenthel.com/forum/showthread.php?tid=11805 -tweaked vignette to automatically apply perceptual gamma adjustment based on vignette color brightness (now dark colors are stronger)
-'Input/Inputs' now supports all button states
-added translation languages: chinese traditional (CT), turkish (TR), czech (CS), ukrainian (UA), hungarian (HU), indonesian (IND)
-improved performance / reduced memory usage of translation functions
-improved outline shader to draw outlines on the outside (and not on inside which made the objects seem thinner)
-fixed issues when using multi-sampling (motion vector shaders - TAA+MotionBlur, SSR, outline)
-increased default 'SoundMaxConcurrent' to 32
-renamed SP->ES, JP->JA, PO->PT
-improved 'LanguageSpecific' function
-'OSLanguage' now supports detection of Chinese Traditional (CT)]]> -tweaked vignette to automatically apply perceptual gamma adjustment based on vignette color brightness (now dark colors are stronger)
-'Input/Inputs' now supports all button states
-added translation languages: chinese traditional (CT), turkish (TR), czech (CS), ukrainian (UA), hungarian (HU), indonesian (IND)
-improved performance / reduced memory usage of translation functions
-improved outline shader to draw outlines on the outside (and not on inside which made the objects seem thinner)
-fixed issues when using multi-sampling (motion vector shaders - TAA+MotionBlur, SSR, outline)
-increased default 'SoundMaxConcurrent' to 32
-renamed SP->ES, JP->JA, PO->PT
-improved 'LanguageSpecific' function
-'OSLanguage' now supports detection of Chinese Traditional (CT)]]> <![CDATA[New animations]]> https://esenthel.com/forum/showthread.php?tid=11803 Sat, 21 Feb 2026 13:21:05 +0000 https://esenthel.com/forum/showthread.php?tid=11803
Back 2 the future

https://www.youtube.com/watch?v=s3nwI2pvhKM

Johnny Bravo

https://www.youtube.com/watch?v=U5WlK9YZrYw

Will Smith Rap

https://www.youtube.com/watch?v=c-WEwwbNS6w


Superman

https://www.youtube.com/watch?v=pHv1r0SlwwE


Batman

https://www.youtube.com/watch?v=WImSZBtwQ9E]]>
Back 2 the future

https://www.youtube.com/watch?v=s3nwI2pvhKM

Johnny Bravo

https://www.youtube.com/watch?v=U5WlK9YZrYw

Will Smith Rap

https://www.youtube.com/watch?v=c-WEwwbNS6w


Superman

https://www.youtube.com/watch?v=pHv1r0SlwwE


Batman

https://www.youtube.com/watch?v=WImSZBtwQ9E]]> <![CDATA[February 2026]]> https://esenthel.com/forum/showthread.php?tid=11802 Wed, 11 Feb 2026 06:13:29 +0000 https://esenthel.com/forum/showthread.php?tid=11802 -Gui Skin Editor can now edit TextBox Panel
-Gui Window title bar now additionally includes StrEx allowing to include images and text color
-added a new kind of light 'LightPointEx' which is more customizable]]> -Gui Skin Editor can now edit TextBox Panel
-Gui Window title bar now additionally includes StrEx allowing to include images and text color
-added a new kind of light 'LightPointEx' which is more customizable]]>