Implementing forces in Unit Motion (HELP WANTED)

[Atrik]

20 minutes ago, Thalatta said:

"a circular body is always struck through its centre", I guess this is some non-physical simplification

Like a simplification that doesn't account for friction? 

[Thalatta]

2 minutes ago, Atrik said:

Like a simplification that doesn't account for friction? 

I see, tangential forces would need friction to act. And I guess including that might cause a bunch of other problems, like units getting quite stuck.

[nifa]

ok, another random guess:

Maybe we could use an additional force, where an idle unit clears the path for an allied moving unit, before they are colliding, when it's blocking the way? The blocking unit would just slighty move to the side, but only if there is space available

[Atrik]

38 minutes ago, nifa said:

Maybe we could use an additional force, where an idle unit clears the path for an allied moving unit, before they are colliding, when it's blocking the way? The blocking unit would just slighty move to the side, but only if there is space available

It is kind of the case depending on how you look at it : 
We could say that units aren't actually pushed, they just look at every neighbor that look too close to them, then they move away from them.
Consuming all forces they calculated, tells them where they have to go for this turn. So it's them actually moving away..
Well since all that is a bit some abstraction of physical events probably there are as many way to phrase it as you want. 

Edit : I meant is that the pushing range is already some kind of way to communicate to units to move away. But maybe if you wanted to add one that apply only to allies but further then the normal push one, it could be a good idea for example for rams where you want them to push allies but enemy can still block the way. It's a good idea.
Edit 2: Now I have regret dropping my initial approach about a forward area in front of units used for charging, that would be maybe a few lines of codes to just make it possible to apply to allies only...

38 minutes ago, nifa said:

ok, another random guess:

I'm glad for the involvement, it shows that this is an interesting topic and that many things will sprout out of it. 

In fact, a big highlight of this project is that it will be easy, even from a mod, to plug in forces into UnitMotion.
Examples : weather, spells (attractions, repulsion)...

Edited 23 hours ago by Atrik

[guerringuerrin]

9 hours ago, Atrik said:

But I have a feeling it's doable, let's see if @guerringuerrin find a way to prove we are still far off succeeding.

I managed to block my 24 elephants again.  The gaps they tried to pass through are quite small. I’ll clarify again here that I’m deliberately trying to push things a bit. 

Spoiler

 

In particular, I’d like you to look at what happens with the group at the bottom, which has a visibly wider path than the group at the top. The first elephant goes straight through, but the second one, which is coming slightly from the side, collides with the house and turns to its left to try to go around the house. However, there is no longer enough space for it to make the 90-degree turn, so it gets stuck at the corner of the structure's hitbox + some eles probably pushing it too, and ends up blocking all the eles.

Spoiler

 

I replicated this with only a few elephants, and something similar happened. It seems that elephants need to make a 90-degree turn to go around a building, avoiding any contact between their hitbox and the corners of the structure. This can be seen in the following videos. There is clearly enough space for the elephant to pass through if it moved diagonally:

Spoiler

The obvious conclusion is that the hitboxes are too large, both unit and building (I'm asuming hitbox are the green ones). They extend well beyond the 3D model that the user sees and create these visual inconsistencies: the elephant cannot pass through a gap that appears wide enough. 

Having the structure's hitbox larger than the model may be desirable to prevent units from clipping through it and perhaps also help with visual clarity. But for organic bodies, maybe we can cheat a little with this. And I think this is also why I mentioned several times trying to "give them more overlap". But perhaps that wasn’t the right term. Maybe it’s not a matter of giving them more overlap, but rather making their hitboxes smaller. This could help elephants move through gaps that appear wide enough to the user, and it would also prevent them from pushing each other without actually touching, as can also be seen in this same video (00:10).



In this last example, we can see an elephant walking around the barracks while keeping an exaggerated distance from the structure's visible boundaries:

Spoiler

 

One final clarification:

It’s obvious that destroying the houses is the quickest way forward, and there’s no reason to expect the elephants to organize themselves perfectly and head straight for the fortress. After all, the purpose of this feature is to add more realism and make a huge creature like an elephant somewhat clumsy.

However, I think there is still room to improve the visual inconsistencies I’ve shown, where there appears to be enough space for an elephant to pass through, but it nevertheless gets blocked. I think most users will consider these visual inconsistencies a bug, and they can make the experience somewhat frustrating. That’s why I keep pointing them out as something that I think needs to be addressed.

Edited 19 hours ago by guerringuerrin

[Thalatta]

3 hours ago, guerringuerrin said:

The obvious conclusion is that the hitboxes are too large, both unit and building (I'm asuming hitbox are the green ones). They extend well beyond the 3D model that the user sees and create these visual inconsistencies: the elephant cannot pass through a gap that appears wide enough.

Reducing hitboxes might solve the issue with the wider path from your first video, but the narrow one would remain. It's like chasing the issue. I think hitbox shape might be more determinant: in tight spaces, vertices complicate rotating and straight sides give too much front for static equilibrium. Maybe elliptical shapes with increased on-center repulsion range to avoid compact tiling might be worth a try (since that seems to be the only problem about them, for now).

[nifa]

8 hours ago, Atrik said:

It is kind of the case depending on how you look at it : 
We could say that units aren't actually pushed, they just look at every neighbor that look too close to them, then they move away from them.
Consuming all forces they calculated, tells them where they have to go for this turn. So it's them actually moving away..
Well since all that is a bit some abstraction of physical events probably there are as many way to phrase it as you want. 

I think the difference would be the direction that the unit is pushed to: With the current pushing, it would move the same direction as the pusher, which means they will probably collide again.

With the "clearing the path" mechanism, the second unit would make two steps into the direction it faces/ or into a direction with free space/ or a certain angle of the pushers movement direction, so hopefully avoiding another collision. I'm especially thinking of the elephant sliding another elephant scenario from the videos above.

I don't know if this makes sense or if it's too costly but maybe one active instead of passive move could help solving the bottlenecks somehow

8 hours ago, Atrik said:

I'm glad for the involvement, it shows that this is an interesting topic and that many things will sprout out of it. 

In fact, a big highlight of this project is that it will be easy, even from a mod, to plug in forces into UnitMotion.
Examples : weather, spells (attractions, repulsion)...

Yeah, I'm a big fan

[guerringuerrin]

4 hours ago, Thalatta said:

Reducing hitboxes might solve the issue with the wider path from your first video, but the narrow one would remain. It's like chasing the issue. I think hitbox shape might be more determinant: in tight spaces, vertices complicate rotating and straight sides give too much front for static equilibrium. Maybe elliptical shapes with increased on-center repulsion range to avoid compact tiling might be worth a try (since that seems to be the only problem about them, for now).

Yes, I agree with you. Although I’m not sure elephants necessarily need to be able to move smoothly through the narrowest possible passages. There has to be a point where the elephant’s size actually matters mechanically, and in those situations, the most logical choice seems to be to destroy the house rather than try to squeeze through it.

But I think trying elliptical hitboxes is reasonable. I got the impression that implementing them would be quite complicated, but if there’s any possibility of doing it, I’d definitely give it a try.

[Thalatta]

1 hour ago, guerringuerrin said:

There has to be a point where the elephant’s size actually matters mechanically

Yes, I agree they should be very clumsy, as ships, nothing wrong about that. But what I find might be solvable is their uncooperativeness , by putting in place the measures needed for them to rotate in certain situations.

[real_tabasco_sauce]

4 hours ago, guerringuerrin said:

There has to be a point where the elephant’s size actually matters mechanically, and in those situations, the most logical choice seems to be to destroy the house rather than try to squeeze through it.

yes, but this is already the case with elephants. IMO the target should be to keep their maneuverability through buildings and other immovable obstacles as close to current as possible.

[Atrik]

14 hours ago, guerringuerrin said:

The obvious conclusion is that the hitboxes are too large, both unit and building (I'm asuming hitbox are the green ones)

 

This hitbox you used are the model's bounds but aren't accurate to see what the unit collide with.
It's my bad for not doing the obvious : adding a debug for visualizing the actual footprint used for collision.
I was debugging mostly using boats to this time because they have everything more extreme than elephants : inertia, size, and they even have drifting effects.  For them, the footprint is already accurately displayed when you select them, but now I added the debug so we can also see it for elephants. Also it made me realize that for boats it's fair to approximate their shape to a rectangle, but not so much for elephants who have different ratios, so when we spoke about corners, we highly exaggerated their extent for elephants :

Yellow is the debug footprint. You can now display it by enabling Unit motion overlay and selecting the elephants.
 

1 hour ago, real_tabasco_sauce said:

IMO the target should be to keep their maneuverability through buildings and other immovable obstacles as close to current as possible.

I'm convinced that a lone elephant pathing got better. He'll be more resilient to solving hitting a building corner for example. Lone elephant with other non-solids that used to block them it's even more obvious. 
I'm doing the tweaks I can to make herds of elephant not too terrible but they will always be less agile then normal units 
@real_tabasco_sauce do you think we could also slightly increase both their pop cost/res cost, and make them a bit more tanky? So that you get their new ability with micro but getting tones of them is still not as easy?

 

[Thalatta]

@Atrik I'm a bit confused now... collision surfaces were rounded all along? If so:

-Is that some non-elliptic oval? Doesn't it take more computational resources than for an ellipse? (since I guess more equations would be required to define that).

-What was happening with the elephant sliding against the wall then? If pushed off-center, shouldn't it have rotated?

-Can't the scheme be unified and ships be treated in the same way? Or all objects for that matter.

[Atrik]

16 minutes ago, Thalatta said:

@Atrik I'm a bit confused now... collision surfaces were rounded all along? If so:

-Is that some non-elliptic oval? Doesn't it take more computational resources than for an ellipse? (since I guess more equations would be required to define that).

The shape is a radius around a segment, a 2D capsule, which you generally picture as a rectangle but for small segments, it start being more circular.

20 minutes ago, Thalatta said:

Can't the scheme be unified and ships be treated in the same way? Or all objects for that matter.

They are, and for boats their footprint shape was displayed as it was (the champion ele had the triangle one because it's a champion). Since they are long shapes, there it looks more like a rectangle then for elephants. So I was approximating them as being all rectangle, but now that it is drawn for elephant, it's obvious that it's a bit less true for them.   Although they are still pretty close to a rectangle.

25 minutes ago, Thalatta said:

-What was happening with the elephant sliding against the wall then? If pushed off-center, shouldn't it have rotated?

For buildings, it was always was one contact point anyway, as it doesn't use the hitbox used for pushing. But the example you gave was still trickery! The wall was blocking the unit from complying to the push because of having one less degree of freedom.  

[Thalatta]

54 minutes ago, Atrik said:

The wall was blocking the unit from complying to the push because of having one less degree of freedom.  

I see, it was even more constrained than the case of me pushing that elephant in the open. It all comes down to their resistance to rotate, and how messing with that messes with other things. Seems the only solution is "taking into account the relative velocity" between them, but I guess you didn't want to complicate the code with that.