Global constant Entity accessible in bursted code.

[Mockarutan]

I have a singleton system setup where all my global constant data in the game is inside of IComponentsData attached to a single entity. Before I’ve been grabbed them with a GetSingleton() outside of the ForEach loops. Now I thought I should try to put them as a GetComponent() inside of the ForEach loop. So I need to feed in the entity into the ForEach. Now, I can just use a GetSingletonEntity() outside of the ForEach, but then I thought maybe I can have something global and static (preferably somehow constant) variable that all jobs can reach whenever they need to grab any singleton component. After all, the entity never changes and it’s the first thing that gets created, so it’s always (0,1).

Creating an actual constant entity variable was not allowed somehow? But maybe that is a bit weird and risky though… It looks like the only thing that I’ve found that works is SharedStatic, but SharedStatic does not seem to totally make sense here?

Is there any good solution? Maybe there is some flaw in my reasoning in all this?

[tertle]

Not sure why you’d want to couple all your systems together.
Just use GetSingletonEntity. Cache the entity if you don’t want to do it every frame.

[Kmsxkuse]

One option is to create a blob asset containing all the constant readonly data then use a chunk component data to store the reference to that blob asset. In the job, just access the chunk component and use that to read from the blob asset inside bursted code.

Although that really only makes sense if the blob data is fairly large. Depending on the size of the data and the number of chunks, it may be more efficient to just copy the data to all possible chunk component datas (denormalize it), especially if it’s constant.

In either case, use the profiler to check which one is more efficient for you, if it even matters.

[Mockarutan]

@tertle

Not sure why you’d want to couple all your systems together.
Just use GetSingletonEntity. Cache the entity if you don’t want to do it every frame.

I’m not coupling any systems together. I’m just putting most of my constraint data on a single entity. No need to either have duplicate of the data with every entity that needs if, or nearly empty chunks with a single component inside. Probably not the ultimate solution but it works well enough and make sense to me.

@Kmsxkuse

One option is to create a blob asset containing all the constant readonly data then use a chunk component data to store the reference to that blob asset. In the job, just access the chunk component and use that to read from the blob asset inside bursted code.

Although that really only makes sense if the blob data is fairly large. Depending on the size of the data and the number of chunks, it may be more efficient to just copy the data to all possible chunk component datas (denormalize it), especially if it’s constant.

In either case, use the profiler to check which one is more efficient for you, if it even matters.

Yeah, I’m considering converting it to blobs. But the denormalisation, that is an interesting question to me! Should I be putting the data in every single entity so it’s more linear and more likely in the cache line? My thought is that by not having duplicate in every entity I can get more relevant data in every load instruction and thus better performance. But I have not looked enough at it to have an answer. Do you have any experience?

[tertle]

@Mockarutan

I’m not coupling any systems together. I’m just putting most of my constraint data on a single entity. No need to either have duplicate of the data with every entity that needs if, or nearly empty chunks with a single component inside. Probably not the ultimate solution but it works well enough and make sense to me.

Yeah, I’m considering converting it to blobs. But the denormalisation, that is an interesting question to me! Should I be putting the data in every single entity so it’s more linear and more likely in the cache line? My thought is that by not having duplicate in every entity I can get more relevant data in every load instruction and thus better performance. But I have not looked enough at it to have an answer. Do you have any experience?

Sorry I partially miss-read what you were trying to do.
Anyway, if I recall correctly the reason I believe you can’t put an entity in a shared static is simply that you can’t put structs in there, it only supports primitives.
Technically you could do something dirty and store it as a long in a shared static then just split it into its index/version. Not sure it’s a particularly nice idea though.

[Krajca]

The cost of getting a singleton data/entity is so low you probably shouldn’t concern yourself with it. If it’s constant by design you can cache values, but in my opinion, is not worth it. Most of my systems have “RequireSingletonForUpdate” and a bunch of GetSingleton() on the beginning on OnUpdate() and it’s working fine.

[Mockarutan]

@Krajca

The cost of getting a singleton data/entity is so low you probably shouldn’t concern yourself with it. If it’s constant by design you can cache values, but in my opinion, is not worth it. Most of my systems have “RequireSingletonForUpdate” and a bunch of GetSingleton() on the beginning on OnUpdate() and it’s working fine.

Yeah… My hunch is the same. But I was just looking over it all and though it might be something to gain from it. Event if it’s just reducing complexity or something.