How to make 3d camera rotation?

[dusky rivet]

I have been working on this for a bit. And don't have it quite right yet. Here is where I am at right now: https://github.com/bentondrew/farmsim-game/blob/clamp-camera-vertical-orbit/src/characters/player/camera/control.rs#L161.
It does the horizontal rotation just fine but I want the vertical rotation to pin to PI/2 above or below the xz plane but I don't have the rotation quite right and if I am not directly on the z axis, it will start going back down when it gets to the top.

[plush slate]

https://docs.rs/bevy/latest/bevy/prelude/struct.Transform.html
Transform.rotation is a Quat (quaternion). It requires a different kind of mathematics to manipulate. So x isn't x axis, y isn't y axis, z isn't z axis and there is also w 😅

Instead, you can use helper methods like Transform::rotate_y as in
https://github.com/bevyengine/bevy/blob/latest/examples/transforms/3d_rotation.rs
or similar above bsd24 shared

Or you can can convert it into Euler, make your changes, convert it back into Quat via:
https://docs.rs/bevy/latest/bevy/math/f32/struct.Quat.html#method.to_euler
https://docs.rs/bevy/latest/bevy/math/f32/struct.Quat.html#method.from_euler

[woeful tiger]

Hmm, thank you for this information.
When I read everything this, and find what I need, I add tag resolved.

[plush slate]

Feel free to ask

[woeful tiger]

Where can I get euler? Cause mouse give only Vec2.

https://tenor.com/view/hobbes-mouse-cat-kitten-kitty-gif-16040914

[woeful tiger]

Trying to find third number

[plush slate]

😄

let (mut x, mut y, z) = camera_transform.rotation.to_euler();
x += x_coordinate;
y += y_coordinate;
camera_transform.rotation = Quat::from_euler(x, y, z);

I might've confused mouse x with y

and this might be too fast, so you might need to divide it by some number

[plush slate]

ah, what's your up direction?

EulerRot::XYZ

let (mut x, mut y, z) = camera_transform.rotation.to_euler(EulerRot::XYZ);

[woeful tiger]

Yeah, I forgot write "EulerRot::".

[plush slate]

I too 😅

[woeful tiger]

New problem, saving it.
Cause after moving it move to zero zero zero position.

+= not work.

[plush slate]

have you solved it?

[plush slate]

this looks like working

[woeful tiger]

After move camera back to default position.

The video shows that it is impossible to move.

[plush slate]

can you share the code with the latest changes?

do you have movement code? or something that sets transform?

[woeful tiger]

Yeah

[plush slate]

would you mind showing it?

still thinking about it

it is weird

can you move with it?

[woeful tiger]

Yeah, but can't rotate camera.

[plush slate]

ah, found the sneaky

instead of dividing it there

divide x_coordinate and y_coordinate here

x += x_coordinate / 100.0

like so

it should work then

we were dividing our coordiante by 100, so eventually it became closer to 0 each frame

if your mouse movement were enough, you could escape for several frames

but then it would go back to 100

[plush slate]

so, with the change above

it should only divide delta (or change) by 100

[woeful tiger]

One moment, converting video.

[plush slate]

oh, still no worky? :(

[woeful tiger]

Worse than before.

[plush slate]

I think I see two issues there, but let's begin with the obvious one

we are mixing the coordinates

[plush slate]

^ probably this

so, when you move your up and down, it is y axis, right?

but euler rotation is different, rotation is about "rotating around an axis"

[woeful tiger]

Moved down, camera up.

left and right not working.

[plush slate]

so, to move up, we need to rotate around x axis, not y

x += y_coordinate / 100.0;
y += x_coordinate / 100.0;

[plush slate]

if this is still the case

instead of adding, remove it instead

x -= y_coordinate / 100.0;

[woeful tiger]

Same

[plush slate]

let me come up with a quick demo, I have some ideas but it would be easier if I could test them. will reply in around 15 mins

[gray dove]

Have you guys seen the mouse_look example here? https://github.com/PROMETHIA-27/bevy_mod_wanderlust/blob/master/examples/first_person.rs They do it without converting to euler, might give better results

[plush slate]

yeah, that looks good

[plush slate]

found the issue @woeful tiger

euler rotation needs to be applied in a sequence, that's where I messed up

using EulerRot::YXZ instead

let (mut y, mut x, z) = camera_transform.rotation.to_euler(EulerRot::YXZ);

camera_transform.rotation = Quat::from_euler(EulerRot::YXZ, y, x, z);

and removing both coordinates

x -= y_coordinate / 100.0;
y -= x_coordinate / 100.0;

though you need to clamp your x coordinate as that's one of the issues of euler math. you can see it in action by moving all the way up

you are either way going to clamp your x coordinate, so that's okay

[plush slate]

this is fancier ofc, this probably wouldn't have that issue as that's one of the reasons to use quaternions

good luck! 😅

[woeful tiger]

It's work!
But now left is up and right is down.

😵‍💫

[woeful tiger]

x += y
y -= x

[woeful tiger]

https://tenor.com/view/wtf-gif-gif-26042600

Why does it even work.

Thank you so much @plush slate!

If you don't mind, I'll add you as a friend.

Сamera movement regardless of its rotation.

[woeful tiger]

https://tenor.com/view/stitch-stressed-gif-13066022

[woeful tiger]

I need to take a nap.

[plush slate]

no problem. but please ask your questions here, so others can also find from search history

[plush slate]

that's easy

so when you rotate something, its forward direction is no longer its z+

so instead of this

z_coordinate -= camera_transform.forward() * CAMERA3D_SETTINGS.camera_speed;

like so for z axis

camera_transform.right() * speed

for the x axis

[plush slate]

ahhh, yeah, my bad

[woeful tiger]

: f32 = ?

[plush slate]

nope
z_coordinate and x_coordinate needs to be combined into a vector3

instead of this

let mut movement = Vec3::ZERO;

[plush slate]

then instead of this

simply add it into movement

movement += camera_transform.forward() * CAMERA3D_SETTINGS.camera_speed;

[plush slate]

then, you'll have to set y to zero, after this

otherwise it is like noclip flight 😅

[plush slate]

and preferably normalize it after that

so there is no speed loss due to looking up or down

[plush slate]

about this:
rotations affect each other. if you rotate your camera downwards first via x axis, then rotate it from y axis to side by side, you change where your y axis points

that makes it act weird as it constantly changes your "up" direction

but if you rotate around y first, as y is your up direction, it doesn't do that

you can then apply your x direction

EulerRot::YXZ does that

applies rotation in that order

so it works

[plush slate]

you are welcome 😅

I think there is nothing left I haven't anwered :P

[neat bronze]

Hi @plush slate I'm new to game dev. Where did you learn about game math rotation, euler, quartenion? Is it experience from another game engine or do you have any youtube or book reference?
Thanks.

[plush slate]

Some are from high school, some are from previous experiences 😅 Unrelated to rotation but I can suggest this:
https://youtu.be/DPfxjQ6sqrc

I've also found a playlist way extensive than the video above. I haven't watched it but it looks good:
https://www.youtube.com/watch?v=fjOdtSu4Lm4&list=PLImQaTpSAdsArRFFj8bIfqMk2X7Vlf3XF

[gleaming flint]

for quaternion specifically this video is great https://www.youtube.com/watch?v=zjMuIxRvygQ https://eater.net/quaternions

[neat bronze]

Exactly, I'm doing Math really bad at highschool lol.
Thanks anyway.

[woeful tiger]

New day - New problem, move right working not as I want.

so many problems with this movement.

https://tenor.com/view/cat-sad-котик-грустный-phone-gif-23938000

[woeful tiger]

waiting for someone to answer

[plush slate]

abs

that's the issue

[woeful tiger]

I don't remember why I added it, but the code didn't work without it.

Removed it, code still works...

[plush slate]

is it solved?

[woeful tiger]

Yeah...

TechoWizard

[plush slate]

so, imagine having a vector pointing fowards towards the Z axis

Vec3::new(0., 0., 1.);

it would be like so, right? Z being 1. that would be your forward vector. taking absolute of it wouldn't change anything as it is positive

but if you turn around 180 degrees, look towards back, now your forward vector would be

Vec3::new(0., 0., -1.);

[plush slate]

if you get absolute of it, it would become this ^

so, that was the issue

but for all components (x, y, z), not just z

also, a quick bug I caught

if you look towards ground, space or ctrl wouldn't work as you expect

because now your new up direction is previous forwards as you rotated towards ground