Forem: KamilVDono

Deep dive Tainted Grail [4] - MipMaps streaming

KamilVDono — Sun, 21 Dec 2025 12:32:14 +0000

Introduction

What it is?

A texture can have mipmaps. Mipmap level 0 is the original texture, level 1 is downscaled by a factor of 2, level 2 by a factor of 4, and so on.

Mipmaps are generated so that far textures can sample higher mip levels, which means a more pleasant visual output and cheaper sampling. Wikipedia has a very nice example of that phenomenon, as well as the OpenGL GitBook.
The downside is that we need to use more memory:

Why use it?

Most of the time we don't render textures with mip 0, which means we don't need it in memory. That means almost 50% memory reduction per texture. But further mips like mip 1, mip 2, and so on aren't always needed either. That means even more frugal textures.
Screenshots are from the editor. Total texture memory in the editor is wrong because in the editor Unity keeps track of all ever-loaded textures and takes them into account for that stat.

Here are stats of a working system. You can see how many textures are at which mip level. There is 292.4MB of non-streaming textures and 1.2GB overall memory usage, therefore 1.0GB is from streamed textures.

If I force textures to be at mip 0, then memory usage goes up to 3.4GB.

Forced mip 1 results in memory pressure at the 1.1GB level, but makes textures blurred. It may not be very visible in this screenshot, but it's very visible for others scenarios.

Forced mip 5 reduces textures to occupy 299.8MB. If you subtract 292.4MB of non-streamed textures, then you see that 1667 textures take just 7.4MB.

Here is a small table with a summary (by accident I moved a bit, so measurements are a bit different):

More examples can be found at the end of this article.

So as you can see, there are massive savings to achieve here.

Other considerations

The mip level to sample is calculated by the GPU when sampling is performed. Therefore the CPU doesn't know which mip level is needed. To obtain that knowledge we need to calculate it ourselves. For every texture we need to calculate the minimum mip level (mip 0 is original resolution) and either load it if not present (along with all higher levels) or unload unused levels (that step could be skipped if we are under the budget).

That means CPU overhead. Mip level approximation is calculated from UV distribution, distance to camera, and camera setup. That indicates potentially different mip levels for every renderer.

Unity's out of box

Unity inside its engine code has support for CPU mip level approximation for MeshRenderers and SkinnedMeshRenderers. For unknown reasons it's very slow, so Unity implemented sparse updates, so only X renderers are processed per frame.
It's hidden from C# view. That means you can just override an unknown internal value. That means you can either use the texture as is and stick to vanilla renderers, or fully reimplement it yourself.

As you know, we have custom rendering solutions (also the ECS way where there is no mipmaps streaming implemented by Unity – really good job), which indicates we must implement mipmaps streaming (the CPU level calculations and requests part of it; the GPU resources handling is still on Unity's side and cannot be reimplemented) on our own.

Requirements

The first requirements were as follows:

Must be fast
Avoid runtime allocations
Debug capabilities:
- Check when a texture got blurred
- Detect textures which should be streamed but are misconfigured

After the first version more requirements appeared:

The system must have universal inputs, because Drake, Leshy, Medusa, and HLODs must have support for mipmaps streaming.
Easily expandable as more systems may be introduced (and Kandra was added after that point, and the connection between both systems was done in a few lines of code)

Implementations

Version 1

At that time most of the data was held by ECS, so it felt natural to implement it as a System, but at that point we were still using Entities and Entities Graphics as external packages. That meant we needed to duplicate some code related to material registration. Extracting textures from a material is a very costly operation (Unity's shaders and materials pipeline is very sluggish), but slicing in an ECS system is very hard and odd. We needed to maintain multiple caches for materials, textures, refcounts, and mappings.

Duplicated code means unnecessary slowdowns.
A complex and performant caching strategy means giga-complex code, a debugging nightmare, and extending headaches.
Systems are more or less singletons, but still, accessing them and storing data feels awkward.

It wasn't impossible to maintain and plug new rendering systems into this version, but it was a long process.

Debugging capabilities were also nearly non-existent.

Version 2

As I described, there were problems with the first version as it was very rigid and error-prone. Therefore we added requirements that it must be easily expandable to plug in other systems or make changes or fixes.
To simplify the whole code, a small layer of indirection was introduced.
System can register a Material and Material_MipMaps will take care of tracking textures of that Material. Then it's expected that in a background thread that System will provide a Mip Factor associated with MaterialHandle.
For any Material, factors are gathered and Interlocked.CompareExchange is used in a way that we store the min factor.
Then the Textures part of the system takes it and applies similar logic to textures extracted from registered Materials.

You can see that it is very easy to add a new system – just look at the Kandra example:

[BurstCompile]
struct KandraMipmapsFactorJob : IJobFor {
    public CameraData cameraData;
    [ReadOnly] public UnsafeBitmask takenSlots;
    [ReadOnly] public UnsafeBitmask toUnregister;
    [ReadOnly] public UnsafeArray<float> xs;
    [ReadOnly] public UnsafeArray<float> ys;
    [ReadOnly] public UnsafeArray<float> zs;
    [ReadOnly] public UnsafeArray<float> radii;
    [ReadOnly] public UnsafeArray<float4x4> rootBoneMatrices;
    [ReadOnly] public UnsafeArray<float> reciprocalUvDistributions;
    [ReadOnly] public UnsafeArray<UnsafeArray<MipmapsStreamingMasterMaterials.MaterialId>> materialIndices;

    public MipmapsStreamingMasterMaterials.ParallelWriter outMipmapsStreamingWriter;

    public void Execute(int index) {
        var uIndex = (uint)index;
        if (!takenSlots[uIndex] || toUnregister[uIndex]) {
            return;
        }

        var position = new float3(xs[uIndex], ys[uIndex], zs[uIndex]);
        var radius = radii[uIndex];
        var scale = math.square(math.cmax(rootBoneMatrices[uIndex].Scale()));

        var factorFactor = MipmapsStreamingUtils.CalculateMipmapFactorFactor(cameraData, position, radius, scale);
        var fullFactor = reciprocalUvDistributions[uIndex] * factorFactor;
        var subMaterialIndices = materialIndices[uIndex];

        for (uint j = 0; j < subMaterialIndices.Length; j++) {
            outMipmapsStreamingWriter.UpdateMipFactor(subMaterialIndices[j], fullFactor);
        }
    }
}

There are still caveats. The biggest is that you can (Un-)Register a Material mostly during the Update phase. During EarlyUpdate we extract textures if there are newly added Materials. PreLateUpdate: jobs, like the one above, are started. Finally, PostLateUpdate: jobs are completed and per-texture requested levels are updated.

Closing

Mipmaps streaming is a very important technique to lower memory pressure, which is even more important in Unity as it has big memory pressure to start with. Virtual Textures would be better and more impactful, but there is no real solution from the Unity side, and we are not brave enough to do it ourselves (or adopt any solution from GitHub).

Overall, by making the code simpler I was able to make it faster too. A bit of indirection (as opposed to abstraction) makes it easier to think and reason about the topic, and from thinking and reasoning the best optimizations are born.
When designing architecture, be aware of the mental map/image of the tools you are about to use. An ECS System may not be far from a Singleton-like System, nevertheless it could lead to very different architectures – one feeling like a nightmare while the other more like a dream.

More examples of stats

Act I

Starting beach:

Graveyard:

Under bridge:

Act II

Wyrd-tower:

Farmlands:

Inside interior (overworld is loaded in background):

Cuanacht city:

Act II

Village:

Capitol:

Random nowhere:

Deep dive Tainted Grail [3] - Medusa - blazing fast cliffs rendering

KamilVDono — Sun, 19 Oct 2025 14:50:14 +0000

Introduction

The Name

In Greek mythology, Medusa is an entity which possesses the ability to turn others into stone. Such a nice name for a system which was created to render cliffs.

Application

As mentioned above, Medusa was created to accelerate the rendering of cliffs, later rephrased as a very CPU- and memory-friendly way of rendering always visible and fully static meshes.

Why new system

As you know from previous posts we already have Drake and Leshy. Why not to use them?

Drake

Drake uses a slightly modified Entities Graphics for rendering, which means you need to create an entity for each renderer, keep all data on the CPU, and every frame the data is sent to the GPU. There is also binning code, chunk upkeep costs, and other parts which make Entities Graphics and Entities themselves a very generic solution.

Medusa is the opposite of that; it's highly specialized. All data is baked into a file and, at scene startup, loaded into the CPU and sent a single time to the GPU buffers. Meshes and materials are directly referenced. There is no support for data modification.

Another significant difference is frustum culling. Medusa uses sphere-vs-frustum instead of the traditional box-vs-frustum used by Entities Graphics. All of this makes it very CPU-friendly.

Leshy

Leshy is a very nice system, but for cliffs, we need colliders to be present at a much larger distance than is required for Leshy. Also, cliffs are a landscaping tool, so they must be visible from a very, very long distance, meaning cell streaming from Leshy is not needed here. The last requirement is to not change the level designers' workflow; therefore, authoring must be done manually with MeshRenderers.

From this, we can see that Medusa only requires the rendering part from Leshy.

How it works

Colliders

Colliders are always present for the scene; honestly, nothing changes here - we left them unchanged.

Rendering

Based on experience (and code) from Leshy, Medusa uses BRG with a few optimizations. The GPU side is immutable for a scene; once created at scene start, it persists with the same data and layout until scene unloading (when Medusa disposes). This means buffers are ideally linear and fully utilized. Batches are also ideal; for a given submesh, there is always just a single draw call.

Frustum culling is a highly optimized (SIMD in a multithreaded environment) sphere-vs-frustum, with no need for chunking, preprocessing, or any other fancy technique. This is because it's so fast that the entire cost of frustum culling and draw call preparation is hidden by HDRP's render graph main thread interactions.

Baking

As already mentioned, Medusa's objects are just plain Unity rendering primitives (LODGroup + MeshRenderers), so that data must be baked into an optimized data structure, which can be pushed to BRG without wasting user resources. It's also important to have the same data and representation in the final build as well as in Play Mode. To achieve this behavior, we used IProcessSceneWithReport, which is super useful for ensuring consistency and parity between Play Mode and build, but it must be used carefully. Long baking times not only slow down releases but also affect the day-to-day work of everyone who needs to quickly check changes in Play Mode.

If you have a single system that needs to be baked and baking takes 1 second, then it's not a big deal. If you have 15 systems where each bakes in 1 second, that's 15 seconds of idle time for every entry into Play Mode. That adds up quickly: 15 seconds * 10 entries per hour * 8 hours is 20 minutes; that means for every 24 people in the team, one person-day is just idle waiting for Play Mode.

The data is baked into a separate file in StreamingAssets, from where it will be loaded via AsyncReadManager, a fast and parallel file buffer reading API.

Closing

That was a short one, but its brevity shows the strength of experience and solid foundations.

Reuse of already working, established, and well-known systems accelerates progress greatly. I would advise you to copy-paste relevant code and make modifications without haste. After that, compare the source system(s) and the new one to generalize where needed and possible.

Medusa is also a confirmation of the Data-Oriented Design mantra: "Know your domain." We could have stuck to cliffs rendered as common Drake renderers, but after a close look, we saw that there are few cases covered by Drake, and cliffs are so common that we can introduce meaningful optimizations here.

Deep dive Tainted Grail [2] - Leshy - vegetation streaming and rendering

KamilVDono — Sat, 23 Aug 2025 11:48:38 +0000

Introduction

The Name

In Slavic mythology Leshy is a guardian of forests. Which makes perfect name for vegetation related system.

Application

Leshy is a system for rendering vegetation and streaming vegetation placement data.

VSP

Conquest was using VegetationStudioPro (VSP) as a vegetation solution, as the world is procedural, vegetation placement needed to be runtime.
Fall of Avalon has static offline pre-prepared world, that means more optimizations can be introduced.
VSP has storage for offline baking, but VSP is no longer developed nor maintained. That means the issues won't be fixed by package update, we would need to fix these manually and code of VSP is complicated.

Issues

Shaders - VSP uses "old" instancing model, which makes shaders a lot harder to maintain. Every time we upgraded Unity, all vegetation was glitching and required long days of fixing.
Variations limitation - we needed the same prefab spawned with different rules, for VSP every such item () was a separate item, resulting in a lot of small jobs and memory duplication.
Slow open world streaming - streaming was slow and required a lot of small jobs to be scheduled
High memory footprint - rotation and scale weren't compressed

What was good

Editor setup - level designers and artists were already familiar with VSP setup
Procedural placement - algorithm of procedural placement of vegetation is the strongest part of VSP
Baking - VSP can output generated vegetation placement into a file

Solution

VSP

From the list above you can find that editor mode part of VSP was not bad, therefore we kept it. That means vegetation setup, placement, and baking are done by VSP. Then our system will pick up baked data and transform it (baking time) and at runtime it will stream cells, render vegetation and place colliders next to the player.

Entities

As you know, from the previous post, we had experience with Entities. Entities are promoted as fast spawn, fast rendering, low memory overhead. Sounds like a perfect solution.
With transformed data in place, I did a few tests. Every test failed, having hundreds of thousands of vegetation entities spawned and removed is too much for entities, operations were too slow.
Additionally, memory footprint was a few times the number from VSP, as there was a requirement for some additional components and transform is float4x4.

Custom solution

After Entities attempts failed, only fully custom solutions were possible:

There was possibility to rewrite VSP jobs and how it deals with streaming and variants. The shader problem would still be in place.
Custom kind of GPU driven pipeline, most complicated, with most unknowns.
BRG-based rendering, new shiny tech empowering entities with low documentation (still more than other approaches), but entities is good usage example.

With all that, we chose BRG, GPU driven pipeline may yield better performance and memory, but shaders were unknown and may not mean we would achieve it. After time spent on Entities attempts, we wanted a more guaranteed path (and faster to do).

BRG

BatchRendererGroup (BRG) is the heart of modern Unity rendering. I mentioned that Entities Graphics uses it, but new GPU Resident Drawer also uses it.
BRG has a few parts:

Resources registration - register meshes and materials to obtain burstable handles to them
Batches - batch is a graphics buffer with description of the data it contains
Culling callback - callback with struct to fill with drawing data, for most cases you will also perform frustum culling here and maybe other cullings if you are using them (custom LOD solution, custom occlusion culling). You can decide which rendering types you are supporting by passing them to SetEnabledViewTypes.

Resources registration

You need to register meshes and materials, you do it by respectively calling RegisterMesh and RegisterMaterial, which give, respectively, BatchMeshID and BatchMaterialID. After you are done with any asset, you must call UnregisterMesh and UnregisterMaterial with appropriate ID.

Batches

Batch consists of metadata and buffer. You can register batch with AddBatch and that will give you BatchID.
Metadata is an array of MetadataValue.
MetadataValue defines which property it defines, how to interpret data, and where it starts.

static MetadataValue CreateMetadataValue(int nameID, int gpuOffset, bool isPerInstance) {
    const uint IsPerInstanceBit = 0x80000000;
    return new MetadataValue {
        NameID = nameID,
        Value = (uint)gpuOffset | (isPerInstance ? IsPerInstanceBit : 0),
    };
}

Most common are:

unity_ObjectToWorld - Local2World transform in form of matrix with 4 rows and 3 columns
unity_WorldToObject - Inverse of above
unity_MatrixPreviousM - Previous frame Local2World transform required to generate motion vectors

Example

Let's say we want batch where there is a max of 3 instances (to keep visualization possible), support motion vectors, per instance _TintColor and per batch _DebugColor.

Create batch buffer:

var maxInstances = 3;
var uintMatrixSize = sizeof(PackedMatrix) / sizeof(uint);
var uintColorSize = sizeof(Color) / sizeof(uint);

var transformsSize = uintMatrixSize * 3 * maxInstances; // (unity_ObjectToWorld, unity_WorldToObject, unity_MatrixPreviousM)
var colorsSize = uintColorSize * 1 * maxInstances; // _TintColor
var debugColorSize = uintColorSize * 1 * 1; // Per batch singe value of _DebugColor
var fullSize = transformsSize + colorsSize + debugColorSize;

var graphicsBuffer = new GraphicsBuffer(GraphicsBuffer.Target.Raw, fullSize, sizeof(uint));

Now create metadata descriptor:

var metadata = new NativeArray<MetadataValue>(5, Allocator.Temp, NativeArrayOptions.UninitializedMemory);
var offset = 0;

metadata[0] = CreateMetadataValue(Shader.PropertyToID("_DebugColor"), offset, false); // I like to keep per batch data first
offset += sizeof(Color); // Per batch mean it is just single value

metadata[1] = CreateMetadataValue(Shader.PropertyToID("unity_ObjectToWorld"), offset, true);
offset += sizeof(PackedMatrix) * maxInstances;

metadata[2] = CreateMetadataValue(Shader.PropertyToID("unity_WorldToObject"), offset, true);
offset += sizeof(PackedMatrix) * maxInstances;

metadata[3] = CreateMetadataValue(Shader.PropertyToID("unity_MatrixPreviousM"), offset, true);
offset += sizeof(PackedMatrix) * maxInstances;

metadata[4] = CreateMetadataValue(Shader.PropertyToID("_TintColor"), offset, true);
offset += sizeof(Color) * maxInstances;
// If you have more data keep adding it

var batchID = _brg.AddBatch(metadata, graphicsBuffer.bufferHandle);
metadata.Dispose();

With sizes presented as:

Then the buffer would be like this:

But it's hard to read, so let me break that semi-continuous into more described image:

Culling callback

This callback must fill draw data inside BatchCullingOutput. It returns JobHandle therefore the code can be bursted. The callback also contains BatchCullingContext which contains information and all data for performing right culling and producing draw data.

You should perform a few operations here:

Frustum culling
Layer culling
Split calculation

If you implement your own Occlusion Culling you can apply it here as well, Leshy doesn't have occlusion culling.

You also need to determine which views your callback methods support. There are following views available:

Camera - is the main rendering, GBuffer pass, called once per camera
Light - is the shadows maps pass, called for every light with shadows
Picking - when you click in scene view, this callback gets called to determine what you clicked on
SelectionOutline - as the name indicates, used to outline rendering in scene view
Filtering - I think it is used when you are using graying out non-matching when searching in hierarchy window

For main functionality you want to handle Camera and Light.
For camera splitMask is not important, but you must assign it correctly for shadows.

Data

To prepare for the streaming chapter you must know how the data is represented for Leshy.
A vegetation item has rendering data (meshes, materials, lod distances, bounds, and optional collider prefab).
Each vegetation item has its own 2D grid, where each instance is assigned to a grid cell. Instance is represented by float3 position, half4 quaternion and half3 scale. Rotation could be uint but I wasn't aware of such compression method possibility at the time. I said 2D grid cell, but after instances are assigned, cell is no longer represented as square, but instead it is represented as circle.
Last piece is GPU data, the format is described at the BRG section. Leshy is fixed cost here, as it allocates the whole GPU memory at initialization.

Streaming

With rendering handled, the next part was streaming. Very important as it minimizes required memory; it also reduces work done inside culling callback as not present cells don't need to be processed.

Streaming has the following steps:

Calculate visible cells - cell has position and radius, cell visibility is determined by two factors, which are ORed. Cell frustum visibility and cell distance to camera. Cell is checked as circle as sphere vs frustum is faster than box vs frustum.
Cell content loading - cell data is stored in a file, to start loading we need to have loading slot available (to not load too much at once), then loading from file into CPU buffer starts, it will take several frames
Filter data - particular vegetation types support lowering density (so you can lower vegetation density to boost performance), to do that we randomly remove X% of the loaded instances
Cell transfer to GPU - the CPU buffer is then transferred to BRG buffer on the GPU, but that step requires a few actions:
- Find free cell(s) - the single vegetation cell into a single memory block on GPU is preferred, but sometimes it must be split into multiple GPU memory blocks
- Copy CPU minimal data to transfer buffer - CPU data needs padding to fill GPU buffer, so MemCpyStride is used to copy CPU buffer into CPU transfer buffer which will be transferred to GPU memory
- Expand GPU data - CPU data with padding is not what is required by BRG so, we transfer minimal data from CPU to GPU, then compute shader is used to copy and expand data on GPU, from small transfer buffer into big BRG buffer

Stream-out is simple, just clear CPU buffers, and mark CPU representation of GPU memory block(s) as free.

Collisions

Large vegetation (trees, boulders) must have collision, otherwise it would be very odd. Having all spawned vegetation with colliders would kill Unity, so the idea is to place colliders only around the player. To do it, we go with the following steps:

Dispose bitmask for removed cells
For each cell, check if in radius
If in radius, check each instance and generate bitmask which indicates which instance should have collider
Move pooled colliders to the place where we need them
Hide colliders which are not used anymore

Quality

Vegetation has its own setting in graphics settings. The artists must set up what each quality level does for each vegetation type for the following properties:

Density - artists generate vegetation with Ultra density (1.0), then we can specify reduction for lower quality, density cannot change for vegetation with collisions as it would affect gameplay
SpawnDistance - defines the distance from which the cell will be marked as to spawn
Shadows - choose if vegetation should cast shadows
BillboardDistance - for vegetation with billboards defines when billboard starts

Handplacing

Last part of the system, introduced after a few months was the possibility to manually place vegetation and then Leshy during baking will pick it up. For Leshy runtime there is no difference between procedural and handplaced vegetation, all end up in the same data stream.

Issue

Leshy entered the main branch with no major issues or bugs. Also with knowledge from Drake development, Leshy was smooth. For a few months only minor workflow improvements were needed along with optimizations for baking process.
Biggest issue was discovered when we started to play on Xbox, the slower the game was running, the more weirdly the vegetation behaved. We tracked the issues were present for all new graphics APIs (DX12 for PC, DX12 for Xbox and PS5 API), deeper investigation resulted in discovery that there were two system changes required.

First:
Group data binding and compute shader dispatch within command queue, that eliminated some part of misbehavior but not all.

Second:
Don't use LockBufferForWrite. It sounds like a great feature for transferring CPU data to GPU transfer buffer, which then is expanded through compute shader, but even with fence and waiting the data sometimes were corrupted. It may be we did something wrong, but the bug was present mostly on Xbox so debugging became very time consuming, with that in mind we decided to pay additional 0.01ms and go with ordinary SetData.

Closing

You can see how important experience is. If no exploration was done during Drake development then the idea to just use BRG in a custom way won't pop in the mind. We would probably go with custom GPU pipeline, complex shaders tool and encounter more roadblocks. BRG is nicely integrated into engine (especially picking and shaders generation), provides burstable API and eliminates a lot of manual wiring and boilerplate when compared to doing similar instancing system written from scratch, so huge amount of time saved.

With more time I would do vegetation harvesting (so you can remove a particular instance from rendering) and LOD cross-fade. Probably in reverse order, because lack of LOD cross-fade you can see annoying pop-in.

BRG

When Leshy was developed, BRG was a new thing which felt like Unity's future of rendering, that had underlying promise of idea expansion, new features and so on. It was kind of true, new GPU Resident Drawer is based on BRG, it also has GPU occlusion culling. Unfortunately, occlusion culling is not made in a way that can be used by custom BRG-based system, what a shame. That puts a big question mark for how the future of BRG will look. Would it be frozen in its current state for custom projects and only will be expanded and developed for Unity's internal systems?

Another missing pieces are:

Batch lighting - right now you need to deal with each shadow-casting light separately, more for that issue here.
Keyword override - possibility to enable keyword for every material registered would be great, right now if you want such behaviour, you need to create a material copy and manually enable keyword, and somehow track changes to original material and redo them to the copy.
Depth prepass view - right now camera view is used for depth prepass as well as for GBuffer passes. With separate culling I could skip depth prepass for most vegetation, and keep prepass only for big and close renderers. So for 20% of draws I would get 80% of final depth, that is how most of the engines do it.

Deep dive Tainted Grail [1] - Drake - runtime entity renderer registration system

KamilVDono — Thu, 19 Jun 2025 08:04:23 +0000

The Name

Drake is a type of dragon. Dragons are gold keepers, and this system is also golden. :) With this system, I started a naming convention related to mythological creatures/entities.

Background

We faced significant performance issues with MeshRenderers. Internal managers for MeshRenderers were (and may still be) very CPU-intensive, as was frustum culling. However, we needed to use many renderers.
At the time, Entities were nearing version 1.0, and my tests with heavy renderer loads showed much better performance. The idea was straightforward: use Entities for rendering. The requirements were:

Minimal changes to artists' workflows
Only rendering changes (physics and other systems remain unchanged)
Interactivity with Unity's OOP world (most renderers are static, but hundreds require some interaction):
- Follow transforms
- Copy enable/disable state from corresponding GameObject
- Process material change requests (a recent addition)
Streaming via Addressables, as Entities' content management would duplicate assets, and we were unaware of Addressables' scaling limitations

Subscene systems were not feasible for this use case.

First steps

Let's start simple. Just take MeshRenderer and convert it at runtime to entity. It's easy, just use RenderMeshUtility.AddComponents, nice win.
The next step was to remove MeshRenderer and move all required data to DrakeMeshRenderer:

Mesh
Materials
RenderMeshDescription

Editor code was implemented to convert MeshRenderer to DrakeMeshRenderer. The DrakeMeshRenderer itself is just a few lines of code:

var count = _materials.Count;
var renderMeshArray = new RenderMeshArray(_materials, new Mesh[] { _mesh }); // Allocation :(
var localToWorld =  new LocalToWorld(){ Value = transform.localToWorldMatrix };

_entities = new NativeArray<Entity>(count, Allocator.Persistent, NativeArrayOptions.UninitializedMemory);

for(var  i = 0; i < count; ++i)
{
    var entity = entityManager.CreateEntity();

    RenderMeshUtility.AddComponents( // Heavy :(
        entity,
        entityManager,
        desc,
        renderMeshArray,
        MaterialMeshInfo.FromRenderMeshArrayIndices(i, 0, i)
    );
    entityManager.AddComponentData(entity, localToWorld);

    _entities[i] = entity;
}

LOD's

Next, we needed to handle LODGroup conversion by creating entity with LODGroup data and notifying rendering Entities that they are linked to it.

Entities LodGroup

We need MeshLODGroupComponent. It's easy code:

public void Initialize(LODGroup lodGroup)
{
    var transform = lodGroup.transform;
    var worldSize = LodUtils.GetWorldSpaceScale(transform) * lodGroup.size;
    localReferencePoint = lodGroup.localReferencePoint; // Local space

    lodDistances0 = new float4(float.PositiveInfinity);
    odDistances1 = new float4(float.PositiveInfinity);
    var lods = lodGroup.GetLODs();
    for (var i = 0; i < lods.Length; ++i)
    {
        var d = worldSize / lods[i].screenRelativeTransitionHeight; // But here world space ugh
        if (i < 4)
        {
            lodDistances0[i] = d;
        }
        else
        {
            lodDistances1[i - 4] = d;
        }
    }
}

DrakeRendererManager and modifications of DrakeMeshRenderer

Now DrakeMeshRendererneeds to add to its entities MeshLODComponent. So we need to save lod mask at conversion time and we need entity spawned by DrakeLodGroup.
Let me introduce DrakeRendererManager, which creates both renderer and LOD group Entities. so after lod group entity is created we can pass them to spawning of renderers.

For simplicity, we maintain a link between DrakeLodGroup and DrakeMeshRenderer:

DrakeMeshRenderer has an optional reference to DrakeLodGroup.
DrakeLodGroup has an array of DrakeMeshRenderer references, requiring at least one entry (otherwise, it’s an invalid LODGroup).

DrakeRendererManager has two Register methods: one for DrakeLodGroup (DLG) and one for DrakeMeshRenderer (DMR), also called from DLG for each child. Both DLG and DMR call the appropriate method from Start.

Streaming

Streaming is critical to load only necessary meshes and materials. RenderMeshArray and MaterialMeshInfo must be added and removed dynamically.
Addressables uses strings as keys, which cannot be bursted, so we store them indirectly.

Ladies and gentlemen, DrakeMaterialMeshInfo:

public struct DrakeMaterialMeshInfo : IComponentData
{
    public ushort meshIndex;
    public ushort materialIndex;
    public byte submesh;
}

Marvelous one. This component stores material and mesh indices, which require arrays to index them. This led to the creation of DrakeAddressablesManager.
If C# would has header files, for DrakeAddressablesManager it would be like that:

public class DrakeAddressablesManager
{
    Dictionary<string, ushort> _meshKeyToIndex;
    Dictionary<string, ushort> _materialKeyToIndex;

    List<AddressableLoadingData<Mesh>> _meshLoadingData;
    List<AddressableLoadingData<Material>> _materialLoadingData;

public:
    ushort RegisterMaterial(string materialKey);
    void StartLoadingMaterial(ushort materialIndex);
    void StartUnloadingMaterial(ushort materialIndex);

    ushort RegisterMesh(string meshKey);
    void StartLoadingMesh(ushort meshIndex);
    void StartUnloadingMesh(ushort meshIndex);

    Optional<BatchMaterialID> TryGetLoadedMaterial(ushort materialIndex);
    Optional<BatchMeshID> TryGetMesh(ushort meshIndex);
}

and if you wonder, AddressableLoadingData<T>:

public struct AddressableLoadingData<T> where T : Object
{
    public readonly string key;
    public AsyncOperationHandle<T> loadingHandle;
    public ushort counter;
}

During registration, we register keys and add DrakeMaterialMeshInfo instead of RenderMeshArray and MaterialMeshInfo. Then other simple checks if the renderer should be loaded (based on a distance-to-camera vs. LOD distance comparison). If so, StartLoadingMaterial and StartLoadingMesh are called with the corresponding indices.
The next frame, another system checks TryGetLoadedMaterial and TryGetMesh. If both succeed, MaterialMeshInfo is created and added to the entity.

You may ask:
What about RenderMeshArray?

It’s very wasteful, as we know when resources are loaded. We manually replicate RenderMeshArray’s functionality by obtaining EntitiesGraphicsSystem and calling (Un)RegisterMesh or (Un)RegisterMaterial. This eliminates multiple managed array creations - double win.

Mipmaps streaming

It's not topic of this post, but quick mention.
Once mesh loading is complete, we collect UV distribution data. When material loading is finished, we register the material to the mipmap streaming system, which provides a MaterialMipMapsStreamingHandle. After both the mesh and material are loaded and the Entity is spawning, UVDistributionComponent and MipmapsStreamingComponent are added to the Entity. From then on, mipmap streaming systems can process these and update the required mip level.

Let move it

Another requirement: possibility to link transform with renderer entity.
Transforms are one of Unity’s Four Horsemen of the Apocalypse. To avoid killing performance, we use TransformAccessArray.

We model this as: after the simulation step, run IJobParallelForTransform to write transform data back to linked Entities.
The challenge lies in the near-nonexistent documentation for TransformAccessArray. Let me reiterate: one of the most impactful and essential optimization tool lacks explanation - good job Unity as always :)

It's worth mentioning how we store transforms in an ECS unmanaged component:

public struct LinkedTransformComponent : IComponentData, IEquatable<LinkedTransformComponent>
{
    public readonly UnityObjectRef<Transform> transform;

    public LinkedTransformComponent(Transform transform) {
        this.transform = transform;
    }

    public bool Equals(LinkedTransformComponent other) {
        return transform.Equals(other.transform);
    }

    public override int GetHashCode() {
        return transform.GetHashCode();
    }
}

The registration method collects new entities and registers each:

int Register(Entity entity, Transform transform)
{
    if (_freeIds.Length > 0) {
        var lastIndex = _freeIds.Length - 1;
        var index = _freeIds[lastIndex];
        _freeIds.RemoveAtSwapBack(lastIndex);
        _transformsArray[index] = transform;
        _linkedTransformEntities[index] = entity;
        return index;
    }
    var newId = _transformsArray.length;
    _transformsArray.Add(transform);
    _linkedTransformEntities.Add(entity);

    return newId;
}

_freeIds tracks unoccupied transform indices in _transformsArray. At the time, leaving removed transforms in TransformAccessArray was faster than removing them and adjusting Entity indices. We also use LinkedTransformIndexComponent, an ICleanupComponentData storing the index to free.

Two way link

We can read managed data (track transform values), but we also need to manipulate Entities from the managed side.
If requested, LinkedEntitiesAccess MonoBehaviour is added during registration, holding a list of Entities linked to the GameObject. A challenge arises because registration uses EntityCommandBuffer, so the Entity isn’t immediately available. As a workaround, registration creates a LinkedEntitiesAccessRequest with a UnityRef to the LinkedEntitiesAccess MonoBehaviour. After ECB playback, a system processes requests and registers valid Entities to the given LinkedEntitiesAccess. This requires a managed, unbursted system, but I’m unsure if there’s a better approach.

Enable/Disable/Destroy

With access to entities we can react to GameObject state changes: hide entities when GameObject is disabled, show them when is enabled, and destroy renderers alongside with GameObject.

Materials

Often there is need to modify material of renderers (strictly for renderer not material itself). There are two main modifications:

Replace value

This uses custom components tagged with MaterialPropertyAttribute from Entities Graphics. No custom modifications are required, only a smart editor to display possible changes.

Replace whole material

To replace a material, we first register the new material with DrakeResourcesManager, which returns a material index for creating a DrakeMaterialMeshInfo.
Next step is tricky, as it depends on the current state of DrakeMeshRenderer. There are five states to address, but all involve replacing the old DrakeMaterialMeshInfo with a new one. Additional operations primarily include unloading the previously loaded material (decrementing its refcount) and adding or removing certain state components.

Scene unloaded

Scene lifetime management is required.
Startup is easy using MonoBehaviour’s Start (preferred, as spawning agents can edit properties, e.g., mark as non-static).
Unloading is much trickier, as no MonoBehaviour remains (see Optimize/Leftovers section). To solve that issue I created SystemRelatedLifeTime<T> class, with nested IdComponent. IdComponent has just int id and it's ISharedComponentData.
To make such generic component work you need to register every usage with line like:

[assembly: RegisterGenericComponentType(typeof(SystemRelatedLifeTime<DrakeRendererManager>.IdComponent))]

Now you can make query over that component, with filter for specific IdComponent, and destroy all matching entities. It’s highly efficient and elegant.
Id for scene is just scene handle value.

Vertex snap hack

Our artists often use vertex snap tool in editor. Therefore Drake needs to support it, unfortunately there is no such functionality in entites. As a workaround, we made special mode when instead of creating entities we spawn old LodGroups and MeshRenderers as hidden in hierarchy children. That made editor flow very complicated (need to keep track of all Drakes, spawn in two ways, enter/exit play mode edge-cases, prefab editing nightmare, duplication edge-cases, undo and so on).
There is no much more to say, just that Unity editor support is very painful.

Optimize

Leftovers

Once Drakes are registered, there is no need to keep their corresponding MonoBehaviours. In most cases, these are the only components on a GameObject, allowing the GameObject to be destroyed. Often, this leaves the parent GameObject as a leaf node with no components, which can also be purged, and the cycle continues up to needed GameObject.

This results in shallower hierarchies and allows many small memory allocations to be reclaimed faster (after a GarbageCollector run, of course).

Static

If you check entities graphics code, you can find that LodGroup is just to update components on rendering entities.
For static groups with no moving parts, we can skip spawning LODGroup and assign values at spawn time.
The plan is simple: for static group, spawn only fully set up rendering entities. First, we need to determine if the prefab is static. I used the static flag from the GameObject, but since this flag is unavailable in builds, it must be cached during baking.

EntityCommandBuffer

You might hear that EntityManager should be used whenever possible because it’s faster than EntityCommandBuffer. We tested this, but it was significantly slower in our case. At Start, we spawn thousands of entities for Renderers and hundreds for LODGroups in chains of operations on these entities. Most operations occur after a scene loads, though a few take place during gameplay.

For LodGroup chain is like:

Create Entity
Set LocalToWorld
Set MeshLODGroupComponent
Set LinkedTransformComponent
Set IdComponent (shared component)
[Optionally] Add LinkedEntitiesAccessRequest

For Renderer:

Create Entity
Set LocalToWorld
Set WorldRenderBounds
Set DrakeMeshMaterialComponent
[Optionally] Set MeshLODComponent
[Optionally] Set DrakeRendererVisibleRangeComponent
[Optionally] Set LODRange
[Optionally] Set LODWorldReferencePoint
[Optionally] Set LinkedTransformComponent
[Optionally] Set RenderBounds
[Optionally] Set LinkedTransformLocalToWorldOffsetComponent
Set RenderFilterSettings (shared component)
Set IdComponent (shared component)
[Optionally] Add LinkedEntitiesAccessRequest

Archetypes

Adding components is expensive, so we create Entities with the correct archetype using DrakeRendererArchetypeKey. It covers all configurations, and the manager generates archetypes for each.
Main logic looks like:

static DrakeRendererArchetypeKey[] CreateAllValues() {
    // _static * _isTransparent * _hasLod * _inMotionPass * _lightProbeUsage * _hasShadowsOverriden * _hasLocalToWorldOffset
    DrakeRendererArchetypeKey[] values = new DrakeRendererArchetypeKey[2*2*2*2*4*2*2];
    int index = 0;
    for (int i = 0; i < 2; i++) {
        var isStatic = i == 1;
        for (int j = 0; j < 2; j++) {
            var isTransparent = j == 1;
            for (int k = 0; k < 2; k++) {
                var hasLod = k == 1;
                for (int l = 0; l < 2; l++) {
                    var inMotion = l == 1;
                    for (int m = 0; m < 4; m++) {
                        var lightProbeUsage = m == 0 ? LightProbeUsage.Off : (LightProbeUsage)(1 << (m-1));
                        for (int n = 0; n < 2; n++) {
                            var hasShadowsOverriden = n == 1;
                            for (int o = 0; o < 2; o++) {
                                var hasLocalToWorldOffset = o == 1;
                                values[index++] = new DrakeRendererArchetypeKey(isStatic, isTransparent, hasLod, inMotion, lightProbeUsage, hasShadowsOverriden, hasLocalToWorldOffset);
                            }
                        }
                    }
                }
            }
        }
    }
    return values;
}

var archetypeKeys = DrakeRendererArchetypeKey.All;
_entityArchetypes = new NativeHashMap<DrakeRendererArchetypeKey, EntityArchetype>(archetypeKeys.Length, Allocator.Domain);
foreach (var archetypeKey in archetypeKeys) {
    _entityArchetypes.Add(archetypeKey, CreateArchetype(archetypeKey, entityManager));
}

// From Unity.Rendering.RenderMeshUtility.EntitiesGraphicsComponentTypes
EntityArchetype CreateArchetype(DrakeRendererArchetypeKey archetypeKey, EntityManager entityManager)
{
    var components = new UnsafeList<ComponentType>(24, ARAlloc.Temp) {
        ComponentType.ReadWrite<WorldRenderBounds>(),
        ComponentType.ReadWrite<DrakeMeshMaterialComponent>(),
        ComponentType.ReadWrite<PerInstanceCullingTag>(),
        ComponentType.ReadWrite<WorldToLocal_Tag>(),
        ComponentType.ReadWrite<LocalToWorld>(),
        ComponentType.ReadWrite<MipmapsFactorComponent>(),

        ComponentType.ChunkComponent<ChunkWorldRenderBounds>(),

        ComponentType.ReadWrite<RenderFilterSettings>(),
        ComponentType.ReadWrite<SystemRelatedLifeTime<DrakeRendererManager>.IdComponent>(),
        ComponentType.ReadWrite<ShadowsProcessedTag>(),
    };

    if (archetypeKey.isStatic)
    {
        components.Add(ComponentType.ReadWrite<Static>());
    }
    else
    {
        components.Add(ComponentType.ReadWrite<LinkedTransformComponent>());
        components.Add(ComponentType.ReadWrite<RenderBounds>());
        if (archetypeKey.inMotionPass)
        {
            components.Add(ComponentType.ReadWrite<BuiltinMaterialPropertyUnity_MatrixPreviousM>());
        }
        if (archetypeKey.hasLocalToWorldOffset)
        {
            components.Add(ComponentType.ReadWrite<LinkedTransformLocalToWorldOffsetComponent>());
        }
    }

    if (archetypeKey.hasLodGroup)
    {
        components.Add(ComponentType.ReadWrite<DrakeRendererVisibleRangeComponent>());
        components.Add(ComponentType.ReadWrite<LODRange>());
        components.Add(ComponentType.ReadWrite<LODWorldReferencePoint>());
        if (!archetypeKey.isStatic)
        {
            components.Add(ComponentType.ReadWrite<MeshLODComponent>());
        }
    }
    else
    {
        components.Add(ComponentType.ReadWrite<DrakeRendererLoadRequestTag>());
    }

    if (archetypeKey.isTransparent)
    {
        components.Add(ComponentType.ReadWrite<DepthSorted_Tag>());
    }
    if (archetypeKey.lightProbeUsage == LightProbeUsage.BlendProbes)
    {
        components.Add(ComponentType.ReadWrite<BlendProbeTag>());
    }
    else if (archetypeKey.lightProbeUsage == LightProbeUsage.CustomProvided)
    {
        components.Add(ComponentType.ReadWrite<CustomProbeTag>());
    }
    if (archetypeKey.hasShadowsOverriden)
    {
        components.Add(ComponentType.ReadWrite<ShadowsChangedTag>());
    }
#if UNITY_EDITOR
#if DEBUG
    components.Add(ComponentType.ReadWrite<CullingDistancePreviewComponent>());
#endif
    if (!UnityEditor.EditorPrefs.GetBool("showEntities", false)) {
        components.Add(ComponentType.ReadWrite<EntityGuid>());
    }

    components.Add(ComponentType.ReadWrite<EditorRenderData>());
#endif

    var archetype = entityManager.CreateArchetype(components.AsNativeArray());
    components.Dispose();
    return archetype;
}

This reduces runtime operations significantly.

Scene parts hide/show

In the “Two-Way Link” section, I mentioned that entities access is managed per LOD hierarchy. That isn't always optimal. In game, we handle several map region changes, that involve hiding or showing many such hierarchies, leading to numerous small operations for each action and and requires many LinkedEntitiesAccess MonoBehaviours.
To address it, we introduced SharedLinkedEntitiesAccess: if available in a parent, we register entities to it instead of creating a new LinkedEntitiesAccess.

Merged drake

We have a lot static drakes, each renderer and LOD group requires short living MonoBehaviour. That mean a lot of small allocations.
Lot of small allocations is definition of bad memory management.
Solution is fairly simple:

At build:

Collect all static Drakes from scene
Create a single MergedDrake GameObject with GUID
Collect all data required to spawn collected Drakes
Serialize data as binary into file in StreamingAssets, file is addressed by GUID
Remove processed Drakes

At runtime:

Load data into Temp native allocation
Register all meshes and materials
Spawn Drakes via a bursted job
Release data

This requires only one MonoBehaviour with single field (GUID) and, as a bonus, spawning is now bursted. Big win for simple batching.

Closing

As you can see, even a 'simple' "runtime entity renderer registration system" can be complex.
At the same time, you may notice that even a straightforward system, when scaled, reveals new optimization opportunities.
To see it in action, try playing Tainted Grail: The Fall of Avalon and count how many rendering is going on (be aware there is no occulusion culling) :)

Deep dive Tainted Grail [0] - Introduction

KamilVDono — Sat, 31 May 2025 11:54:41 +0000

Best place to start is from beginning

Inheritance

Fall of Avalon is second digital game in Tainted Grail IP. First game in series is Conquest. Development history of Conquest could fill a book, tltr it started as small indie project and grew into medium-sized indie game. We had systems designed for small indie game, but managed to scale them up for medium-sized one. These systems were then copied over to Fall of Avalon as foundation.

Another big success we carried over from Conquest was the team. Team building is topic worthy of PhD thesis and in many ways more impactful than tech itself in determining game's overall success.

So we had two key components: systems built on top of Unity and team that performed well with Unity and the tools (a subset of those systems).

(Not so) Fresh start

You have team proficient with Unity and tools built on top of it. You have tools within Unity and systems (which tools rely on). So it made sense to take these and start new project, especially since Fall of Avalon wasn’t entirely different from Conquest. But there was catch: systems were originally built for small indie game. We already scaled them up once for Conquest, so we thought we could do it again. It kind of worked, but not without issues.

Systems

Here is list of main systems at beginning of TG:FoA:

MVC (custom)
Unnamed event bus (integrated with MVC, so I’ll treat it as part of MVC for now)
Story graphs (custom node system for story)
Addressables
HDRP
FMod
Visual scripting
A* project
VFX Graph

The cornerstone: MV(C)

Let’s start with core system inherited from Conquest: MV(C).

In this setup:

M - Model: where logical data lives.
V - View: prefab spawned to visualize model data.
C - Controller: but not existed :)
S(ilient) - Service: global functionality that’s too broad to fit into model.

Yes, the C part of MVC is missing but not big issue, you can get used to it.

Let’s dive deeper into actual components, starting from end.

Service

Services are straightforward: they provide globally available functionality that’s too specialized to be model. Good examples:

Regrowable Service: lets you register ID and time when you want to be pinged.
ID Service: provides next unique ID for given model type.

Service is singleton you can query by type. There’s no dependency injection, so any dependencies need to be handled manually:

Injected during initialization (in constructor or initialize method).
Queried when method that requires dependency is called.

View

View defines prefab, where to spawn it, and contains glue code between Unity objects and models. Exact nature of this glue code isn’t strictly defined, so you might see fat view paired with gameplay model or thin view with UI model and gameplay model.

This setup introduces clean separation: View handles Unity-specific elements, keeping model layer almost engine-agnostic, which is nice feature. But since this separation is more about model, let’s finish View first.

Regarding prefabs: they’re optional. If you don’t provide path, new GameObject is created and View MonoBehaviour is attached to it. If you do provide path, prefab is loaded from Resources—yes, old method, but we need synchronous loading and Addressables aren’t reliable for that. So prefabs can’t contain heavy content; heavy content is lazy-loaded via Addressables.

One thing to note: we don’t rely on Unity’s object lifetime. MVC has its own lifetime management. Spawned prefab with View MonoBehaviour is valid MVC object, even if it’s not yet "Awake" in Unity or has been "Destroyed".

Model

Model contains logic and data/state (classic OOP). Entire gameplay is built from models. Often UI creates its own intermediate models to reduce logic inside view.

Single model can spawn zero to multiple views when it’s created. For example, hero model might spawn 3D model in game world and portrait with HP and MP on HUD. Views can also be removed at any time without disposing of model. In most cases, model-view relationship is managed automatically by MVC.

Models have four main types of relationships:

Hierarchy - Model can be child of another model, it's main (or at least should be) main type. For example, FastTravel element is child of Location model. Parent knows when child is added or removed, and child’s lifetime is tied to parent—it can’t exist without it.
Hard Ref Field - Model can have direct reference to another model.
Weak Ref Field - Model can have field with another model’s ID, resolving reference each time and checking if it’s still valid.
Named Relation - It is possible to create a class that defines the relationship between models. For example, one Item can be owned by one Character; one Character can own zero, one, or multiple Items. Such relationships have automatic management by MVC. For example, a relationship will be automatically terminated if one of the sides is disposed.

While this hierarchy promotes a composition-over-inheritance approach, there's nothing to discourage you from using inheritance.

As mentioned in View section, models are designed to be engine-agnostic. In Conquest, where Unity was mostly visualization layer for logic and state, this worked well. But in TG:FoA, gameplay logic is tightly coupled with physics, visuals, and Unity’s state. So what was strength became weakness: model lifetimes are independent of Unity object lifetimes, but logic is deeply intertwined with Unity. Welcome to lifetime management hell. :)

Since the Model is a base class, there is no support for structs. While this wasn't an initial concern, it ultimately led to two massive pessimization:

The MVC architecture cannot be bursted at all.
Even temporary allocations are practically impossible with native or stack allocations; mostly only slow managed allocations or static caches are possible.

This, combined with an 'every-call-is-cache-miss' scenario, results in a massive performance hit.

Events

Event system is at core of MVC, so let’s cover it here.

Events are defined by an ID, generic constraints on the model (specifying that the event can only be triggered on a particular model type or its inheritors), and a payload type.
Any model can trigger any event on any other model (as long as generic constraints are met), and any model can listen to any event on any model. You can also listen for all events of certain type, not just on specific model.

To clarify, here’s some pseudocode:

// Event declaration
public static class Events {
    public static readonly Event<IGrounded, TeleportData> Teleported = new Event<IGrounded, TeleportData>(nameof(Teleported));
}

public class Location : Model, IGrounded {
    public void Teleport(Vector3 newPosition) {
        Move(newPosition);
        // Call event on myself
        this.Trigger(Events.Teleported, new TeleportData(this, oldPosition, newPosition));
    }
}

public class LocationTeleportListener : Model {
    public void SingularListen(Location target){
        // Listen for specific model for Events.Teleported
        target.Listen(Events.Teleported, Callback);
    }

    public void AnyListen() {
        // Listen for all event of type Events.Teleported
        EventsSystem.ListenAny(Events.Teleported, Callback);
    }

    void Callback(TeleportData data) {
        // Do something
    }
}

The 'any event, any model, any listener' aspect might sound like a readability nightmare, but it's not so scary in practice. That said, discovering the implicit connections between models can be tedious at times.

Saving (and loading)

Models have built-in support for saving. System automatically dumps eligible models into JSON blob. It uses reflection to determine which fields to include, and then JSON engine serializes them.
Loading is straightforward: read JSON, deserialize models, and call their restoration methods. There's nothing particularly complex about it.

There's nothing fancy here, but you can probably tell that reflection and JSON are the antithesis of performance. So, you can expect a future post dedicated to saving and loading optimizations.

Other systems

Other systems are more or less publicly available, or were created as part of TG:FoA so it's not necessary to introduce them.
Only the "technological stack" built on our very proprietary baseline required an introduction.
Nevertheless, it's beneficial to show what we ended up with and what will likely be covered in future posts.

You can find a list of the initial systems at the beginning of the document, and here is a list of the final systems:

MVC
Addressables (never again)
HDRP (with small custom optimizations)
FMod (with optimizations at Unity glue-code level)
Visual scripting (never again)
A* project (with custom optimizations)
Entities with graphics (with custom optimizations and fixes)
VFX Graph
Leshy (custom system for vegetation streaming and rendering)
Medusa (custom system for static environment assets like cliffs and terrains)
Drake (custom runtime rendering baking to ECS, with optimizations and systems for OOP interactions)
Scenes baking (system to merge multiple scenes into one, then split into dynamic and static parts, and flatten hierarchy)
Kandra (custom system for rendering skeletal meshes with mesh-mesh culling)
HLODs (custom system for clustering and merging multiple renderers into single simplified mesh, ECS-based rendering)
Mipmaps streaming (built on Unity’s system, adapted for ECS and other custom systems)
Binary serialization via source generator
Various smaller utilities (rain textures, cheap VFX mesh sampling, debug tools, flocks with vertex animations, cheap splatmap sampling, Pix and Superluminal markers)

This isn’t order I’ll cover them in future posts. I plan to discuss custom systems chronologically, starting with Drake and then Leshy.

In addition to custom systems, I’ll also cover some key optimizations we implemented. Stay tuned for those and future posts.