Feedback we need a struct only sharedComponent concept

SharedComponents are a pain because they can contain objects, but it seems that lots of programmers would be very happy with a struct only SharedComponent :

- Same rules as IComponentData: struct, only blittable members, no arrays.
- Same impact on chunks as current ISharedComponentData

example :

Code (CSharp):

1. Struct PlanetData {
2. public readonly ushort Id;
3. public readonly ushort Radius;
4. public readonly int3 Position;
5.  
6. public PlanetData(ushort id, ushort radius, int3 center)
7.     {
8.         Id = id;
9.         Radius = radius;
10.         Position = center;
11.     }
12.  
13. }

 

So a little more explanation to my use cases:
I make quadtree based planets, a planet is made of a set of nodes.

- I need to process planets one by one, I m definitely not interested in other planets nodes so a sharedcomponent PlanetData would make sense for the ecs chunks.

But it's too much of a pain with the current non-struct shared data, I often need the radius and position in my jobs so for now I just made that a IComponentData and so I'm wasting memory.

- My nodes have a level. 0 for the biggest (less detailed) ones, 12 for the more detailed.
It would make sense to have a Level SharedComponent ( struct with just a byte !) so all the nodes of the same level are in the same chunks, and so that I could priorise work on the highest level of detail.

But for now, I'm just using a level11 IComponentData and level12 empty IComponentData.

 

For immutable data it seems like you could use BlobAssetReference. But for dynamic shared data things are more difficult. Can you use Entity references and store data on a separate entity? Getting it by ComponentDataFromEntity<>? But some easy API for shared data would be great.

 

You also have chunkcomponentdata, which is accessible in a job. But yes, I also feel that there might be a better way around
- SCD
- CCD
- Blob

 

Would it be possible to add a simple table overview with use cases to the manual?

For each of those:
- [Singleton] Entity with data storage (ICD / CD)
- SCD
- CCD
- Blob
- etc.

A brief summary of:
- what is allowed (i.e. ICD, CD)
- what is restricted (i.e. access in job, burst, etc.)
- what is a common use case

 

There is some value in being able to share/define data at the level of an Archetype that doesn't seem as well suited at the Entity/Chunk level. Sorting chunks of multiple archetypes based on some archetype value is an example. For now I keep track of this Archetype/Value relationship in a hash map but only because there isn't a well suited method of doing this in the current ECS API.