How the TransformAccess actually transform game objects from jobs?

1. In IJobParallelForTransform is the change being queued up in parallel but the real change in position happen in the main thread later like how entity command buffer works? Or can the worker thread work together to change the transform for real?

That is, is it wise to make a job which its only task is to transform given that all the required float3/quaternion required are already calculated (no more benefit to gain from parallel calculation), the only thing left is to set local position/rotation etc. To do this I make NativeArray of all float3/quaternion that match the length of TransformAccessArray or send a ComponentDataArray of matching length to the job.

Or is it better to just loop set them in the main thread. If the set is really queued up to be done in the main thread then it means doing this kind of job is strictly slower than just linearly loop them right away.

2. Any way that I can get just `TransformAccess` to send to a normal `IJob`? For example, I want to have a job that calculate things then set 5 different transforms gathered from differenct places in the same job.

Currently I have to make them into TransformAccessArray, send to parallel job to get TransformAccess in the Execute, then have to switch case on the `i` index to determine which is which and change the logic accordingly. Feel like a hack and there should be a better way.

3. If I have to rotate 4 groups of 10 game objects which each group will end up with the same rotation. I can either :

3.1. Parent game objects into 4 group with each containing 10 children then run IJobParallelForTransform on 4 Transform of root game object so than the rotation get automatically applied to all children by inheritance
3.2. Or just run IJobParallelForTransform on 40 separated Transforms. Use modulo on the Execute index to determine which group each one belongs to.

I want to know if is there any chance that IJobParallelForTransform can do better job with worker thread transforming 10 + 10 + 10 + 10 transforms in parallel (My Android phone has 4 worker threads so they should each get 10 works to do) vs. letting the game object inheritance system work out the children's rotation? (Each root would be similar in terms of unit of work to the worker thread way + help of game object transform parenting which should be happening in the main thread)

 

I know this was posted a while ago, but did you ever find the answer to this question?

I'm currently workin on something that could be a performance hog if done poorly, and knowing how the TransformAccess is handled could save me a mayor headache down the line.

 

This does give me some idea, but just to get a clear picture.

You're saying that the TransformAccess writes to the component directly, but does it do this "immediately" and lock access for other accessors (by means of semaphore, spinlock or other locking mechanism).

Or is write access actually witheld and done synchonously back on the main thread?