Is there a Name component for entities?

Unity Engine
,
1

I noticed the Entity Debugger shows names of Entities that were converted from GameObjects, but I couldn’t figure out the mechanism.

But my main point is I’d like a built-in Name component to hold the original name of the GameObject.
It’s useful in many places, like the implementation of the Entity Debugger and Animation (since the curves in an AnimationClip hold the affected target object through a path string), or for debugging purposes in standalone builds, and probably many more scenarios.

Note that I work with pure ECS (project tiny), so if currently the Entity Debugger uses the hybrid mechanism that links an entity to a gameobject to figure out the name, I can’t use that. I’d need a pure Name component sitting on the Entity.

Of course I could roll my own with the conversion system, but I’d like to know if there’s a built in option first, or if there are any plans to add a built-in one?

2

Conversion uses EntityManager.SetName(entity) but only works on Editor (you can check the underlines in EntityManagerDebug.cs on Unity.Entities package).
You can create your own Name component using one of the NativeString*. NativeString* uses a fixed buffer to store the string with fixed (max) size. So passing NativeString* as a copy is expensive and converting to a C# string (calling ToString) will allocate. They used to be inside the Unity.Entities package but later was moved to Unity.Collections package. I’m not sure if this will available in Tiny.

Example:

public struct Name : IComponentData {
    // Can store up to 30 characters
    // 1 char equals 2 bytes plus 4 bytes (int) to store the length
    public NativeString64 Value;
}

[ ]'s

3 Likes
3

Hi, thanks, yeah, no, I know how to roll my own with NativeString, but the point is Unity should have a built in one.
Indeed I see there’s a SetName and GetName in EntityManager, thanks, didn’t know about those. Not sure why it’s done like that and not through a component, but maybe it’s because NativeString didn’t exist back then and they knew it would be a temp solution, which is probably why they’re Editor only anyway.

There should exist an opt-in built-in one to unify all these systems that need the name, instead of each system rolling their own Name implementation.

4

IIRC they where introduced about the same time.

As a component, definitely it shouldn’t. It takes space of the chunk and makes adding/removing components slower (more data to be moved). As another solution, maybe it could.
Why it should? What’s your case? Excluding some named entities and URL data I barely have any need to use strings stored in entities to justify a need for built-in system. And for the cases that I’ve mentioned I’m using DynamicBuffer with extension and internal capacity set as zero to not be stored in the chunk. The same for localization (for keys, the final text is stored in another format).
I’m not trying to be an a**hat here and saying that just because I didn’t need it so it should not exists but just trying to understand your case.

[ ]'s

5

I did list above the cases where it can be used. Since it’s opt-in, and the cases are common uses, there’s no point in everyone rolling their own. It should exist, be opt-in like I said earlier, and whoever uses it, will understand the drawbacks.

6

EntityManger.SetName(entity, "My Name"); is for editor use only, it’s for debugging, not storing data and actually using said data. It’s just so you know which entity is which
Just cover it in #if UNITY_EDITOR