You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/blog/micro_opt_hell_simd_bit_gather.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
+++
2
2
title = "SIMD Bit-Gather: X86 AVX2 Edition"
3
-
date = 2025-05-21
3
+
date = 2025-06-22
4
4
draft = false
5
5
6
6
[taxonomies]
@@ -28,7 +28,7 @@ It is a simple bit-gather, but vectorized using ``X86 AVX2`` intrinsics.
28
28
For some reason, Burst compiler did not want to vectorize the ``Load4`` internal loop, so I wanted to see if using manually placed intrinsics would be faster.
29
29
It was faster by 3ms on the median time for a chunk of volume ``66^3``, but for a chunk with volume ``34^3``, this is most probably only a marginal improvement. I will most probably remove this for the sake of code cleanliness and upgradeability, since having raw intrinsics like that make modifying the code extremely more convoluted and annoying for such a small speedup. But, I will leave this here on my website just as a way to archive it because I still feel proud of such an optimization, even though it's not that good.
Copy file name to clipboardExpand all lines: content/blog/unity_ecs_2025.md
+64-8Lines changed: 64 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
+++
2
-
title = "The State & Usability of Unity ECS in 2025"
2
+
title = "The state of Unity ECS in 2025"
3
3
date = 2025-05-21
4
4
draft = true
5
5
@@ -26,12 +26,11 @@ Here is the list of the nuances / pitholes, and pros that we feel should be more
26
26
27
27
# Pros
28
28
- Easy to create "entity" like behaviour without worrying about what should be inherited and what should be composited; everything *will* be composited
29
-
29
+
- Umm.... it's.... it's le ECS.... hehehehehe
30
30
31
31
# Cons
32
-
33
32
## Pit Holes
34
-
-``ISystem`` and ``SystemBase````OnCreate`` executes even before some baked entities get created in the world. Meaning that if you want to fetch a baked singleton component to spawn something only **once** you need to do something like *this*:
33
+
-``ISystem`` and ``SystemBase````OnCreate`` executes even before some baked entities get created in the world. Meaning that if you want to fetch a baked singleton component in one of your sub-scenes you need to do something like *this*:
35
34
```cs
36
35
publicpartialstructSystem: ISystem {
37
36
privateboolinitialized;
@@ -49,8 +48,65 @@ public partial struct System: ISystem {
49
48
}
50
49
}
51
50
```
52
-
like what the **fuck**? why can't I just add a ``[CreateAfter(typeof(SomeSceneLoadingSystem))]`` instead and call it a day?????
53
-
54
-
- Why is it that some functions require you to use ``SystemState`` whilst others require you to use ``SystemAPI``?? Why can't you keep it consistent...
55
51
-``ISystem`` can NEVER use or even REFERENCE a managed class type. Even if you don't have ``[BurstCompile]``, you still can't use it in ``ISystem``
56
-
- Due to code gen, using generics (or generic query functions) becomes a bit harder. Still doable as long as you don't use ``SystemAPI``
52
+
- Having a baked child (with a non (1,1,1) scale and with a collider component) will not bake it as a child. Any transformations done on the parent entity will not be propagated to that child or its children. No warning or anything like that to let you know either... lol
53
+
- Due to code gen, using generics (or generic query functions) becomes a bit harder. Still doable as long as you don't use ``SystemAPI``
54
+
- There is no way to force two colliders (a child and a parent) to not be merged during baking when using ``Unity Physics``. So far, I have not found a solution for this. This is really annoying.
55
+
56
+
# SystemAPI discrepencies
57
+
- There are missing ``EntityManager`` methods in ``SystemAPI``.
58
+
- There does not exist a ``SystemAPI.TryGetComponent`` nor ``SystemAPI.TryGetComponentRW``. You have to do a manual ``HasComponent`` check and then fetch the component data
59
+
- There does not exist a ``EntityManager.GetComponentDataRW`` for entities, like ``SystemAPI.GetComponentRW`` for entities.
60
+
61
+
# Entity Baking / Conversion Workflow
62
+
- The ```Entity Baking System```. It's painful that all the GameObject prefabs that can be spawned at runtime must be first converted to Baked Entities. This stops you from using ``Scriptable Objects`` to store ``GameObject`` prefabs to instantiate, as you must keep the data in an ``Authoring````MonoBehaviour`` with corresponding ``Baker``. For example, the following data-driven code:
63
+
```cs
64
+
publicclassSwordData: ScriptableObject {
65
+
publicfloathitDamage;
66
+
publicfloataoeDamage;
67
+
publicfloatrange;
68
+
publicGameObjecthitPrefab;
69
+
}
70
+
```
71
+
72
+
must be converted to all of THIS to be able to instantiate ``hitPrefab`` as an entity
Because you must first add it to the entities baking dependency chain for conversion. That whole system should be removed and instead of using gameobjects, Unity should have implemented an Entity only workflow. Adding that level of complexity (converting from GameObjects to Entities) complicates things, as you can only do that at runtime.
97
+
{% end %}
98
+
99
+
I mean, I understand why they'd opt for this. Having all the data being serialized in entities before spawning them makes loading scenes with lots of entities really quick, as it's just a memory copy practically. No expensive loading. My issue is how they have built the entity conversion workflow on *top* of GameObject based MonoBehaviours instead of coming up with a dedicated solution specifically for ECS.
100
+
101
+
Unity states that "you should be able to mix and match ECS and GameObjects in your projects" but that practically never happens. Either because you need one ECS-specific feature in ECS that isn't supported by MonoBehaviours or because you need one GameObject specific feature that isn't supported by ECS. It's half baked, basically. If they made the runtime Entity component editor able to create entity "Prefabs" and set their components that way, that could save us some trouble, but I bet it wouldn't be easy considering the other design choices.
102
+
103
+
104
+
-``MeshRenderer``s with multiple materials create multiple additional entities during baking, but there's no way for the user to know about these additional entites. This screws you over if you want to keep track of all the mesh renderers of a converted ``GameObject`` so that you could, for example, change their ``RenderFilterSettings`` value at runtime (for example, for changing the light layer value at runtime). At least Unity converts the multi-mat ``MeshRenderer``s to Parents in the ECS world, so you could iterate over its children, but that's still somewhat stupid.
105
+
106
+
# Blob Data
107
+
- No way to check or debug blob data in the editor. Looking at a component with a ``BlobAssetReference`` will NOT show the internal blob data that was baked. There isn't a blob data window tab either. It's as if blobs do not even exist in the editor lol.
name = "Unity Multiplayer Chat Lobby Prototype (2025)"
88
+
desc = "Implemented in a few hours using Unity Netcode for GameObjects."
89
+
tags = ["unity", "multiplayer"]
90
+
links = [
91
+
]
92
+
93
+
[[project]]
94
+
name = "Unity Multiplayer Tic Tac Toe Prototype (2025)"
95
+
desc = "WIP. Using Unity Netcode for GameObjects."
96
+
tags = ["unity", "multiplayer"]
97
+
links = [
98
+
]
99
+
100
+
[[project]]
101
+
name = "Unity Factory Game Prototype (2025)"
102
+
desc = "WIP. Using ECS as the backend. Taking inspiration from Satisfactory / GregTech / Factorio / Create. Maybe something more realistic with more in depth automation."
0 commit comments