Weird bounce

[triton]

Damn its so ugly, any way to reduce bounce behaviors? Also the way units push each others looks dumb, no? Any way to make it looks more realistic?

[[Fx]Doo]

This seems to be caused by the fact that units are simply pushed away, displaced, without any change to their orientation nor velocities.
The same happens with ie gunship-like air transports colliding with cliffs. They are moved away by unit-ground "collision", while keeping their speed in the XZ plane. Without altering their speed, they are likely to collide again.

Also, i think it should be said that it's not only a matter of being realistic or beautiful:
- Air transports instantaneously "climbing" cliffs without any regards to their vertical speed (causing the need for specific gadgets to avoid instantaneous drops on cliffs)
- Construction ground units endlessly blocking each other when given a build order: The ones nearest to the build location will attempt to build but by the time they are able to start building, they have been pushed inside the build location and are now trying to move away, while all the others are preventing them to move away by attempting to reach target location.
- Unpredictable behaviours of ships around coasts or islands, when the slope is light (because we need them to be passable by amphibious units or hovers!) which can allow to dodge some projectiles in the weirdest ways.
- Some units getting stucked INSIDE buildings (yes, literally inside) after moving towards then getting pushed away then moving towards again, ending up inside a building and being very difficult to move out of it.

I tried echoing velocity of different units that were pushed either by ground or other units, these velocities never matched their displacement in the last frames. Probably, altering velocity rather than simply displacing unit would help?

[triton]

just to clarify, I used engine 104.0.1-531 + formation move in straight line.

[Silentwings]

Any way to make it looks more realistic?

In the spirit of my previous comments, ships that did crash into each other could suffer an immediate hull-integrity failure and embark upon a swift departure towards the sea bed.

[triton]

More realistic movement behavior? Its up to modders to decide if ships get damaged or not, but for units dancing, nothing modders can do right?

Also look how ships move in diagonal, its so weird. No need to defend engine devs, we fucking love this game dude. We just want MORE :)

[MasterBel2]

No need to defend engine devs, we fucking love this game dude. We just want MORE :)

To paraphrase:
Dear Engine Devs, your mistake was making an engine so good we expect it to be perfect. We wouldn't go anywhere else because anything else is trash but, you see, our expectations have been set too high.

To paraphrase again:
It's not you, Dear Engine Devs, it's us.

[gajop]

I think the solution is to limit the maximum speed achievable when being pushed, to something like max_unit_speed * [1, 1.5]
Could use engine support there

[triton]

will be tried

[raaar]

you've likely tried to use line formation on a far-away destination. The engine should do some sort of check and have the units follow parallel paths instead of reusing the same path which forces them to converge and bump into each other.

You may also increase the footprints on the movedefs to make them spread out more.

[triton]

What is avoidMobilesOnPath supposed to do?

It would be nice to make units considering units that are not moving as buildings?

Units seems to totally ignore others units when choosing their path, I tryed with and without allowRawMovement.

Also lot of units who can't reach their destination keep moving perpetually while colliding with other units. Maybe they could stop trying to reach an impossible destination after some time?




I am trying pushresistant = true, but its not possible to use with the issue you can see

[[Fx]Doo]

@raaar i tried changing footprins in the movedefs:
It only makes the collision happen "further" but the issue remains. That is, units get pushed in the same weird ways, with the same issues that i've spoken of in my earlier post, but this time with no physical collision. They do not "touch" each other.

@gajop I tried similar things like a x% slow upon unit-unit collisions.
Units that are being pushed don't have a speed that corresponds their displacement. What can be done to prevent that is to check position on each frame, calculate the effective speed, and compare with max vel ==> Not really doable + if i cannot even change the speed at which it is pushed it's quite meaningless.
I but i still tried applying a slow on the units that are colliding (SetWatchUnit and the collision callin).
I tried checking for relative positions of the unit so that the slow only involved the unit that is "pushing" (meaning the other one getting pushed isn't slowed, but is pushed "less" because the one pushing is slowed). It ended up being quite a workload...
And yet it wasn't even close to being good enough, so i had to try adding a move command to the queues to force units to move away from each other.
Some weird thing started happening but it was probably the closest i could get to something decent. Units would avoid each other but if the collision was inevitable it would still perform at a decent speed and not break the momentum entirely.
There still remained a few issues like the footprints being square while my avoidance move cmd was based on relative positions. So on buildings corners or unit corners (of their footprints) it was still sketchy.
The perf cost was huge, and that wasn't something that could have been used in anything besides small 1vs1 or 2vs2.
And honestly the improvement was visible but not critical so i gave up on it.

Alternatively, as trit has been showing, we tried to make units pushresistants just for the sake of trying.
The units don't even try to avoid each other. I think i understood that pathing only attempts to avoid immobile units, not the mobile ones. But in this case it doesnt even try to avoid immobile units... So disabling pushing (which already sounds like a pretty bad idea to me) is now out of the question because it will create even more "infinite bounce" situations.

[Silentwings]

What is avoidMobilesOnPath supposed to do?

Search wiki -> https://springrts.com/wiki/Movedefs.lua

(Note that, it defaults to true, but unless something changed recently BA overrides the engine native "ctrl" move orders via customformations and perhaps is failing to make use of this functionality as a result - I am unsure.)

It would be nice to make units considering units that are not moving as buildings?

I think this will not be computationally feasible. Also, of limited value, because units that are currently not moving have a tendency to start moving soon after.

Also lot of units who can't reach their destination keep moving perpetually while colliding with other units. Maybe they could stop trying to reach an impossible destination after some time?

Create a short demo of it -> mantis. (Ideally, without giving orders to units that are impossible to carry out.)

[triton]

dude wiki is not very clear, and ofc I read doc on wiki before wasting your precious time.

bool avoidMobilesOnPath  default: true 

Do the units attempt to avoid other mobile units when pathing?

Pro: groups moving without a ctrl-order clump much less
Contra: groups moving with a ctrl-order are less organized

mobile units = units than are moving or units that CAN move.
Pro and Contra : is it only usefull for ctrl-order?

Anyway I might have an idea, I'll keep searching.

Also I think that my gif is very clear that the units are moving stupidly for infinite amount of time while some units block them, not sure how I could make a more clear video.

[triton]

My last nub idea was to try to use this :

Heat Tags

These tags are used in unit avoidance.

bool heatMapping  default: false 

This enables/disables generation and usage of path heats.

float heatMod  default: 0.0042 

The pathfinder cost modifier that is multiplied by the heat of the current square.

int heatProduced  default: 30 

How much heat to place on a square if a path goes through it. heat set = max(currentSquareHeat, heatProduced).

I had some decent result, but in the end I am not sure about this. Sometimes I have units avoiding big groups of units, and sometimes they get stuck stupidly, also I tried tons of different value, but I dont know. Anymore with good experience on this can help me?

Is it possible to have answers from people who work on engine?

[Silentwings]

Re avoidMobilesOnPath:

mobile units = units than are moving or units that CAN move.

can

Pro and Contra : is it only usefull for ctrl-order?

Turns out it affects all path calcs equally:
https://github.com/spring/spring/blob/e ... .cpp#L1173
https://github.com/spring/spring/blob/d ... r.cpp#L399

Also that first link gets you right within the PF code for 'dynamic' obstacle avoidance, so if you find you're done with holding out for a hero you could have a look around

[[Fx]Doo]

What you call "avoidance", is that the green arrow in debugpath mode? The ones that appear when a unit gets close to another one and seems to create a turn in the opposite direction to avoid it? Kinda make sense but I still want to make sure.

// do not avoid statics (it interferes too much with PFS)
if (avoideeMD == nullptr)
continue;

I take it this means units do not avoid buildings or features because it interferes with pathfinder. What if the pathfinder is already failing to find a path that doesn't go through a building? I recall you explaining that if a building was created after the move command was issued it is possible that it will not be taken into account during the movement. But there have been other cases that i've seen ships fail to path around a building and try to go through.
In these cases that aren't that rare, wouldn't it be wise to have that avoidance take action, so that the unit is turned in a manner that avoids a collision as much as possible ? What kind of "interferences" are preventing us from using this for buildings aswell?

Secondly:
// if MAX_AVOIDEE_COSINE is too small, then this condition can be true
// one frame and false the next (after avoider has turned) causing the
// avoidance vector to oscillate --> units with turnInPlace = true will
// slow to a crawl as a result

Ok that's what happened 99% of the time to vehicles. Back when they weren't turning in place but had a turninplacespeedlimit, they WERE slowed down to a crawl. Right now, with turninplace and a properly defined turninplaceanglelimit, they ignore these kind of "small turns spams" and keep their speed.
This has not much to do with current presented issue, but just felt like it was worth mentionning our experience with this...

This part:
// now we do the obstacle avoidance proper
// avoider always uses its never-rotated MoveDef footprint
// note: should increase radius for smaller turnAccel values
const float avoidanceRadius = std::max(currentSpeed, 1.0f) * (avoider->radius * 2.0f);
const float avoiderRadius = avoiderMD->CalcFootPrintRadius(1.0f);

I take it this is the turnRadius of the unit, kinda represents the minimal space to perform a turn right? Thing is turninplace units theoretically have "0" turnRadius. At least that should be the case, since they can stop and turn in place.
Most of our issues happened with ships, some others with vehicles, these are all units with low turnrates BUT turninplace. Which means they should be able to stop and turn, or slow down and turn, or whatever. The way engine handles it, it's always aiming for full speed even if it means crashing into allied units or buildings.
Just a guess, but what if instead of calculating the avoidanceRadius depending on speed + unit's turn radius, we did set the speed according to the unit's turnRate and the current possible radii. Say the avoidance will work as long as the radius is under x, then slow down the unit so that currentSpeed * (avoider->radius * 2.0f) < x ? For units that don't have turninplace, since they cannot slowdown too much maybe that'd be harder to set, but for turn in place, having the unit slowdown when it is about to hit a unit (or a building aswell, that would be great) so that it has time and space to safely turn and avoid seems acceptable to me.
This makes me realise how much this part is silly. Why do units only have those 2 (3?) possible speeds: 0 or maxvelocity (or turninplacespeedlimit mb?). They could be able to adapt their speed to the path they're taking and to the needs for a precision move or a larger, broader movement.
This is the same with turnRate, it's always either the full turnrate or no turnrate... I guess there is a reason it is like this, can it be exposed somewhere, i am actually interested in discovering it.

Last: avoidanceVec += (avoidanceDir * avoidanceResponse * avoidanceFallOff * avoideeMassScale);

Does that mean that the higher the avoidee's mass (and lower the avoider's) the more marked is the avoidance ?
Doesn't that sound weird though? Maybe that heavy unit is a kbot that can easily turn while the least heavy one is a vehicle at full speed that will not be able to turn... Shouldn't that "avoideeMassScale" be replaced or ponderated by a ratio of both units' turnradius?
If any of those two is supposed to turn, that would be the one with the highest turnrate, not necessarily the least heavy?

Then, more about units pushing each other, it's not really mentionned here, but i guess this happens when the avoidance has failed, and all that is left is to just "move" the unit according to that avoidance vector? Can the unit's velocity and direction be altered, rather than just its position? We got the avoidance vector which is pointing towards the pushed unit, and the pushed unit's direction. Can't we add the avoidance vector's projection over the pushedunit's direction vector to the pushed unit's speed? Basically make it accelerate either forward or backward to clear path but not be pushed from the side? (only move along unit's Z-axis, rather than on its X and Z axis) I think a case where the two would be perfectly orthogonal is unlikely ?

[Silentwings]

I'm afraid you're asking more about that code than I really know - I suggest you compile the engine for yourself and add a few debug prints to test your theories.

Also, this is why short demos are better than gifs/videos/screenshots/youtube/facebook/skytv; with a demo you can actually run it for yourself and find out exactly what the code was doing when user X believed smth was wrong, and then you can test the same demo against a fix. With the skytv approach all you can do is guess.

What you call "avoidance"

is from the name of the function. Idk what draws what in debug mode, I guess you should check https://github.com/spring/spring/blob/e ... .cpp#L1232, which afaics isn't going to draw any green arrows.

fail to path around a building ... wouldn't it be wise to have that avoidance take action

Aside from whatever interference it causes with the PFS - no idea of the details - I suspect that your suggestion mostly wouldn't help: I guess only the PFS has the intelligence to actually coordinate walking around obstacles (as opposed to just trying not to crash into whatever oncoming obstacle is currently nearest).

Ok that's what happened 99% of the time to vehicles

I would test this before being confident, its highly unlikely that there is only one possible source of repeating behaviour around here.

adapt their speed to the path they're taking and to the needs for a precision move or a larger, broader movement.

Sounds like a nightmare to me, so much guessing of "what is wanted" and many games/units/devs wanting different things.

...mass...

Idk.

can ... be altered

I guess the only way to find out if things work, in this area, is testing them. It's had quite a bit of attention in the past so I wouldn't expect many easy wins. There is certainly enormous potential for making collision handling worse, and once it was much much worse. Imo it works pretty well unless you do wtf stuff like disabling all overlap/pushing. Also, https://github.com/spring/spring/commit ... 6dcfa38fce

[[Fx]Doo]

Tested something lately (but sadly erased the change like a newbie).
Since i could inject some "avoidance"-like code into the common vehicle script that we have, written in LUS, i gave it a quick try.
Goal was to "add" slows to the already existing avoidance script.

How it was done was by slowing down veh by a factor comprised of:
Set "maxWantedSpeed" = max((distance/defaultTurnRadius) + (DirVehVector dot (DirVehtoNearestVector), 1.0) * uDef.speed

Seemed to give a not so bad result. DefaultTurnRadius is turnRadius at uDef.speed and uDef.turnRate + unit's radius and nearestunit's radius

I seen there was recently a "Triton" dev branch, you think we might give this an implementation in engine for more tests ?
I'm really not knowledgeable on engine compiling or with messing with the different collision and avoidance scripts.
Ideally i would like to give it a shot at some point, mostly for the purposes of experimenting and see wht does what exactly, but that's a little early for that :/

[Ares]

dev tips with papa Bluestone