[Request] ToBufferArray

Hi,

I've just switched to latest entities package and tried to update some of my remaining [Inject] to the new way.
So I should have 2 options: either go the long way and use Chunks or for a bit less lines to write I could create a ComponentGroup and then use ToComponentArray, ToEntityArray and ToComponentDataArray.

But it seems that there isn't any way to get BufferArray (BufferAccessor would be more accurate I think from the Chunk what I used with chunks) from component group since GetBufferArray was deprecated.

Any plan to make that available ?

Thanks!

 

From what I see, unless I go with chunks, you can't access DynamicBuffers from a ComponentGroup (now called EntityQuery).
That's the use case I'm talking about:
- On main thread
- Without chunks
- Access buffers

If it's not something that will be added, then I will just make mine (a job going through a query and fetching all buffers matching the query and putting them in a BufferAccessor).

It feels like the API deprecation push us to use chunks or ForEach but in the current state of ECS where we still have some hybrid things, having ToComponentArray, ToEntityArray, ToComponentDataArray and the missing ToBufferAccessor is something I feel like I can't go without.

 

Same here, I really liked the simplicity of the previous approach, but then again after converting, it doesn't seem like the IChunk approach isn't any more complex than using IJob. It's just a bit uglier.

Anyway, I was porting my code to IChunk recently and thought maybe the following snippet could be useful for someone in the future:

Code (CSharp):

1. // Old
2. public struct IterateBufferTypeJob: IJob {
3.            [DeallocateOnJobCompletion, ReadOnly] public NativeArray<MyComponentData> test1;
4.            public BufferArray<MyBufferElementData> test2;
5.  
6.            public int Length;
7.  
8.            public void Execute () {
9.                for (int i = 0; i != Length; i++) {
10.                     //Do stuff
11.                 }
12.            }
13. }
14.  
15. // New
16. public struct IterateBufferTypeJob: IJobChunk {
17.             [ReadOnly] public ArchetypeChunkComponentType<MyComponentData> test1Type;
18.             public ArchetypeChunkBufferType<MyBufferElementData> test2Type;
19.  
20.             public void Execute (ArchetypeChunk chunk, int chunkIndex, int entityOffset)
21.             {
22.                 var test1 = chunk.GetNativeArray(test1Type);
23.                 var test2 = chunk.GetBufferAccessor(test2Type);
24.                 for (int i = 0; i < chunk.Count; i++) {
25.                      //Do stuff
26.                 }
27.            }
28. }
29.  

 

Speaking about ForEach vs manual iteration, why is ForEach not supported in a JobComponentSystem if it's more performant?

 

Looking at where we access entities on the main thread, we could probably get rid of all uses of ToComponentDataArray except for IJobParallelForTransform, where you guys even still use it.

 

Oh I misunderstood that you are also working on a ToBufferAccessor but also what you meant by using ForEach since I was thinking with the context of EntityQuery and it wasn't making sense to me, now it does.

Thanks, I think I will switch to a ForEach for that part, I'm still a bit flexible for this specific issue.

Well let's say you are a monster like me and you have 10 components on the same entity with 2 hybrid, 3 buffers and 5 componentdata. ForEach doesn't work in that case so having a manual way to handle things is useful. You could say that my issue is having too many components on the same entity but I could argue that it's context-specific and that in some case you need to have something like this to have some perfs.

 

I'm not really in favor of second guessing use cases myself. But I'm hard pressed to think of use cases that could not be eliminated with a better design. Hybrid I think counts here, that's a choice you made. Now is it a good idea to force developers into a paradigm that isn't really even stable or supported well yet? Maybe, I mean now is the time when they are setting their architecture for the next decade, so I can see the argument for not supporting flows that in the future would be considered not the best practice.

We have a few of these ourselves, ForEach right now would make life better on a practical level at this point in time. But if they chose not to support it I would understand, until I see a use case where it's not really a choice.

 

it took me a while to figure out i needed DynamicBuffer<MyBufferElement> with Entities.ForEach (actually, i didn't figure it out, but i thankfully found this post). as i'm generally a bit slow, would it be possible to simplify this or make it more clear in the error / overloads what's going on?

 

What the situation on this? I think getting buffers from the query is important, since right now I'm not sure how else you can create editor defined queries that are assembled at runtime.

If Entities.ForEach could consume a query that would also help things.

Edit. I guess WithEntityQueryOptions is worth a shot.