View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004924||The Dark Mod||Physics||public||23.12.2018 12:45||02.07.2022 16:22|
|Product Version||TDM 2.06|
|Target Version||TDM 2.08||Fixed in Version||TDM 2.08|
|Summary||0004924: Rope physics mad when FPS is low and uncapped|
|Description||When uncapped FPS is on (aka com_fixedTic 1), most of physics is modeled with arbitrary deltatime depending on framerate (instead of fixed 16 ms step).|
When FPS is low, rope physics becomes crazy if you try to swing on it.
Originally posted here:
|Steps To Reproduce||1. Load a mission with rope (e.g. PD3: Erasing the Trail).|
2. Find the rope (e.g. at coords 5293.07 896.25 108.25 15.2 18.4 0.0).
3. Enable "Uncapped FPS".
4. Make sure FPS gets low (e.g. use antialiasing + high-quality soft shadows).
5. Get yourself onto the rope (e.g. using noclip temporarily).
6. Try to swing on the rope and then jump from it.
7. Look back at the rope.
In my case, I am thrown out from the rope immediately when I try to swing on it. The rope is jumping around like a crazy polyline after that.
The problem happens when:
com_fixedTic 1, FPS = 30
The problem does not happen when:
com_fixedTic 0, FPS = 30
com_fixedTic 1, FPS = 60
The video showing the problem:
|Tags||No tags attached.|
|related to||0004983||closed||AIs randomly dying with uncapped and low FPS|
|related to||0004665||resolved||stgatilov||Mouse Sensitivity Tied to Framerate|
|related to||0004698||resolved||stgatilov||Timescale command doesn't work with uncapped FPS / com_fixedTic 1|
|related to||0005992||resolved||stgatilov||Experiment with game tics longer than 17 ms|
|child of||0004493||resolved||duzenko||Some physics events have changed in 2.05 due to faster fps|
Isn't com_fixedTic 0 a sufficient and complete fix for this?
If we really want to make it fluid then someone needs to dive into the rope code in search of hardcoded const's
Yes, disabling "Uncapped FPS" removes the problem completely.
So it is not critical for release, hence scheduled for 2.08.
I understand that it is not a simple problem, but I hope someone could fix it in some future =)
|If someone goes into this issue, maybe it could also be investigated why rope-swing is so clumsy.|
These crazy rope physics also affect the player when he is attached to it, btw. Try it e.g. on the training mission.
Although I have a decent rig, running the latest Debug build (rev. 7897) resulted in 20 to 30 fps. In the training mission, I just jumped on the hanging rope over the channel and was thrown around like crazy, eventually landing in the water, while awkwardly still being attached to the rope.
I'm gonna try a little hack to improve 2.07 until a proper solution is derived:
if ( idSessionLocal::com_fixedTic.GetBool() && com_timescale.GetFloat() == 1 && !physicsObj.OnRope() )
Edit: Doesn't work when applied to just game_local...
Nbohr1more, please do not hack everything to make it work.
It might happen soon that nobody will be able to understand how different modes interact with each other.
I understand that debug visualization tools are much easier to send to non-capped mode than support them properly, and they are not for ordinary player. But please do NOT toggle uncapped FPS for ordinary gameplay.
I wasn't really happy with this workaround anyway.
One more forum thread about the topic:
Basically, I have a feeling that the problem is caused by instability of ODE solver approach (which is most likely explicit Euler) on large timesteps. The suggested fix is to limit timestep of any game tic by 17 ms.
Done in svn rev 8435.
Now with com_fixedTic = 1, game tics are limited by 17 ms (com_maxTicTimestep).
When com_fixedTic = 0, then all game tics are exactly 16 ms --- as before.
In both modes, at most 10 (com_maxTicsPerFrame) tics are modelled each frame. If frame takes more than 170 ms, then game time perceptively slows down.
|23.12.2018 12:45||stgatilov||New Issue|
|23.12.2018 12:46||stgatilov||Steps to Reproduce Updated|
|23.12.2018 12:50||stgatilov||Product Version||TDM 2.07 => TDM 2.06|
|23.12.2018 12:50||stgatilov||Description Updated|
|23.12.2018 12:50||stgatilov||Target Version||=> TDM 2.08|
|23.12.2018 12:53||stgatilov||Relationship added||related to 0004493|
|23.12.2018 14:39||duzenko||Note Added: 0011070|
|23.12.2018 14:41||duzenko||Note Edited: 0011070|
|23.12.2018 14:44||stgatilov||Note Added: 0011072|
|31.12.2018 13:26||STiFU||Note Added: 0011195|
|06.01.2019 19:29||STiFU||Note Added: 0011250|
|07.01.2019 02:57||nbohr1more||Note Added: 0011251|
|07.01.2019 03:20||nbohr1more||Note Edited: 0011251|
|07.01.2019 03:48||nbohr1more||Note Edited: 0011251|
|07.01.2019 04:12||nbohr1more||Note Edited: 0011251|
|07.01.2019 04:13||nbohr1more||Note Edited: 0011251|
|07.01.2019 04:32||stgatilov||Note Added: 0011252|
|07.01.2019 04:47||nbohr1more||Note Added: 0011253|
|01.02.2019 04:50||stgatilov||Relationship added||related to 0004983|
|01.02.2019 05:40||nbohr1more||Relationship deleted||related to 0004493|
|01.02.2019 05:41||nbohr1more||Relationship added||child of 0004493|
|01.12.2019 17:25||stgatilov||Note Added: 0011885|
|05.12.2019 08:10||stgatilov||Note Added: 0011889|
|05.12.2019 08:43||stgatilov||Assigned To||=> stgatilov|
|05.12.2019 08:43||stgatilov||Status||new => resolved|
|05.12.2019 08:43||stgatilov||Resolution||open => fixed|
|05.12.2019 08:43||stgatilov||Fixed in Version||=> TDM 2.08|
|13.05.2020 04:14||nbohr1more||Relationship added||related to 0004665|
|21.07.2020 05:02||nbohr1more||Relationship added||related to 0004698|
|02.07.2022 16:22||stgatilov||Relationship added||related to 0005992|