Ability to lock rotation/position axes on Attached camera types?

[TheBlackParrot]

I use an attached camera on my menu camera (attached to a chest bone on the VRM avatar (via NalulunaAvatars)) with the SmoothFollow rotation option set to 0 to freeze the way it's facing but still have it move around, and have to face forwards as a chart ends, or else the camera ends up panning too much to one side. I also use multiple avatars and have to tweak Y rotation on the camera between all of them, as the avatar skeletons all act a bit different from each other.

Can something be added to tell the camera not to adjust specific rotation/position axes relative to the objects they're attached to? If I have a camera facing 60 degrees to one side, for example, I'd like it to be able to always be facing 60 degrees to one side. Everything else can still do whatever it'll normally do, I'd just like to tell specific values not to change.

[kinsi55]

Mhhhh, I'll consider it. If I was to add it it would work for Attached and FP cameras so that its universal, in which case the "Force Upright" feature would get superseded by this and it would also implement #67

[blackorbit1]

Following the discussion in #82, I'm happy you took it into consideration ! Maybe there isn't necessarily the need of distinct min and max if you want to keep the configuration simple. I think having a slider for each axis going from 0 (locked) to 360 could be a solution.

Here's what I'm thinking about (pseudocode):

// parent gameObject / head axis rotation
float axis_rotation;
// axis offset defined in the config
float axis_offset; 
// range chosen for the axis
float axis_range;

applyRange(axis_rotation, axis_offset, axis_range) {
    // please don't judge me :')
    return -1 / (1 + e^(axis_rotation/2)) * (2*axis_range) + axis_range + axis_offset ;
}

The weird formula allows not to have to impression the camera hit a wall when the range is reached. It's a tweaked sigmoid function maybe there are better and simpler way to have a similar result with a derivative of ~1 in most of the range. Example with a range of 5:

[kinsi55]

That wont be the case since the limiting of the range will be done before the smoothing - That being said, I would not add an ingame UI for this (Only the "Force Upright" toggle would get translated into this new handling).

I might at some point rebuild the Camera2 UI and split it into a Simple, and Advanced view - I guess the difference between both would be obvious.

[blackorbit1]

I don't know if a typical smoothing value would allow to avoid the effect of hitting a wall or it may have to be super strong and impact the effect of movement that is researched with those camera types. Also, having that before applying the smoothing would allow more natural camera movements when the rotation is near the range limit.

But yeah it's just a bonus, just having a range parameter would already be awsome :smile:

[kinsi55]

Well, move your head abruply by 30 degrees and then hold it in that location - Thats exactly how it would look if it hits the boundary

[blackorbit1]

Yes but that's the case with and without it. It would just be an almost free cost way to mitigate the problem especially near the range limits

[kinsi55]

I'm not sure I understand what you think the problem here is, the smoothing is eased, so it slows down as it gets closer to the target - And since the target here is what the limit would influence, not the resulting value of the smoothing, it would already smoothly approach the boundary

[blackorbit1]

Ok, I started to code a demo on pygame but I think it's a bit overkill for a issue comment x) I tried to illustrate it, hope it makes sense (the big gray lines are the range limit)

The "vision confort" smoothing of the camera movements scale will likely not match the scale of the rotation range.

That being said, maybe the result will look weird, as if the camera has difficulty to rotate. It's just an idea that I think can be interesting to explore as it can be implemented with a one line function 🙂