What's the Unity.Physics Thread?

[fickle vortex]

I searched all the threads inside the Profiler. I'm almost sure physics is the bottleneck but none of the threads contained anything about any physics related jobs. does profiler even catch unity.physics ?

the timeline is filled with these ParallelBuildJacobiansJob job, which I assume is related to physics

but summed up they only take ~10ms

most weird thing is, all Job Worker threads are mostly Idle

main thread is also mostly idle

render thread is also mostly idle

so, where are this physics' profiler samples stored?

I checked almost all of the threads there were

[torpid meteor]

can you click this ^_^'

[fickle vortex]

sure. they're just job handles waiting for job threads

[fickle vortex]

also visible in here

[torpid meteor]

hierarchy view is useless

so yeah that's mostly physics

it's generating all the job pairs then running them basically

there's like 4 different jobs

if you click the little drop down arrow on the middle right

and click show flow events

you'll see the dependency chain

[fickle vortex]

yeah, although it does sound weird that my job is mostly taking the FixedStepSimulationSystemGroup idle time

(job started by

new FloatingTowardsSystemJob {
    elapsedTime = SystemAPI.Time.ElapsedTime,
    targetArea = targetArea, // some custom readonly IComponentData 
    targetAreaTransform = targetAreaTransform // read/write LocalTransform
}.ScheduleParallel();

[fickle vortex]

hmm, you mean in this Show dropdown button?

and btw there's nothing on the 2nd row of each job

except for these very tiny mallocs

created a thread for it over at forums
https://forum.unity.com/threads/where-is-unity-physics-sample-data-inside-the-profiler.1450834/

[torpid meteor]

no

on the far right of screen somewhere, near top

there is a dropdown

with some options

(dont have unity open so cant send a picture)

but yeah you're looking right at the physic jobs

[fickle vortex]

ah found it

interesting. my job takes ~20ms to just boot up

the job itself takes ~0.2ms to execute

what's going on...

since I really doubt myself at this point, this is the whole system+job codes.
I don't expect you or anyone else to read through it, but I'm just sending it for the sake of it being here just in case

[UpdateInGroup(typeof(FixedStepSimulationSystemGroup))]
public partial struct FloatingTowardsSystem : ISystem {
    
    [BurstCompile] public void OnCreate(ref SystemState state) => 
        state.RequireForUpdate<FloatTargetAreaTag>();

    [BurstCompile] public void OnUpdate(ref SystemState state) {
        var tagEntity = SystemAPI.GetSingletonEntity<FloatTargetAreaTag>();
        var targetArea = SystemAPI.GetComponent<AreaComponentData>( tagEntity );
        var targetAreaTransform = SystemAPI.GetComponent<LocalTransform>( tagEntity );
        
        // scheduling the job to execute in parallel (multiple threads)
        new FloatingTowardsSystemJob {
            elapsedTime = SystemAPI.Time.ElapsedTime,
            targetArea = targetArea,
            targetAreaTransform = targetAreaTransform
        }.ScheduleParallel();
    }
}

[BurstCompile] public partial struct FloatingTowardsSystemJob : IJobEntity {
    
    [ReadOnly] public AreaComponentData targetArea;
    public LocalTransform targetAreaTransform;
    public double elapsedTime;
    
    // defining our query parameters here as 'ref' or 'in'
    [BurstCompile] void Execute(
        ref FloatTowardsComponentData floatTowards, ref PhysicsVelocity physicsVelocity,
        in PhysicsMass physicsMass, ref LocalTransform transform) 
    {
        // new random point
        if (elapsedTime > floatTowards.nextReTargetTime) {
            floatTowards.nextReTargetTime = (float)(elapsedTime + floatTowards.reTargetRate);
            var point = floatTowards.random.NextFloat3( -targetArea.area / 2f, targetArea.area / 2f );
            floatTowards.targetPoint = targetAreaTransform.TransformPoint( point );
        }

        // move towards point
        var direction = math.normalize( floatTowards.targetPoint - transform.Position );
        var moveImpulse = direction * floatTowards.speed;
        physicsVelocity.ApplyLinearImpulse( physicsMass, transform.Scale, moveImpulse );
    }
}

but yeah don't mind the codes. I'm pretty sure it's the physics

i mean there are ~10 thausand spheres getting a new impulse force every fixed update

I just wanted to somehow confirm this with the profiler

[torpid meteor]

your job isn't taking anytime

it just looks like physics is taking a while

how many colliders in what area?

[fickle vortex]

~10k sphere colliders with rigidbodies

I'm gonna try ungrouping my system from fixedupdate

yeah my job isn't the issue at all

(screenshot of the physics system without my custom job/system inside it. results are the same as before)

i'm 90% convinced Unity.Physics doesn't have proper profiler samples yet🚶

btw this is interesting. the bottleneck is actually the CPU

(either that or the GPU profiler is inacurate)

[torpid meteor]

are close are they to each other? and type of hardare?

[fickle vortex]

yeah very close. I had sent a video of it the other day https://forum.unity.com/threads/where-is-unity-physics-sample-data-inside-the-profiler.1450834/

hardware is gtx1650. why? is it supposed to go way beyond 10k actively pushed rigidbodies?

[torpid meteor]

gpu isn't relevant it's all cpu

physics scales very well

[fickle vortex]

it's an i5 10300H

[torpid meteor]

but there is a limit how many bodies you can have in close proximity

[fickle vortex]

2.5Ghz

[torpid meteor]

it's too many potential colliders

[fickle vortex]

right

[torpid meteor]

like spread thsoe 10k spheres over say, 1km^2

[fickle vortex]

I'll try that

yup. as expected, better results. 3x more

bottleneck is clearly physics here

[slender dagger]

This is not actually the dependency chain, but just which job ran after the next such that you can see the flow of jobs (arrow pointing right) from starting one job (arrow down) until someone waits on it explicitly (arrow up).

There is not physics thread, physics submits multiple different jobs for each physics fixed update, and since they are bursted the jobs are coloured green. (this seems like a UI malfunction to me since it loses context on which domain submitted the job, something we should improve). Your job is dependent on something that physics jobs are writing to, so you wait that work is completed.

As tertle mentions you have a lot of physics work going on with 10K spheres tightly packed, so that will push out when your job runs.

[fickle vortex]

Thanks!

[rancid mango]

@fickle vortex : in case it helps, I just answered your question on the Unity Forum by referring to answers I have provided in another thread which is very similar to yours.
See here: https://forum.unity.com/threads/where-is-unity-physics-sample-data-inside-the-profiler.1450834/#post-9106741