Help with camera logic

[Siegfried67]

Hi everyone,

I'm facing a problem, it's been days i try to work it out, but to no avail :

I'm trying to control a camera, on a pitch and yaw axis via a seat. Everything is fine at a given zoom level , i can set the rotation speed to be just right with the seat sensitivity.
The problem being, once i zoom in, it moves way to fast, or way to slow once zoomed out.

What i want it to do is be at a "normal" speed zoomed out, and slow down and be much more precise when zoomed in.

I tried with a PID, the integral gain being controled by the zoom level, but it's way to shaky. and doesn't really work.

Is there a way to change the axis sensitivity of a seat while in game depending on the zoom? (20% zoomed out is ok, once zoomed in i have to go down to 2%)

Or if anyone has another idea that would work out.

Thank you.

[Console]

You can try with a micro controller and connect the seat to a number input and a number output to the axis.

Then you could use logics to control the sensivity, depending on the zoom status, which needs to be connected to an own input on the controller.

As exampe: zoom 1.00 - 1.10 = 20% output, 1.10 - 1.20 = 10% output, 1.20 - higher = 5% output.

I made a controller, which you can test or modify for your needs:
https://steamcommunity.com/sharedfiles/filedetails/?id=2006466614
It's untested, but i hope it gives you a hint how to work out a good solution for your needs. :)

[Ra-Ra-Rasputin]

Divide your input by your zoom level, or a multiple of your zoom level, whatever works best. i.e. where X is input and Y is your zoom level x/y, and so on. If you feel that this is far too fast, simply try x/(y*2)

[Siegfried67]

Originally posted by Ra-Ra-Rasputin:

Divide your input by your zoom level, or a multiple of your zoom level, whatever works best. i.e. where X is input and Y is your zoom level x/y, and so on. If you feel that this is far too fast, simply try x/(y*2)

Already tried that, but doesn't work: lets say my input is 0.5, the pivot goes to 0.5 turn... if i zoom in and divide the input by 2, it's twice as sensitiv, but the pivot goes back to 0.25 turn. The position will change when zooming in or out, even without changing the base input.

Originally posted by Console:

You can try with a micro controller and connect the seat to a number input and a number output to the axis.

Then you could use logics to control the sensivity, depending on the zoom status, which needs to be connected to an own input on the controller.

As exampe: zoom 1.00 - 1.10 = 20% output, 1.10 - 1.20 = 10% output, 1.20 - higher = 5% output.

I made a controller, which you can test or modify for your needs:
https://steamcommunity.com/sharedfiles/filedetails/?id=2006466614
It's untested, but i hope it gives you a hint how to work out a good solution for your needs. :)

I'll give it a shot and tell you if it worked.

Edit : same effect, pivot turns back to center when zooming in, and max rotation is only fraction of the max range.

Thanks for the quick answers.

[Ra-Ra-Rasputin]

Well, let me try something quick for you, shouldn't take long. I wanted to make one like this anyway. Consider it an alternative to the previous, unless we end up making the same thing. I enjoy logic puzzles.

[Siegfried67]

Yeah i like playing around with logic, but this one, i'm stuck.

We have to find a way to not divide the input, but the input variation speed.
Tried with a memo block, keeping the base value, but adding ( or substraction) to itself a value based on zoom level every tick.

Right input -> positive threshold gate -> add 1/zoom level to the base input (starting at 0 ) every tick
Left input -> negative threshold gate -> substract 1/zoom level to the base input (starting at 0 ) every tick

Seemed to make sense, but doesn't work, dunno why. Maybe i'm using the memo block wrong, not adding at every game tick, but only one time once i pass the threshold gate.
Maybe if i manage to get repeated on signals every tick to actualize the memo block as long as i press right or left

Edit : Maybe using the "on tick" in a lua script, getting the ON signal out of it into the "set" node of the memo block...

Edit 2 : don't bother too much, i'm going to work and wont see any of the solution before 10 hours... but thanks anyway!

[Ra-Ra-Rasputin]

Here you go. About half of it (and a vast majority of making it) is fixing my spaghetti function's shortcomings and dealing with floating point errors on memory registers. You might still get a slight amount of stuttering due to the math. Pay attention to the sensitivity of the seat controls and the property in the microcontroller

Also i should've made the gimbal value circular, in that it overflows and underflows, but i couldn't be bothered after fixing so many dumb issues

https://steamcommunity.com/sharedfiles/filedetails/?id=2006557525

It's possible to make it completely stutterless and remove the bubblegum fixes i put in, but then the camera will have momentum. To do this, reduce sensitivity of A/D and W/S and then drop the property of the equals in the microcontroller to 0.001.

If you want to invert the controls, simply add a minus to the x's in the first 2 functions

The reason your memory block didn't work is because you're not taking into account that it's writing the value 60 times a second, or close enough to that.

[Siegfried67]

Thank you for your work.

Figured out my memo block was overflowing too quickly, setting the increments to 0.1, it reached max in 1/6 of a sec.

I took inspiration of your logic to remake mine ( that "equal" block is really usefull, had to use multiple threshold gates before). It works much better now, but not perfect : the zoom isn't linear, and i couldn't figure out the math function they use, so the camera takes the same amount of time to cross the field of view at the same speed on different zoom level.

Tried 0.0005x/((y+0.2)*(y+0.2)) as increment on the memo block every tick, x being the seat input and y the zoom input. It's what works the best at the moment, even if it's a bit slow at mid level zoom.

There must be a trigonometry function better suited, but i'm really bad with that kind of stuff.

Anyway, thank you very much, it already helped me a lot.

[Ra-Ra-Rasputin]

I'm sure there's a sneaky way to use trigonometry to determine the very specific ratios at hand, but i'm happy such a spaghetti of an implementation helped you along!