Saturday afternoon Unity.Physics and DOTS samples strife (after late start)

Where I struggle with tiredness and the "preview" nature of Unity.Physics and its samples but emerge victorious and ready to get sticky!

--

Super-late (midday) start due to family stuff and a headache to boot so this might all be lost already.  Still, we have paracetamol and coffee and the possibility of a nap later so let's push on and see what we manage :)

Running that code (from last night) gives an error:

InvalidOperationException: The previously scheduled job CollisionSystem:CollisionJob reads from the NativeArray CollisionJob.PhysicsWorld.DynamicsWorld.m_MotionDatas. You must call JobHandle.Complete() on the job CollisionSystem:CollisionJob, before you can deallocate the NativeArray safely.
Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle.CheckDeallocateAndThrow (Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle handle) <0x257a8ae2730 + 0x00052> in <3bd64dd808f046b38ba2fb6667d0adc4>:0

Side note: This theme does make me wonder whether I could add "game elements" to an old serious idea I had for using springy nodes to think about stuff a bit like a mind-map.  Perhaps it could be a murder mystery mind game -- like you have to build connections between clues?  (I always think about this idea when learning new things when I find I get little pieces of information and want to write them down then connect them up later in various different ways to show different things.  Does that make sense?)

Back to it: `DynamicsWorld` has a (terribly named) `MotionDatas` which creates a `NativeSlice<MotionData>(m_MotionDatas, 0, m_NumMotions)`.  (aside: WHYYYYYY doesn't itch.io support posting devlogs in Markdown?!?!  Here's a feature request.)

A bit of "comment out sections to see" reveals it's this that's causing the problem:

if (!PhysicsVelocityData.Exists(entityA))
  EntityCommandBuffer.AddComponent(entityA, new PhysicsVelocity());

So is it reading `PhysicsVelocityData` ?

And what's an `EntityCommandBuffer` ?

Oh no, just realised I'm using an out-of-date Unity.Physics -- I have 0.0.2 and there's a 0.1.0 version!  Right, let's try updating that in case it fixes this and/or the WebGL problem.  The changelog's "Known Issues" mentions both (a )IL2CPP potential problems and (b) that it uses "rendering frame rate" atm.  Either of these could have caused the WebGL "dropping through the floor" problem of yesterday.  Oh well.

Oh great.  Lots of compile errors now.  Let's see if I can do without some (since many are in the 'samples' -- don't you love it when API gets updated without the samples and tests getting updated?  Really screams quality ... in a bloodied-face-squeezed-through-an-axed-up-doorway kind'a way.)

Oh the Hybrid Renderer is also out of date so let's throw caution to the wind and update that too.  Nope still errors.  Right, let's start hacking.  (On the bright side, it's all good familiarity work so hey, I'm still making progress on the "learning" goal even if the jam entry isn't moving closer to creation!)

Aside: Just came across Docs for preview Animation API which have a 2 bone IK sample -- spider idea

Oh the irony.  Looking for the Unity.Physics source, I find the Samples project has been updated... last night!!!  Ok then.

Not much better.  Oh well.  So `Simulation.CollisionEvents` has become `internal` and is now passed as an `EventReader` in a `CollisionEventJobData<T>` to a `ICollisionEventsJob`.   So maybe I can swap my class implementing `IJob` to being one of those?  That makes its `Execute()` take a `CollisionEvent` which seems pretty positive!  Ok now it can't be scheduled -- oh `DisplayCollisionEventsJob` uses `ScheduleImpl()` but that's `internal` ... and all of the samples that try to use `ICollisionEventsJob` have compilation errors -- hmm... due to ambiguous reference between multiple extension methods.  I want the one in `ICollisionEventJobExtensions`.  So let's make it an explicit call for all of these.  Well, mine first.  Yep, compile error fixed.  And with all the correct arguments I can swap it back to an implicit extension call.  It's now:

var collisionJobHandle = collisionJob.Schedule(m_StepPhysicsWorld.Simulation, ref m_BuildPhysicsWorld.PhysicsWorld, combineDependencies);

On running I'm told I must `Complete()` the job:

collisionJobHandle.Complete();

Aaaand it works!  I'm getting those `collisionEvent.AccumulatedImpulses` values out in the logging!

Now I find all the samples are no longer in their own assembly so let's tidy that and put my code in its own to reduce compilation time (iteration time):

{
    "name": "UnityPhysicsExamples",
    "references": [
        "Unity.Burst",
        "Unity.Entities",
        "Unity.Entities.Hybrid",
        "Unity.Physics",
        "Unity.Physics.Hybrid",
        "Unity.Mathematics",
        "Unity.Collections",
        "Unity.Rendering.Hybrid",
        "Unity.Scenes.Hybrid",
        "Unity.Transforms",
        "Unity.Transforms.Hybrid"
    ],
    "allowUnsafeCode": true
}

Next thing to try is modifying stuff when it hits.  Shall we try connecting them with joints or simply combining their physics bodies together?  One will give sticky/floppy effects (FUN! :-O ) whereas the other will give a hard feeling (the gags just aren't getting better, are they!).  Both sound like they might lead to interesting gameplay so let's investigate how to do either.  I know the docs talk about creating joints at runtime so maybe that's easiest?  (ha!)

Better.  Now to nap or not to nap, perchance to be slower for it?  Let's publish this so far and start a new one for the next section.

EDIT: I napped then BBQ'd for my family.  We made homemade bread rolls, salsa & pork burgers!  First time!  Note for future: smaller bread rolls!  I'm a fully grown adult (well, physically) and couldn't get my mouth around the burgers.  My young sons felt like they were scaling a burger mountain.  Shall we call that a ...wait for it...  berg-er ;-)
(cuz, like, my school german tells me that's german for mountain so it's funny.  Whaddya mean "if it needs explaining?!?!?" :-P )

<- PREV | NEXT ->