[1.9.x - 1.12.x] Camera Tools continued v1.35.0 [2024-09-07]

[Halban]

Hi Doc,

Thanks for supporting Camera Tools. I understand this version is mainly about improving Dogfight mode, but would you be willing to take some suggestions on improving Pathing mode? I'd completely understand if you'd rather spend your time working solely on Dogfight mode.

[DocNappers]

6 hours ago, HatBat said:

Hi Doc,

Thanks for supporting Camera Tools. I understand this version is mainly about improving Dogfight mode, but would you be willing to take some suggestions on improving Pathing mode? I'd completely understand if you'd rather spend your time working solely on Dogfight mode.

If you have ideas on how to improve it, I can try to implement them. I haven't really done much with the Pathing mode since I took over the mod other than fix some minor bugs in it. Most of my time is spent working on BDArmory instead.

[Halban]

Here are my suggestions in order of increasing complexity (I think), baring in mind that this is a wishlist and I understand that some of these probably aren't worth your time.

Prevent pathing/stationary from starting automatically. The current behaviour seems to be to start automatically when switching between modes. This seems inconvenient to me; I'm not sure if it's a bug or a feature.

Improved interpolation based on Kerbcam's component mode. Camera Tools has never had completely smooth interpolation between more than two keyframes, regardless of interpolation rate. Kerbcam's component mode does this really well for rotation, and the default Kerbcam position interpolation also appears to be completely smooth.

Playing paths while the game is paused. The increased frame rate when physics is paused would be immensely helpful for recording high part count scenes. The current behaviour is to freeze with an offset camera.

Support for Time Control. Expanding on the previous suggestion, playing paths (or using any mode) while using either the slow motion or pause features in Time Control would have the same benefit of increased frame rate as well as introduce the ability to film slow motion paths/stationary/dogfight shots. The current behaviour for Pathing mode is to play the path at a speed proportional to the slow motion with working rotation, but with position stuck in an offset position. Current behaviour for stationary mode is working rotation, with camera position remaining stuck in an offset position relative to the vessel.

If you do decide to implement any of these, please let me know if I could help in any way.

[DocNappers]

Yeah, I've notice the auto-enabling behaviour when switching modes too. I'll switch it to only starting that mode if camera tools is already active.

 

Looking at the code for how the camera is positioned and oriented during pathing mode, it's just doing linear interpolation between the keyframes for where the camera ought to be and how it ought to be oriented according to the path, and then doing linear interpolation between its current position and the target position and spherical linear interpolation for the orientation. Switching to using some form of splines (e.g. cubic Hermite polynomials) and directly positioning the camera instead of Lerp'ing would probably make it look nicer.

In the summary of the function you linked to it says

Quote

/// Interpolate rotation dumbly using cubic Hermite interpolation of
/// each Quaternion components. This creates odd effects.

What are these odd effects? I see there's other rotation types too, do you know how they behave?

 

In order to get smooth interpolation of the camera position and orientation between frames, all the camera updates are currently performed in the physics update step (FixedUpdate, which has a constant time-step). Without this the interpolation goes all wonky and you end up with a double image of all the vessels whenever the non-physics update time-step (TimeWarp.deltaTime) is not close to a multiple of the physics update time-step (TimeWarp.fixedDeltaTime) due to it being updated an inconsistent number of times each physics update. This is why the camera doesn't update when the game is paused (either with the escape menu or by pausing with Time Control) as pausing sets the Time.timeScale value to 0, which means no physics updates are being called and the in-game timers are frozen.

A potential approach for playing paths when the game is paused is to specifically check for this condition in the non-physics update step (Update) and call the appropriate camera update functions from there with appropriately adjusted time-step values and timers (if needed), but those new time-step values and timers would then be independent of any in-game timers, so it'd likely cause problems.

 

As for the behaviour of the various cameras when time is slowed down by Time Control, I'm not sure why that's happening, as the updates are done in the physics updates using the physics time-step. I will need to investigate further as to why it gives weird offsets. I checked with Time Control's slow-motion enabled at 100% and it still gives weird offsets in Dogfight mode, so I'll need to see exactly what Time Control is doing (other than adjusting Time.timeScale) to figure out what's going on.

[Halban]

Thanks for writing such detailed responses to my suggestions.

Quote

What are these odd effects? I see there's other rotation types too, do you know how they behave?

Compared to Slerp (the default), Component mode can sometimes cause the camera to rotate in unexpected ways (opposite angles, flipped normal) between highly disparate keyframes, such as keyframes facing towards each other. This has very rarely been a problem for me in practice. If you were to implement something similar to Component mode, linear interpolation could be kept as a fallback for people who need higher accuracy. Slerp is very similar to the linear interpolation in Camera Tools. Squad mode is erratic and was probably just added out of curiosity.

Your ideas about paused pathing seem promising to me; I don't see why using Update, and a real time delta time and clock wouldn't work if physics aren't doing anything. Though that's probably because I don't know enough about Unity and KSP.

After reading your message I checked Time Control's config and found an option called 'CameraZoomFix'. I tested with this setting disabled and paths played in slow motion with no issues. Stationary and Dogfight seem to work fine too. Now I feel an idiot for asking you to support Time Control, but it's great to find that it actually works. Pause doesn't work as the path speed is proportional to the slow motion but even 1% speed works well.

 

Edited June 30, 2021 by HatBat

[Halban]

Seems to work fine during Menu/Time Control pause by moving from FixedUpdate to Update and changing Time.Time to Time.unscaledTime. Might experiment with switching between paused/unpaused mode based on the check you mentioned, unless you've already started on it.

EDIT: It also seems to work while the game is unpaused or running in slow motion with Time Control. The path speed stays the same while moving between different slow motion rates, which is quite handy. This might mean that everything could be moved to Update permanently, unless I'm missing something?

Edited June 30, 2021 by HatBat

[DocNappers]

I haven't started on it yet, I've been busy with work and other stuff. If you've got experience with programming in C#/Unity, feel free to make pull requests.

When I first took over the mod, I did initially try switching the updates to Update instead of FixedUpdate to try to have the camera only being updated once each rendered frame, but the issue with vessels jumping back and forward giving a double image comes about because (at least for the dogfight mode) the camera position is updated based on a Lerp to the current vessel's position (plus some offsets) and due to the inconsistent number of updates between physics and rendered frames that Lerp would cause the camera position to jump to two different positions depending on whether 1 or 2 physics updates had occurred. I'm not sure if the stationary and pathing modes are affected by this as the Lerps used there aren't directly relative to a position that's being updated in FixedUpdate ( I think). It they aren't affected, then an option would be to split the update behaviour such the stationary and pathing modes update in Update and only dogfight mode updates in FixedUpdate.

Using Time.unscaledTime in pathing mode when Time.timeScale is 0 would probably be sufficient for most cases. The main issue I can see would be a bit of a jump in playback speed if the path is already playing when the game gets paused. This could be worked around though by keeping track of the last non-zero Time.timeScale and scaling Time.unscaledTime - pausedTime by this while paused (where pausedTime = Time.unscaledTime when initially paused).

[DocNappers]

I've made the following changes in the dev branch:

Quote

Bugfixes:
 - Only activate the camera when changing modes if it was already active.
 - Don't automatically start playing a path when adjusting it or creating a new one and stop it if keyframes or the path is deleted.
 - Start playing a path when it's loaded if camera tools is active.
 - Adjust ordering of stationary path updates to avoid jitter.
Improvements:
 - Automatically disable TimeControl's camera zoom fix as it breaks CameraTools when slow-mo is enabled (sorry @ntwest).
 - Switch stationary and pathing cameras to run in Update instead of FixedUpdate as they aren't sensitive to physics updates.
 - Switch pathing camera to use unscaled time so that it works while paused.

I think it'd be good to switch the pathing mode to use or have the option of using splines before releasing the next version.

[FDAUT]

omg I was just scrolling through here looking for some tips on how to use this mod and I see @HatBat !  I thought you were long gone!  Your "perspective' vid is the reason I play this game and why I'm trying to start doing cinematics, beautiful vid. Just want to say pls come back   Miss the uploads.   

[Space Scumbag]

Wow, so many improvments to the mod.

Thank you DocNappers!

[Drew Kerman]

not playing currently but will be returning eventually - does the latest version still cause the camera to "jump" up a bit when you launch a vehicle and unhook from a clamp? That always annoyed me and was something KerbCam didn't do. KerbCam also let you target other objects beside the main vessel, which also helped prevent the camera jump. If this is fixable with the way CameraTools is doing things, that would be great

[DocNappers]

I'm not really sure what "jump" you're referring to. I haven't noticed any such jumps. Which camera mode(s) did it occur with?

[OrbitalManeuvers]

19 hours ago, Drew Kerman said:

does the latest version still cause the camera to "jump"

Yes, it still does this.

6 hours ago, DocNappers said:

I'm not really sure what "jump" you're referring to.

I actually came to ask about this the other night and got distracted. Lemme show you...

Liftoff is around 11 seconds. It happens the moment the launch stand decouples. My only wild guess would have to do with the fact that the center of mass is changing at that instant.

Spoiler

 

another example:

Spoiler

 

 

Edited July 6, 2021 by OrbitalManeuvers
added 2nd video example

[DocNappers]

I believe I've found the cause of the jump. It's due to the CoM of the vessel shifting when the launch clamps are released (not related to the "Vessel Center of Mass" option). The way the stationary camera is currently compensating for the movement of the vessel doesn't take this into account. The effect was barely noticeable with the stock launch clamps, but I managed to make a large sideways jump by attaching a bunch of ore containers to one side of the launch clamps to trigger this effect.

I'm going to change the way the stationary camera maintains its position, which works better and negates this effect. However, I'm not sure of the intended difference between the various "frame of reference" modes. From what I can see of what the code's doing, these are just using different velocities in the calculation for trying to maintain the stationary camera's position, which aren't needed for the way I intend to change this to work.

[FDAUT]

On 7/2/2021 at 6:20 AM, DocNappers said:

 

I think it'd be good to switch the pathing mode to use or have the option of using splines before releasing the next version.

just hear to say after using this mod for a few days I eagerly await this

[FDAUT]

also an addition that might be good (but yes this is a problem only a few would have) is be able to change to buttons the keyboard controls are binded to. I use a small form factor keyboard so dont have a numpad so currently unable to manually zoom in without brining up the ui. This would just be a nice qol feature  

[DocNappers]

On 7/8/2021 at 4:45 AM, FDAUT said:

also an addition that might be good (but yes this is a problem only a few would have) is be able to change to buttons the keyboard controls are binded to. I use a small form factor keyboard so dont have a numpad so currently unable to manually zoom in without brining up the ui. This would just be a nice qol feature  

Good idea. I've added it for the next release.

I'm just trying to finish the various interpolation modes for position and rotation before releasing the next version.

[Azimech]

Nice.

Is the doppler effect working again?

[SpacePixel]

Wow, I'm so glad to see someone maintaining CameraTools! DocNappers, you really are doing God's work!  

Unfortunately, I'm here on some weird business. Could someone elaborate a bit about mouse behaviour when using keypad control with stationary camera mode? You see, I've hooked up a joystick via Joystick-to-Mouse to use it as a pointing device (wanted to make smoother hand movements with stationary camera). It's working, but not with CameraTools. Apparently, it only recognizes the mouse as a pointing device and not the joystick. I'd happy to provide any additional information, maybe there's some line I could add in the config to make it work?

[DocNappers]

3 hours ago, SpacePixel said:

Wow, I'm so glad to see someone maintaining CameraTools! DocNappers, you really are doing God's work!  

Unfortunately, I'm here on some weird business. Could someone elaborate a bit about mouse behaviour when using keypad control with stationary camera mode? You see, I've hooked up a joystick via Joystick-to-Mouse to use it as a pointing device (wanted to make smoother hand movements with stationary camera). It's working, but not with CameraTools. Apparently, it only recognizes the mouse as a pointing device and not the joystick. I'd happy to provide any additional information, maybe there's some line I could add in the config to make it work?

The keyboard and mouse input are independent, so if each are working separately, they ought to work together too. If they're not, then it's an issue with Joystick-to-Mouse doing something weird. (Note: I've tested using two mice in Linux and it works fine, so unless Windows handles them significantly differently, that shouldn't be an issue.)

The relevant section of code for mouse input is:

if (camTarget == null && Input.GetKey(KeyCode.Mouse1))
{
    flightCamera.transform.rotation *= Quaternion.AngleAxis(Input.GetAxis("Mouse X") * 1.7f, Vector3.up); //*(Mathf.Abs(Mouse.delta.x)/7)
	flightCamera.transform.rotation *= Quaternion.AngleAxis(-Input.GetAxis("Mouse Y") * 1.7f, Vector3.right);
	flightCamera.transform.rotation = Quaternion.LookRotation(flightCamera.transform.forward, cameraUp);
}
if (Input.GetKey(KeyCode.Mouse2))
{
    manualPosition += flightCamera.transform.right * Input.GetAxis("Mouse X") * 2;
	manualPosition += forwardLevelAxis * Input.GetAxis("Mouse Y") * 2;
}
manualPosition += cameraUp * 10 * Input.GetAxis("Mouse ScrollWheel");

So, right click and move mouse = rotate camera (if no target is selected), middle click and move mouse = translate camera, scroll mouse = up/down translation.

[SpacePixel]

Just now, DocNappers said:

The keyboard and mouse input are independent, so if each are working separately, they ought to work together too. If they're not, then it's an issue with Joystick-to-Mouse doing something weird. (Note: I've tested using two mice in Linux and it works fine, so unless Windows handles them significantly differently, that shouldn't be an issue.)

The relevant section of code for mouse input is:

if (camTarget == null && Input.GetKey(KeyCode.Mouse1))
{
    flightCamera.transform.rotation *= Quaternion.AngleAxis(Input.GetAxis("Mouse X") * 1.7f, Vector3.up); //*(Mathf.Abs(Mouse.delta.x)/7)
	flightCamera.transform.rotation *= Quaternion.AngleAxis(-Input.GetAxis("Mouse Y") * 1.7f, Vector3.right);
	flightCamera.transform.rotation = Quaternion.LookRotation(flightCamera.transform.forward, cameraUp);
}
if (Input.GetKey(KeyCode.Mouse2))
{
    manualPosition += flightCamera.transform.right * Input.GetAxis("Mouse X") * 2;
	manualPosition += forwardLevelAxis * Input.GetAxis("Mouse Y") * 2;
}
manualPosition += cameraUp * 10 * Input.GetAxis("Mouse ScrollWheel");

So, right click and move mouse = rotate camera (if no target is selected), middle click and move mouse = translate camera, scroll mouse = up/down translation.

Thanks a lot, especially for the code, I might have some ideas how I could make it work! I'll post the trick here if successful.

[DocNappers]

On 7/11/2021 at 6:50 AM, Azimech said:

Nice.

Is the doppler effect working again?

I've heard it work a few times, but it seems to stop working fairly quickly. I think the audio is a bit messed up at the moment. I'll look into it.

[Azimech]

16 hours ago, DocNappers said:

I've heard it work a few times, but it seems to stop working fairly quickly. I think the audio is a bit messed up at the moment. I'll look into it.

Thank you! It really makes the whole experience of a fly-by more real.

I made this short video almost 6 years ago. The sirens are my own mod. I think I still have that version of Camera Tools on my HD. Could take a while to find it. In case you need it, let me know.
 

 

Edited July 14, 2021 by Azimech

[DocNappers]

So, I've looked into what's going on with the doppler effect and from what I can tell, the issue lies with the build of KSP itself and isn't something that I can fix in CameraTools. The problem (I think) is that KSP seems to have disabled the audio spatializer plugin (https://docs.unity3d.com/2019.4/Documentation/ScriptReference/AudioSettings.GetSpatializerPluginName.html returns an empty string and the corresponding SetSpatializerPluginName function doesn't appear to be available outside of the editor in this version of Unity, despite being in the documentation) or it's simply not available in that version of Unity, which is odd since it was supposedly introduced in 2017.2 and this video (https://coding.degree/unity-doppler-effect-tutorial/) demonstrates it being used in 2020.1.

So, basically, I think the appropriate settings are being applied to the audio sources, but without an audio spatializer, the doppler effect isn't being applied. (I think what I heard before was simply an engine spooling down as it went past, which sounded like a doppler effect.)

 

Edit: What I might be able to do instead is to manually adjust the pitch of the audio sources based on their relative velocity to the camera position. I'm thinking to clean up what I've got now and release it as v1.17 and then try to do something like this for the doppler effect.

Edited July 15, 2021 by DocNappers

[Azimech]

15 hours ago, DocNappers said:

Edit: What I might be able to do instead is to manually adjust the pitch of the audio sources based on their relative velocity to the camera position. I'm thinking to clean up what I've got now and release it as v1.17 and then try to do something like this for the doppler effect.

Excellent thinking!

Thanks for the effort!