beyond-all-reason / spring

A powerful free cross-platform RTS game engine
https://beyond-all-reason.github.io/spring/
Other
220 stars 102 forks source link

non-upright ground units flicker upright when colliding and driving on water slopes #615

Open springraaar opened 1 year ago

springraaar commented 1 year ago

engine : BAR105 1478 map : "Downpour 1.1" game : MF v2.02 (replay attached)

When driving through water slopes, units flicker between their upright and sloped positions sometimes.

same issue exists on 105.0, as reported here https://springrts.com/mantis/view.php?id=6434

springraaar commented 1 year ago

20230205_031441_tank_water_upright_flicker_Downpour 1_105.1.1-1478-gbc6400c BAR105.zip

^--- replay mentioned in the first post (it's an .sdfz file but github forced me to rename it to be able to upload here)

i spawned a sphere_bulk (amphibious heavy tank) and moved it around underwater on slopes to trigger the issue issue also happens even if luarules is disabled so it's an engine issue

lhog commented 1 year ago

Try unitdef's upDirSmoothing parameter I added recently. Start from something like 0.8 and go down to the comfortable level. What happens here is that non-upright unit is obliged to follow the ground normal direction, which is quite random around edges. upDirSmoothing is averaging "up" direction over time helping to reduce the flicker you see. On the downside it's always in action so on slowly changing slopes the unit's up direction will lag behind a little bit.

Let me know if it helps.

springraaar commented 1 year ago

that seems like something that'll mask the issue. But there seems to be something else, like the unit flickers between the slope normal and upright (flat normal) instead of the two slope normals

lhog commented 1 year ago

Yes it will only mask the issue. If you have better ideas, feel free to throw them in. I have one extra solution such that "walking normals" would be calculated based on coarser version of heightmap, but then it'll consume more memory and compute power. Not ideal too.

I haven't watched your replay yet, but I'm 99% certain about the cause (you're not the first one to complain).

lhog commented 1 year ago

Please let me know your testimonials from using upDirSmoothing if that's not good enough I can think of a different solution.

springraaar commented 1 year ago

the upDirSmoothing seems more relevant the higher it is, at 0.3 the effect is barely noticeable, at 0.8 it lowers the flickering/shaking to some degree, but it's still very noticeable. At 0.99 (actually 0.9499...) the issue is much less noticeable, but the unit slope lags behind the terrain too much.

EDIT: it seems clamped to 0.9499

btw, the issue seems triggered by collisions with other units or slopes that are too steep for the unit type and only happens underwater.

I'll try going with 0.9 for next MF version.

lhog commented 1 year ago

Yes, it's clamped at 0.95. Hold on though, perhaps upDirSmoothing being the temporal averaging is really not that great. I'll probably keep it as is, but do "walking normal" map, which is going to be based on normals calculated on heightmap averaging/reduction of certain order (probably gonna be a modrule).

Stay tuned.

springraaar commented 1 year ago

what i was trying to say is that it doesn't seem an issue with the normal map varying wildly, it seems to be some interaction between collisions AND being underwater (it only happens underwater).

I haven't looked at the code, but maybe units colliding with either units or slopes they can't drive through sometimes briefly lose contact with the ground and "snap" to their horizontal orientation when underwater.

lhog commented 1 year ago

Ok, I probably need to watch your replay then, been rather busy IRL lately.