Sunday afternoon

(TODO: talk about trying to get matrix into the job, `GetComponentDataFromEntity()` didn't work, trying to access via `EntityManager` within the job, pass in the Translation, etc to construct. Nope.)

Perhaps I should use my current job as part of a chain?  So it passes out a list of those that need sticking?  Then create a new job that requires this one and creates the joints?  (UPDATE: I come back to this idea later in the post.)

Aside: Oh, just realised I could probably get those data (rot&trans) from the physics world!

Aside: Just came across a thread suggesting a different way of doing physics event handling.  Think maybe they've missed the way I found in that previous thread so may link it and see if I've missed something about their needs.

Need to know whether there's already a joint connecting A & B before creating a new one.  Can't immediately see how to tell whether there's a Joint already connecting A & B.  Joint is an `Entity` with `ComponentData` that indicates its connections so it's not on A or B.  I won't be able to index into it.  Could I record the Joint's `Entity` in the `StickCause`?  Maybe.  Maybe easier for now to say a `StickCause` is one-use, i.e. remove it after it's stuck once.

Did that but still getting complaints when there's already a joint.  So need to query or get all joints in the scene?  Worse than that -- I'll need to check both the physics world *and* previous work in this job (since we may have requested a joint be created).  I should explain "requested" or maybe better "scheduled" since I'm using `EntityCommandBuffer.AddComponent()` which does the adding once you've finished.  Maybe better doing this as a separate job.

When I tried compiling my existing code with `[BurstCompile]` it complained that I couldn't do a whole slew of stuff in Burst.  Turns out joint creation is the problem.  So that separate job idea is now a must.

Rearchitected slightly to create struct that holds all the parameters for joint creation and made my previous `ICollisionEventsJob` enqueue its requests into a `NativeQueue<JointCreationData>.Concurrent`.  Now compiles with Burst!

[BurstCompile]
private struct JointCreationData {
  [ReadOnly] public Entity a, b;
  [ReadOnly] public float3 posOnA, posOnB;
}

Next I created a `JointCreationJob` that I'll run serially (not concurrent) so I can check existing joints.  I don't anticipate this will be bazillions of hits so should be fine.  It processes the earlier `NativeQueue<JointCreationData>` (no longer as a `Concurrent` so we can get the data out).  To start with it simply does what used to be done in the `ICollisionEventsJob` (that Burst complained about).  That's fine but retains the same problem of trying to create joints on things that already have joints.

private struct JointCreationJob : IJob {
  // no longer Concurrent. Not ReadOnly since Dequeue() used
  public NativeQueue<jointcreationdata> queueToAddJoints;
  public EntityCommandBuffer entityCommandBuffer;
  public void Execute() {
    var count = queueToAddJoints.Count;
    for (int i = 0; i < count; i++) {
      var jointCreationData = queueToAddJoints.Dequeue();
      // TODO: Check whether already joint present and use SetComponent()
      // Will need to check both the physics world *and* previous work in this job (since we may have requested a joint be created)
      var jointBlobData = JointData.CreateBallAndSocket(jointCreationData.posOnA, jointCreationData.posOnB);
      entityCommandBuffer.AddComponent(jointCreationData.a, new PhysicsJoint
      {
        JointData = jointBlobData,
        EntityA = jointCreationData.a,
        EntityB = jointCreationData.b,
        EnableCollision = 1 // maybe?
      });
      // For now remove the markers so they don't create any more
      entityCommandBuffer.RemoveComponent<stickcause>(jointCreationData.a);
      entityCommandBuffer.RemoveComponent<stickcause>(jointCreationData.b);
    }
  }
}

I have a little time Monday night so I'll try to do a bit more then but this project is nowhere near a game entry so guess it'll continue as an exercise.  I'll probably publish some code when it's a bit tidier for others ... entertainment :)

<-PREV | NEXT->