Dark Clan Forum

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
Pages: [1]   Go Down
Print
Author Topic: Issue: Camera Speed is FPS dependent  (Read 204 times)
Berserker_BG
Newbie
*
Offline Offline

Posts: 8


« on: Fri 04.08.2023 16:52:02 »

Camera Speed is FPS dependent.

If you have a RypelCam path and you play a demo with 60fps, camera moving speed will be normal. However, if you change your FPS to something higher like 144 or 300, the camera speed becomes way too fast. I've noticed camera speed fluctuating when there are frame drops in demos, the camera becomes slow when there are frame drops and then it suddenly goes fast when FPS stabilizes. Camera speed controls like "Cam.softlyslower" and "Cam.softlyquicker" also speeds up too much if FPS is higher, personally this is my biggest issue, if you record with high FPS, these camera speed controls are no longer "soft" and become way too fast to work with.


Here is a quick example to reproduce this issue:


This example video is without a timed path. You can see how the camera speed changes when I change my FPS from 30 to 300.
VegasKill
Administrator
*
Offline Offline

Posts: 3911


« Reply #1 on: Sat 05.08.2023 13:20:11 »

Camera Speed is FPS dependent.
Yes, and it is based on a timer function as well, so using slowmotion can cause the camera movement to stutter, similar to the early UT3 RCam release.
Maybe I'd need to update UT99, I just use the several years old version 451 from a backup drive, where I can't find options to limit the FPS rate in the config files either.

From the changelist to a newer UT99 version: "Fixed an issue where the game would speed up dramatically when rendering more than 200 frames per second."

If you have a RypelCam path and you play a demo with 60fps, camera moving speed will be normal.
Probably the easiest solution to the problem would be to limit the FPS rate. Do you expect a practical benefit in recording at 100+ FPS?

You could also use a timed path, where the camera speed is adjusted automatically and shouldn't have FPS related problems. Though it is not that easy to get the timing right to create a camera with constant speed with timed path.

Camera speed controls like "Cam.softlyslower" and "Cam.softlyquicker" also speeds up too much if FPS is higher, personally this is my biggest issue, if you record with high FPS, these camera speed controls are no longer "soft" and become way too fast to work with.
The values are hard coded to speed changes of +/- 20% for "Cam.softlyfaster" and +/- 1 for "Cam.faster".

Increasing the camera speed once will change the start value of "3" it to 3.6 or 4 respectively.
Very soon any speed increase will happen in way smaller steps using "Cam.faster" instead of the +20% that are added with "Cam.softlyfaster". This is maybe only relevant if you need to increase the camera speed several steps, though.
If you require a "Cam.faster" with a lower % change (or custom adjustable values), RCam needs to be recompiled.

Mess with the best, die like the rest
Berserker_BG
Newbie
*
Offline Offline

Posts: 8


« Reply #2 on: Sat 05.08.2023 22:15:59 »

The Deck example video is recorded on 436, but the behavior is the same on other patches.

I can't find options to limit the FPS rate in the config files either.

If I recall correctly, if you use default UT99 renderers, then I believe you won't be able to control or limit your FPS. Try using the updated D3D9 or OpenGL renderers for 436 (they should also work for 451). https://www.unreal4fun.net/joomla/index.php/downloads/download/14-ut-updates-unofficial/48-enhanced-d3d9-renderer-for-unreal-tournament

To change FPS in-game, you can type "preferences" in the UT console. Then go to Rendering -> Direct3D9 Support -> FrameRateLimit. if you have VSync, then your FPS limit will be most likely controlled by your GPU, try setting that off.

Probably the easiest solution to the problem would be to limit the FPS rate. Do you expect a practical benefit in recording at 100+ FPS?
Yes, I have done numerous tests and compared a lot. I have also discussed this with other people on Discord. But, to answer your question, here is why setting your game FPS higher is beneficial:

1. If you limit your game FPS to 60 and record a video at 60 FPS as well, you will see how player models and projectiles start "skipping" frames. The RypelCam Camera path is nice and smooth, while players and projectiles are warping.
Here is a video example of what this looks like, this demo is from online play on a 60 tickrate server:

Another thing to add - if players are touching or sliding on walls with 60 FPS, they will start getting stuck on walls and skip 1 or 2 frames when they collide with the walls. I figured out that if you make your Game FPS higher, these issues are gone. I can set my Game FPS to 144 or higher and record a video at 60 FPS without player stuttering issues.

2. Recording a video with higher framerate will give you better slow motion results than using slomo in Demo Manager. Using slomo with Demo Manager is easier to work with, however, sometimes the results are not really that great. There are very small micro stutters to the players and sometimes there are other nasty issues. This is of course situational to the demo you're playing, but having the alternative to record at really high FPS is a good solution to some of my problems and I use it often.

3. Editing videos with high FPS is better. This is also situational, but let's imagine this scenario - your Video Editing Project is capped at 60 FPS and you start working with videos that are recorded at 140 or 200 FPS. The benefit of this is that you can slow down a section of your recording at any time inside your editing software of choice. This is an alternative method compared to recording with slomo in Demo Manager. Sometimes you are not sure which section you would want to record with slomo, so as an alternative, you start laying down your high FPS recordings in the editing software, which will allow you to work with slow motion adjustments better, that's why I think this is a good point as well.

4. If you want to have a proper demo playback using Frame Based playback in Demo Manager, then you need to match the demo FPS with your own game FPS. This means if the demo is recorded at 240 FPS, then to properly play it back you also need to set your Game FPS to 240. Most people in 2023 play and record demos at even higher FPS, there are already 360hz Monitors on the market. You might be also wondering why I would use Frame Based playback at all instead of Time Based. Well, I have confirmed that some demos play much better in Frame Based than Time Based. If I find playback issues with Time Based, I switch to Frame Based as an alternative and I try to compare them to see if its better. Here is the same shot I showed you earlier, but this time with Frame Based Playback:

Check out how much smoother Frame Based Playback is for this specific demo. This demo was recorded at 144 FPS, so I also had match this FPS with my game to play it back properly.

You could also use a timed path, where the camera speed is adjusted automatically and shouldn't have FPS related problems. Though it is not that easy to get the timing right to create a camera with constant speed with timed path.
Yes, exactly. Getting smooth consistent speed with timed path is a challenge. I'm not sure if there is even any smooth interpolation between flags when using timed path, the camera movement feels very sudden and snappy. Timed path in general is a hassle to work with, you can use timed path once per 1 demo playback. I can't play timed path twice by going back at the beginning of demo with seekto, I am forced to play the demo again trough Demo Manager and repeat. Working with it is hard, especially when you want to make adjustments and you keep reloading the demo over and over each time you play timed path.
VegasKill
Administrator
*
Offline Offline

Posts: 3911


« Reply #3 on: Sun 06.08.2023 11:17:45 »

I see. Frame based playback automatically limits the fps to the demo tick rate and does no further time interpolation. If you use slowmotion 0.25 the demo playback changes from 120 FPS to 30 FPS and massive stutters occur.

Time based playback on the other hand does not change the FPS when using slowmotion.
Limiting the FPS rate to the demo tick rate seems to work fine at the first look: no noticeable stutters, similar to the frame based playback.
Although limiting the FPS rate in the graphics settings gives some fluctuations of +-10 FPS, while frame based playback is basically fixed 120 FPS.


Did some tests on the camera speed:
Modifying the RCam camera speed based on the current frame rate seems to give usable results. I'll give it another look and upload it later today so you can test it.

Mess with the best, die like the rest
VegasKill
Administrator
*
Offline Offline

Posts: 3911


« Reply #4 on: Sun 06.08.2023 16:39:22 »

Uploaded as RCam 1.3.1.
In the hud you can see by how much the camera speed was reduced, depending on the FPS.
Speed controls work as if the game runs @ 30FPS, so rather smaller changes compared to the previous RCam.

For some reason the camera slows down a bit more than required at increasing FPS. Very drastic frame drops could still have a somewhat noticeable effect on the camera speed...

« Last Edit: Sun 06.08.2023 16:47:23 by VegasKill »

Mess with the best, die like the rest
Berserker_BG
Newbie
*
Offline Offline

Posts: 8


« Reply #5 on: Sun 06.08.2023 18:15:00 »

Uploaded as RCam 1.3.1.

Excellent work, this fixed the biggest issues I had with RypelCam! The camera speed is now much more consistent and it does not go blazing fast when you play it back at higher FPS.

For some reason the camera slows down a bit more than required at increasing FPS. Very drastic frame drops could still have a somewhat noticeable effect on the camera speed...

Yes, I have noticed that as well. Camera speed seems to be fine if you work within the range of 30 FPS to 180 FPS. If we compare 30 FPS against 180 FPS, the camera slowdown is so small that it's basically unnoticeable. It only starts to get noticeable if you reach 250 FPS and beyond. I wouldn't say this is a big deal, it's miles better than before. I'd rather have the camera slower like this when working with really high FPS, before the camera speed used to be so fast that it finished the RypelCam path in one second.

- default keybinds for "PageUp" and "PageDown" change the command from "Cam.softlyquicker" and ""Cam.softlyslower" to the new introduced "Cam.softlyquicker2" and "Cam.softlyslower2", thus no longer causing 20% camera speed changes, but a customizable value (10% by default, configure "cam_speed_change_perc" in RypelCam.ini, default value 10.0 changes playback speed by 10%)
Great new feature and new binds, I did not notice any issues. Customizable speed works just as expected.

Overall, it's a really good update, great work!
VegasKill
Administrator
*
Offline Offline

Posts: 3911


« Reply #6 on: Sun 06.08.2023 20:30:50 »

Glad it works out for you. afrodd.gif

Controlling RCam over timers caused this problem, among others.
Increasing the timer speed stabilizes the camera speed for moderately higher frame rates. I'm not sure if that causes problems on some other place, though. So if you want to switch to the version with the faster timer, I'll just attach it here to this post.


UT99 Rcam with its dependence on udemo and UT99 specific code is just too different from the UT3 version to simply copy over all the code. Some updates made in the UT3 RCam sure would be a huge improvement in UT99 or UT2k4 as well. Just alone the unreleased code commits to the UT3 RCam... whistle

* UT99RCam1_3.1-FPS_Timer_Fix.zip (28.51 KB - downloaded 9 times.)
« Last Edit: Sun 06.08.2023 20:36:55 by VegasKill »

Mess with the best, die like the rest
Berserker_BG
Newbie
*
Offline Offline

Posts: 8


« Reply #7 on: Thu 24.08.2023 17:53:59 »

Glad it works out for you.

Thank you for your work again! I have discovered a bug with RypelCam.ini on both new versions (1.3.1 and 1.3.1 FPS_Timer_Fix). If you delete RypelCam.ini and load rypelcam in UT, you will notice RypelCam loads 20 flags which are already placed around the map, they were not placed by me. They seem to be hardcoded too and I can't get rid of them even when there is no RypelCam.ini. This makes new RypelCam paths impossible to make. Could you reproduce this?

1. Delete RypelCam.ini
2. Load RypelCam with DemoManager.
3. There are 20 placed flags around the map. Open RypelCam properties to see them, or spectate them with viewclass CamControl.

Let me know if you can reproduce this or if it's just me. The issue is not present when I use older versions like 1.3
« Last Edit: Thu 24.08.2023 17:56:43 by Berserker_BG »
VegasKill
Administrator
*
Offline Offline

Posts: 3911


« Reply #8 on: Sun 27.08.2023 09:38:57 »

Let me know if you can reproduce this or if it's just me. The issue is not present when I use older versions like 1.3
I see, I can reproduce this problem.
If RypelCam.ini is not removed before compiling, Unreal Engine 1 will write it into the compiled RypelCam and use it for default values.

You can either open RypelCam.ini and set the cam point count to 0 (value "z=0"), or wait for an updated RypelCam, that will follow soon.


Edit: released UT99 RCam 1.3.2 fixes this issue.
« Last Edit: Sun 27.08.2023 22:21:45 by VegasKill »

Mess with the best, die like the rest
Pages: [1]   Go Up
Print
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines
© 2008-2024 | design by radarfox | webmaster VegasKill