Extremely Inefficient LOD in Unity DOTS

cominooficial · August 5, 2024, 1:18am

Hello,

I recently reviewed Unity’s ECS Galaxy Sample and noticed that instead of using Unity’s built-in LOD (Level of Detail) system, they developed their own custom solution. This approach intrigued me, especially since they claim that “Our tests have shown that this approach to handling simple LOD entity transforms takes roughly 1/5th of the time taken by the default transform hierarchy approach.”

github.com

Unity-Technologies/ECSGalaxySample/blob/main/_Documentation/code-overview.md#lods

# Code Overview

## Table of Contents
* [Game Initialization](./code-overview.md#game-initialization)
* [Authoring Setup](./code-overview.md#authoring-setup)
* [Planets](./code-overview.md#planets)
* [Buildings](./code-overview.md#buildings)
* [Ships](./code-overview.md#ships)
* [AI](./code-overview.md#ai)
* [Entity Initialization and Death](./code-overview.md#entity-initialization-and-death)
* [Acceleration Structures](./code-overview.md#acceleration-structures)
* [VFX](./code-overview.md#vfx)
* [LODs](./code-overview.md#lods)

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

## Game Initialization

All game initialization is handled in `GameInitializeSystem`. It waits for an entity with a `Config` component to exist, and waits for `Config.MustInitializeGame` to be true. Once this condition is met, it initializes the game in these main steps:
* Spawn team managers and team home planets.

This file has been truncated. show original

Given this context, I am curious as to why Unity has not provided a more efficient solution. I observed that the transform system in Unity DOTS is relatively heavy: Child is 80 bytes, LocalToWorld is 64 bytes, LocalTransform is 32 bytes, and Parent is 8 bytes. In comparison, the QVVS Transforms system from the Latios Framework uses only 48 bytes.

github.com

Dreaming381/Latios-Framework-Documentation/blob/main/Transforms/README.md#chunk-efficiency

# QVVS Transforms

QVVS Transforms is a collections of 3D transform systems based on a concept of a
QVVS representation. A QVVS is a vector-based representation of an object
transform that can account for position, rotation, and uniform scale in both
local space and world space. In addition, it can also account for a flavor of
non-uniform scale in local space referred to as **stretch**. Stretch influences
children positions as one would expect, but does not influence children in such
a way that would introduce shear. This makes QVVS transforms ideal for
representing skeletal squash-and-stretch animations or physics-based elastic
compounds.

Check out the [Getting Started](Getting%20Started.md) page!

## Features

### QVVS Types and Operations

The module defines the basic struct types `TransformQvvs` and `TransformQvs`
which you can use in any of your own types regardless of which flavor of

This file has been truncated. show original

Could someone explain why Unity has not developed a lighter and more efficient transformation system? Is there any known approach or plan to improve this?

Thank you in advance for any insights and clarifications

Spy-Master · August 5, 2024, 1:55am

Internal capacity of Child was set to 0 (from 8) in 1.3.0-exp.1, so the size for that is down to 16 bytes.

Where did that figure come from? The page looks to say the best case is 48 bytes.

cominooficial · August 5, 2024, 2:32am

Thank you very much for the information. I was concerned about the size of the Child component, which led me to consider reducing the number of enemies in the game. Currently, with a maximum of 128 entities, it is nearly impossible to save bytes and accommodate more than 128 entities while simultaneously using Physics and graphics.

For reference, the memory sizes of the components I am working with are as follows:

LocalToWorld: 64 bytes
LocalTransform: 32 bytes
RenderBounds: 24 bytes
WorldRenderBounds: 24 bytes
EntityGuid: 16 bytes
MaterialMeshInfo: 12 bytes
Entity: 8 bytes
PhysicsMass: 48 bytes
PhysicsVelocity: 24 bytes
PhysicsCollider: 8 bytes
PhysicsDamping: 8 bytes
PhysicsGravityFactor: 4 bytes

The total memory usage for these components is 288 bytes. Given these constraints, any additional suggestions or best practices for optimizing component size and performance would be greatly appreciated.

Just the Unity components already limit me to having no more than 128 entities! And the Child component with 80 bytes really complicates things. I even lament the 8 bytes that the Entity carries instead of 4 bytes.

Yes, it is indeed 48 bytes, my mistake, I apologize for the confusion. I will correct it.

DreamingImLatios · August 5, 2024, 2:43am

I can clarify a few things regarding my solution.

Roots are 48 + 16. Children are actually heavier than Unity’s starting with Entities 1.3 because they have the cache, though children also tend to have a lighter archetype, so there’s a little bit of a functionality/speed tradeoff there.

Standalone rendered dynamic entities I believe are 124 bytes total (that is excluding the EntityGuid), so it is possible to fill up a chunk completely, though you usually have some simulation components involved. But chunk occupancy is the least-likely problem here. More likely are the algorithms used for processing the children. Unity Transforms uses a depth-first algorithm which is quite wasteful of the cache. I have a breadth-first chunk-based algorithm which is much faster at greater scale.

However, even better than faster transforms is simply packing all your LOD levels into a single entity. Latios-Framework-Documentation/Optimization Adventures/Part 13 - LODS 1.md at main · Dreaming381/Latios-Framework-Documentation · GitHub

cominooficial · August 5, 2024, 3:45am

I understand now, and it has become clearer to me. I really appreciated the LOD approach, and I plan to explore all the optimization techniques in more detail when I have more time. I would love to use Latios, but my current situation does not allow for it. I hope you continue the excellent work and are able to keep updating Latios.

Since I have the opportunity to speak with you, I am curious about your perspective on areas where DOTS could be improved. While it is clear to me that LOD needs enhancement, are there any other aspects you believe could be better?

Thank you again for your insights and assistance.

DreamingImLatios · August 5, 2024, 4:14am

I think just about every aspect of DOTS could be improved in some way. It is a matter of choosing your battles, or more realistically, not backing down when the battles choose you. There are very few people in the DOTS space who will battle on your behalf, and everyone has their own strengths, weaknesses, and biases you have to be wary of.

You mention that your current situation does not allow for using the framework. That would imply you don’t have any side projects or experiments. That’s the wrong thought process. If you aren’t spending some time exploring things independent of your main project, you are severely crippling your growth trajectory.