Esenthel Forum - All Forums

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

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

RTGI+RT SHADOWS+RT Reflections

No GI, CSM Shadows,

AI written summary:

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

Clustered/froxel lighting

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

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

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

The Shared Foundation: One Scene TLAS, Zero Registration

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

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

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

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

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

Animated characters are supported too.

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

Costs only a fraction of a millisecond per character

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

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

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

Ray-Traced Sun Shadows

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

[]Hit = shadowed []Miss = illuminated

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

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

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

Shadow-mask blur

Advantages over shadow maps

No aliasing, cascade seams, or peter-panning.

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

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

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

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

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

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

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

RtShadows(true);

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

Demo: Tutorial_14_RTShadows

- / =

An on-screen HUD displays GPU cost

The initial implementation supports the sun only.

Ray-Traced Specular Reflections

The reflection pass traces one:

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

Reflection hits are fully lit and textured using:

The hit material's actual albedo texture

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

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

Where it beats SSR

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

The RT path can reflect:

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

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

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

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

RtReflections(true);
Demo: Tutorial_14_RTReflections

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

Combined Ray-Tracing Showcase

Tutorial_14_RTShowcase runs all three ray-traced systems together:

Specular reflections

All three systems share the same automatically constructed TLAS.

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

R — ray-traced reflections

Clustered / Froxel Lighting

Clustered lighting addresses a different renderer bottleneck.

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

The clustered path targets unshadowed point lights such as:

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

A compute pass bins lights into a froxel grid containing:

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

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

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

Measured GPU_TIMER_LIGHT results with overlapping, unshadowed point lights:

5% faster

13% faster

256 lights: approximately 19% faster

The performance advantage grows with light count.

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

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

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

Sub-rectangle views

This keeps rendering parity from being placed at risk.

ClusteredLights(true);
Demo: Tutorial_14_ClusteredLights

The demo presents a twilight field containing 256 overlapping lights.

Up / Down

The light-phase GPU timer is displayed on screen

Additional Notes

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

Design Documents

The repository contains detailed design documents for each system:

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

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

Global Illumination (GI)

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

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

GI ON, intensity cranked so effect is obvious:

GI OFF:

GI ON , yellow arrow is sun direction:

GI OFF:

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

AI Generated Summary:

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

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

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

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

There are two interchangeable producers that fill the lighting probes:

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

How it works

DDGI-style probe grid

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

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

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

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

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

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

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

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

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

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

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

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

Hardware ray-traced path — opt-in, additive

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

RT occlusion moments

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

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

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

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

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

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

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

Verified working on both AMD RADV and NVIDIA.

Demos

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

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

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

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

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

Controls include:

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

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

Controls include:

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

How it is turned off and on

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

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

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

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

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

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

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

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

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

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

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

Canonical app opt-in path

An app opts in from InitPre or Init:

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

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

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

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

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

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

EE_GI=1
EE_GI_RAYTRACE_RADIANCE=1
EE_GI_INTENSITY=...

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

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

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

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

Build and run one demo

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

EE_NO_MSG_BOX=1 ./Tutorials/Tutorial_14_GIShowcase

Documentation

Full design notes and knob reference are in:

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

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

July 2026

Fri, 03 Jul 2026 04:58:27 +0000

Updated Esenthel Source:
-fixed bug in matrix inversion

[Elements] Addition of more formats

Sun, 28 Jun 2026 11:35:14 +0000

Hi there,

Theora has been around for quite some time, and many of the newer video formats are not supported. Can we check if we can include more formats for videos?

Thanks a bunch!

Titan Editor v77.0.0.0 reports projects created with newer Titan Engine ver

Sun, 28 Jun 2026 11:21:38 +0000

Hello,
I'm experiencing an issue where the Titan Editor (binary version 77.0.0.0) refuses to open projects I purchased from the Esenthel Store, claiming they were created with a newer version of Titan Engine.
Affected projects: Esenthel MMO (Source Code) and Esenthel RPG 2 (Source Code).
Error message: "This project was created with a newer version of Titan Engine. Please upgrade your Titan software and try again."
Steps already taken: Re-downloaded the installer from the official source, Completely reinstalled Titan Editor, and Verified that the installed version remains 77.0.0.0

I do not have access to the Titan Engine source code. the binary version appears to be outdated compared to what the purchased projects require, this prevents me from using products I have legally purchased

Any guidance on how to resolve this version mismatch would be greatly appreciated.

Thank you in advance for your help.

Captura de tela 2026-06-28 074545.png (Size: 114.73 KB / Downloads: 8)

Captura de tela 2026-06-28 080700.png (Size: 11.98 KB / Downloads: 8)

Improved Water

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

Video:

https://streamable.com/wfnoh9

Pics:

AI written summary:

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

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

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

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

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

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

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

The heavier Gerstner swell is opt-in:

Code:

Wave Count > 0

What's New

Depth-Graded Surface Color

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

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

Params:

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

Animated Shoreline Foam

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

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

Params:

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

Procedural Caustics

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

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

Params:

Caustic Scale — 0 = off
Caustic Intensity

Gerstner Swell — Ocean Technique

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

Set:

Code:

Wave Count > 0

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

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

Includes:

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

Params:

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

Whitecap / Crest Foam

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

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

Demo

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

Everything is runtime-tunable:

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

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

GPU Mesh Shader Grass GoT Style

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

Best seen in video not pictures:

https://streamable.com/hu3bzs

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

AI written summary:

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

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

What it does

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

Opt-in by material

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

The demo — Tutorial_14_GpuGrass

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

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

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

Implementation notes / caveats

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

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

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

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

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

Before anti-tile:

After anti-tile:

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

Written by AI:

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

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

Two complementary techniques in the deferred terrain shader (

Code:

Engine/Source/Shaders/Deferred.cpp

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

Code:

#if HEIGHTMAP && SET_POS

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

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

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

Code:

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

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

Code:

SampleGrad

is needed.

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

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

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

Code:

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

Code:

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

SampleGrad
keeps mipmapping correct.

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

How to use it

Everything is driven by a single

Code:

TerrainTile

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

Code:

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

SPSet("TileFarScale", 0.22f);

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

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

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

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

Code:

SPSet

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

Parameters

Code:

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

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

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

TileFadeRange
— meters: distance over which it ramps to

Code:

TileFarMax
.
Code:

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

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

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

Code:

<=0
means no limit.
Code:

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

Performance limits: opt-in, runtime

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

Code:

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

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

Both default to “no practical limit.”

Large-world / floating-origin

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

A

Code:

Frac(sin(...))

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

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

Tutorials

Code:

Tutorial_14_TerrainTiling

Code:

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

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

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

The HUD shows every value live, and the

Code:

EE_TILE*

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

Code:

EE_TILE

EE_TILE_STOCH

EE_TILE_CAM_*

EE_TILE_FARMAX

EE_TILE_STOCHDIST

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

Code:

Tutorial_14_World
Code:

Tutorial_14_WorldWithCharacter
Code:

Tutorial_14_ProceduralWorld

Caveats / future work

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

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

[Bug] TitanEditor EditMaterial::fixOldReflect makes old materials metallic → dark

Fri, 19 Jun 2026 02:33:33 +0000

I noticed when I would change any parameter of the "Path" material in the Tutorials in Titan Editor the material would immediately become darker.

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

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

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

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

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

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

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

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

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

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

AI Generated repo review of engine changes:

1. Linux-native shader toolchain + EERegen

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

2. Compiler bug fixed: -fshort-wchar removed

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

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

3. Vulkan backend fixes and improvements

Fixed 15 tracked Vulkan issues, including:

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

4. Upstream Esenthel sync

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

5. Large World: 64-bit floating origin

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

6. Procedural terrain + Azgaar world import

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

7. Portals

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

Honorable mentions

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

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

June 2026

Tue, 02 Jun 2026 06:01:04 +0000

Updated Esenthel Source:
-updated Sound system to operate on VecD positions (64-bit float for high precision huge worlds)

[UI Editor] Feature requests

Thu, 28 May 2026 09:41:25 +0000

Hi,

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!

May 2026

Tue, 05 May 2026 05:03:20 +0000

Updated Esenthel Source:
-fixed physics tutorials not compiling due to updated Box constructor
-added more Edge2 functions
-"Behind" shader now correctly processes "Blend" Materials

Lag compensation

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

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

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

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

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

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

Module layout:

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

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

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

Code:

// --- Replicated actor ---

struct Target : NetBase

{

Vec pos;

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

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

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

void netHitboxes(Memc &out)C override

{

HitboxSample &s = out.New();

s.shape = HITBOX_SPHERE;

s.group = 0x0001;

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

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

}

};

NET_REGISTER_CLASS(Target, 0x54475431u);

// --- Server ---

NetReplicator SvrRep;  NetClock SvrClk;  LagComp SvrLag;

SvrClk.initServer(60);

SvrRep.serverInit(&transport, &SvrClk);

each_tick:

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

// ...gameplay simulation...

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

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

on_client_fire(from, to, client_tick):

LagHit h;

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

apply_damage(h.owner, h.owner_idx);

// --- Client ---

NetReplicator CliRep;  NetClock CliClk;  InputBuffer CliInputs;

CliClk.initClient(60);

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

each_frame:

CliRep.sendPingMaybe();           // periodic NTP sync

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

Vec input = sample_keyboard();

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

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

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

CliInputs.ack(CliRep.lastAckedSeq());

on_fire(from, to):

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

// to exactly what this client was seeing.

fire_cmd.compensation_tick = CliRep.lastSnapshotTick();

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

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

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

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

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

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

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

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

Includes 7 more tutorials.

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

RmlUi

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

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

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

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

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

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

Game HUD tutorial

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

Quick start:

Code:

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

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

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

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

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

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

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

#undef Always  #undef NotUseful

#include 

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

static Rml::Context         *Ctx=null;

static Rml::ElementDocument *Doc=null;

Bool Init()

{

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

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

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

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

    if(Doc)Doc->Show();

    return true;

}

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

Bool Update() {

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

    Gui.update();

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

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

    return true;

}

void Draw()   {

    Renderer(RenderScene);                                             // optional 3D world

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

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

}

Shipped features:

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

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

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

Deferred work:

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

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

Improved Destruction

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

Fracture Destruction System (improve-destruction-v3 branch)

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

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

Core idea:

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

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

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

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

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

Shipped features:

Five bake patterns

shared-boundary jitter

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

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

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

Non-invasive integration:

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

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

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

Deferred work:

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

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

Cloth Physics

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

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

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

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

Behavior Trees, Animation Graph, IK

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

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

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

IK On:

IK Off:

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

Frame profiler and Input Action System

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

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

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

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

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

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

DirectX 12 Ultimate rendering backend

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

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

DX12 seems working nicely on Windows 11 nVidia A2000 GPU.

Lines added (by Claude Code) 11,566

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