Moving entities with JobSystem

Unity Engine
,
1

Hi,
I am trying to use a job that sorts the entities to their right position the problem is i am using math.distance
and then if i set the value to low it wont work.
The lowest value it works at is 0.04, but this makes the entities slightly off their right position
(the entity suppose to stop when it gets to that point).
So my question is whats the better approach to this issue something more accurate.

Another problem that i am having with the same piece of code is that i pass it a time.deltatime and move speed of 5f and with time the entities movement somehow gets slower.
If anyone can check the code and tell me why that would be great :).
btw its a 2d game.

    [BurstCompile]
    struct MyCardMoveJob : IJobForEachWithEntity<Card, Translation, MyCard>
    {
        public float dealtaTime;
        public float movSpeed;

        public void Execute(Entity entity, int index, ref Card card, [ReadOnly] ref Translation translation,[ReadOnly] ref MyCard myCard)
        {
            float3 newPos = new float3(card.moveTo.x, card.moveTo.y, translation.Value.z);

            if (!card.hasPosition && math.distance(translation.Value, newPos) > 0.04f)
            {
                float3 moveDir = math.normalize(card.moveTo - translation.Value);
                translation.Value += moveDir * movSpeed * dealtaTime;
                card.matrix = Matrix4x4.TRS(translation.Value, Quaternion.identity, new Vector3(2f, 2f, 2f));
            }
            else
            {
                card.matrix = Matrix4x4.TRS(translation.Value, Quaternion.identity, new Vector3(2f, 2f, 2f));
                card.OwnerID = 0;
                card.hasPosition = true;
                card.entity = entity;
            }
        }
    }
2

Is line 13 supposed to be float3 moveDir = math.normalize(newPos - translation.Value)?

3

Yes,
i have changed it to that but that doesn’t relate to the calculation issue with math.distance.
Do you happen to know a better approach to move the entity to specific position?

4

2 parts.

  1. when comparing floats to see if they’re equal’ish you have mathf.approximately(valueA, valueB). You would use that to tell if you distance is 0’ish instead of having to use > some arbitrary number. Unfortunately mathf.approximately doesn’t work in burst jobs and i’m not aware of the burst compatible equivalent is (or if there is one),

  2. whenever you make a movement you’re moving by the units full movement distance for that frame, regardless of whether it actually needs to move that far to reach the target. What happens when the distance remaining to travel is less than the distance the unit can move in a frame … it overshoots the target position. Then next frame it has to move in the opposite direction (and probably overshoots again). a unit can get stuck in a pattern of wobbling around a target point, always being slightly off it by up to 1 frames worth of movement distance.

for example with a movement speed of 5 * time.delta time (assuming 60fps) a unit will move 0.083 units per frame. Since your check is distance > 0.04f that means a unit would have to move over 0.08 for it to even be possible to overshoot and move from >0.04f on one side to > 0.04f on the other side. As soon as you lower that >0.04f range however the odds of it happening starts increasing significantly. This is why 0.04f is your lowest value that seems to work.

You should calculate how far the unit can move that frame and then do math.min(distanceToTarget, moveDistance). That way your unit will never overshoot the target and will land right on the target.

(Ideally you’d also replace that >0.04f check with mathf.approximately but like i said it doesn’t work in burst and i don’t know if the new math library has a replacement for it).

1 Like
5

as to why you’re getting slowing.

Are these 2 things (the unit and the target) at the same Z position?
You’re creating newPos using the x,y of the target and the z of the unit. I assume it’s to cancel out any difference in z position and calculate a distance as if they were at the same z position.

Except then you don’t use it for movement as well. For movement you use the actual position of the target (including its z). So if the target is on a different Z position then the angle of movement will not be flat on your 2d plane. It will be angled toward/away from the camera a bit. The movement is the same length but from the perspective of an orthographic camera it appears shorter because some of the movement is occurring on the Z axis which is not visible to the camera. The slowing effect would be more pronounced the closer together the 2 units are on the x/y axis and the greater the difference in z position.

but I’m really tired and not concentrating well, so i may just be talking nonsense. I’ll see if this rambling still makes sense tomorrow :wink:

6

I understood what you said about why it happens but didn’t get how to fix it.
my move distance is speed * deltatime which is a float and distance to target is float3 so how do i do math.min
with these values.

About the second part
haven’t tested it yet but it seems like you are right, because the entities that i am adding are with lower z values
and that is probably why it takes them longer to get to the right position.

7

subtracting a position float3 from another position float3 returns a float3 representing the difference between them. literally just x = x1-x2, y = y1-y2, z = z1-z2. the result float3 is a vector that represents both direction and magnitude (length). the length is your distance.

In your code in your post you’re using math.distance which does this internally for you and should be returning a float.
alternatively you can subtract the 2 positions yourself and use math.length on the resulting float3 to get its length.

i.e

var moveDistance = movSpeed * dealtaTime;
var distanceToTarget = math.distance(translation.Value, newPos);
var finalMoveDistance = math.min(moveDistance, distanceToTarget);
8

I got it now,
Thanks man its more accurate now it’s not exactly on the spot but much better :slight_smile:
(probably just because its a float)