Game Basics Mathematics for 3D Games 1 (3D Space Design, Euler Angles)
GCC Academy
Hello everyone
This is Lee Deuk-woo on Game Mathematics
Today, we will be talking about the third dimension
Before learning about math for 3D,
let's first learn about
how to design the transforms in 3D space
We will start by designing a 3D space
What is different about setting transform in 3D than in 2D,
and in a 3D space,
how do we design the camera system?
We will find out together
And finally, we will take a look
at a work produced with this theory
Next, we'll learn about Euler angles,
an expression for rotation in a 3D space
We will first learn about the expression in an Euler angle,
and then the strengths
and limitations of Euler angle
Designing a 3D Space
When dealing with 3D space,
Let's start with 2D space
In 2D, the x-axis typically points to the right, and the y-axis points upwards,
which makes implementation relatively straightforward
However, in 3D, the space is composed of three axes,
and the way you design this space
can influence the application methods
and the mathematics we will explore
Therefore, it is crucial to clearly define this first
Instead of simply adopting
a coordinate system jus because
this application uses it,
it is better to think about the principles
and establish a system
that suits your needs
I think that is a better way to work with it
So now, for us
to design a 3D space,
you must choose between two options
Using a left-handed
or a right-handed coordinate system
Let me explain briefly about how to distinguish
between the left- and right-handed system
When you create a 3D space,
it essentially adds
one dimension to a 2D space
Then, in designing a 2D space,
to start, fix the 2D space
As this is generally accepted, as we look at the monitor
the x-axis points to the right
and the y-axis points upwards
Now, after we have fixed
this 2D space as we see it here,
based on the direction of the remaining dimension,
you can distinguish
whether the system is left- or right-handed
When you look at the screen,
you can see that after fixing the red
and green axes as the x and y axes,
the direction of the remaining z-axis
determines whether
the system is left-handed or right-handed
If the z-axis points away from you,
beyond the monitor,
it is a left-handed coordinate system
On the other hand, if the z-axis points toward you,
it is a right-handed coordinate system
That's how you can understand it
The left-handed coordinate system is characterized as follows
When we fix the x and the y axes,
by the z-axis pointing forward, beyond the screen,
stretching like this
This makes it suitable for viewing landscapes
or scenes stretching into the distance
In contrast, the right-handed coordinate system,
where the z-axis points toward you,
can be more useful
when observing objects up close
Ultimately, deciding between
the left-handed and right-handed coordinate systems
depends on your preference,
and it's not necessarily set by rule
Go for what feels more comfortable
or convenient for the system
that you are designing
Once you’ve chosen a coordinate system,
the next important decision is
determining which axis will be designated as the upward axis,
of x, y, and z axes
which will be designated as the upward axis?
We have to designate one
The Up direction, as it is commonly referred to,
becomes particularly important later when we deal with operations
like cross products or when calculating rotation matrices
based on view vectors
Knowing and setting the Up direction clearly is crucial
Broadly, the classification involves choosing between left-handed or right-handed systems
and deciding the Up direction
For example, as shown in a diagram
shared on Twitter (X),
systems are generally divided into left-handed and right-handed coordinate systems,
with an additional distinction based on
whether the Up direction is along the y-axis or the z-axis
That's another classification
By classifying the coordinate system into these categories,
just understand that these systems
or programs use these distinctions
In this course, when we deal with 3D graphics,
in the program I developed,
all examples are implemented using the specific type
of coordinate system I have designated
The examples will use a right-handed coordinate system
with the Up direction along the y-axis,
referred to as Y-up Right-Handed
This means we will use the Right-Handed Coordinating System
with the y-axis pointing upwards, to be very brief
The forward and backward directions,
the remaining directions,
will be determined by the z-axis,
while the left and right directions
will be handled by the x-axis
This is the coordinate I will be using
Please take a look at it
After setting up the coordinate system,
the next step involves
configuring 3D transforms
When transitioning from 2D to 3D,
additional considerations arise
For instance, in the case of translation transforms,
movement along the z-axis is added
to the x and y movements already present in 2D
However,
since the x, y, and z axes are orthogonal,
movements along one axis do not affect the others
Therefore, adding an additional dimension
to the matrix we have
allows for straightforward solutions without much complexity
So it's not a big problem
For scaling transformations, enlarging along the x and y axes
does not affect the z-axis,
so it simply involves extending the matrix
to accommodate the added dimension
However, rotation transformations
are more complex because all three axes
influence one another
while maintaining orthogonality
So this is much more complex
Translation and scaling can be easily implemented
by simply extending a single axis
However, in the case of rotation, the addition of one axis
causes all three axes to influence one another,
making it a much more complex transformation
To understand rotation,
consider the x, y, and z axes,
our initial orthogonal x, y, and z axes,
which are rotated
to form a new set of local basis vectors
By substituting the transformed basis vectors into the matrix,
like this,
you can construct a 3x3 rotation matrix,
which consists of nine elements representing these transformations
So that's a rotation transformation
Using the transformed standard basis vectors, such as e_1, e_2, and e_3,
the rotation matrix can be established
as mapped to x_local, y_local, and z_local
By marking the values,
we can then derive the corresponding matrix
For the scaling matrix, the original 3x3 matrix
is extended by adding one more dimension, resulting in a 4x4 matrix
By simply adding the z-axis component to the last row,
the matrix can be easily constructed
However, with rotation, local axis information must
be fully determined
and inserted vertically
to build the rotation matrix
Translation matrices
similarly involve extending the z-axis
and follow a similar design like this
Using these principles, we can construct the modeling matrix
and calculate the TRS like this
The process is not fundamentally different
from what we explored in 2D matrices,
but adapted for 3D space
In this way, we have explored
how to design transformation matrices in 3D space
Now, let’s move on to discussing the camera and its setup
It's not too different with the camera
Finally, when designing the camera for 3D space,
additional considerations arise
or example, using the y-axis
as the Up direction in 3D space,
the z-axis for an object
at the origin typically points toward the monitor,
or towards us
To observe an object properly,
the camera should be positioned in the positive z-axis direction,
facing the object
For example, placing the camera at my position
and pointing it toward the monitor
means that the camera is not facing towards me
If it is rotated 180 degrees, I towards the monitor,
the object towards the monitor,
it means it's facing towards me
That's how we can face the front of the object
If the camera is rotated 180 degrees,
an issue arises
where the x-axis of the camera’s coordinate system
points to the left instead of the right
This contradicts the standard convention
where the x-axis should point
to the right in the final rendered view
Now that it's the left,
it creates an uncomfortable experience for the viewer,
as the output appears flipped
To solve this,
the camera’s coordinate system should be adjusted
so that the x-axis points to the right,
while the y axis stays there
Therefore, in this camera setup,
the final coordinate system
must maintain the orthogonality
of the three axes as originally defined
So now,
the camera is facing forward,
but by rotating the y-axis 180 degrees,
causing the x-axis to align to the right
and the z-axis to point backward from the camera,
This creates a right-handed coordinate system
where the viewing direction
now points in the opposite direction,
behind the camera
The x-axis and y-axis,
which represent the important dimensions of the camera’s view,
align with the standard directions we naturally perceive
However, the z-axis points behind the camera,
meaning the viewing direction corresponds
to this reversed z-axis orientation
To place our camera
and construct a proper view coordinate system,
the x and z axes must be flipped to match this convention
That completes our view coordinate system
Let's now create a view matrix
which is responsible creating this view coordinate system
In 2D, the view matrix was derived
from the inverse of the camera’s transform matrix
by first applying the translation
and then reversing the rotation
The same approach applies to 3D
Translation is applied first,
followed by the inverse rotation
For rotation, the yaw rotation matrix is used,
and its local axes are organized into columns,
then transposed into rows to form the rotation’s inverse matrix
The translation’s inverse matrix involves negating the x, y, and z components of the translation vector.
So, the x, y, and z axes are
initially arranged as columns
So, the x, y, and z axes are arranged as columns
This transposed matrix represents the inverse rotation matrix
used for the camera transform
For the translation inverse matrix, it’s straightforward
As previously mentioned, you simply negate the x, y,
and z components of the translation vector
That gives you the translation inverse matrix
You first apply the translation inverse,
followed by the rotation inverse
By multiplying these two matrices,
the translation component becomes
part of the result as a dot product
At this stage, we need to add something
If we stop here, this is what we get
This is what we get if we stop here
To fully convert the matrix into the view space,
the x-axis and z-axis values must be inverted
By reversing the x and z components
in the original transform information,
both the basic x and z values,
as well as the corresponding elements
in the dot product, are negated
This adjustment produces
this view coordinate system
That was on the foundational setup for 3D space
Next, I will demonstrate
how to apply the view matrix to render a 3D cube
using the program I created
First, the object will be positioned at the origin point (0, 0, 0)
You can imagine
placing a rectangular cube on the monitor
that you are currently looking at as the object being discussed
Next, the object will be rotated 45 degrees around the y-axis
and 60 degrees around the x-axis
This means the object will first spin around the y-axis,
like the rotation of a helicopter propeller,
and then tilt by -60 degrees around the x-axis,
something like this,
as if for nodding
These two rotations combined will result in a state
where the object has been rotated in both directions
After applying these rotations, the camera will
be positioned at (0, 0, 500)
This placement assumes the positive z-axis points outward
from the monitor toward you,
meaning the camera is essentially placed at your position
Since the camera is facing the monitor,
the view needs to be adjusted by a 180-degree rotation,
in the y-axis,
so that the camera can face the object
This is the result
of that scene we just created
This concludes the demonstration
of how to set up and configure a 3D scene
The result displayed here shows
the rectangular shape that appears slightly unnatural
due to the lack of perspective applied
In the upcoming section, we will explore
methods to incorporate perspective into the scene
and compare the resulting outputs
This concludes the basic setups for the 3D space
Euler Angles
To understand Euler angles,
we must first revisit how to handle rotations
in 3D space, as discussed previously
When constructing a rotation matrix,
the standard basis vectors e_1 , e_2 , and e_3
are transformed
while preserving their original orthogonality,
rotating the axes to result in this rotation matrix
The transformed vectors, which are now defined
as local X, local Y, and local Z,
these three local vectors
of x, y, and z
are arranged as columns
to create a matrix
While constructing the rotation matrix is straightforward
if the values of these transformed local axes are known,
the challenge lies in determining
the new local axis values after rotation
If we want to rotate it by some angle,
what is the value of each local axis
that has been rotated? That is still a question
For instance, if a game developer
who is not familiar with math
wants to rotate an object 30 degrees around the y-axis,
with that command that resulted in the 30 degrees rotation,
calculating the exact values of
the local x, y, and z vectors after the rotation
becomes a complex problem
It could be a very complex problem, indeed
The second issue arises
when managing rotations using matrices
As shown, a rotation matrix
requires three 3D vectors,
resulting in a total of nine data elements
When issuing a simple command like
rotate 30 degrees around the y-axis,
determining how to correctly arrange and calculate
these nine values can be cumbersome,
especially in the developer's point of view
From a developer’s perspective,
a simpler method
for representing rotations in 3D space
is highly desirable
his is where the Euler angle representation comes into play
As shown on the screen,
the Euler angle representation expresses rotations in 3D space
by specifying the amount of rotation
around the local x, y, and z axes
The newly defined basis axes
e1, e2, and e3 correspond to
the standard basis vectors (1, 0, 0), (0, 1, 0), and (0, 0, 1)
So they do not need to be explicitly included
Instead, only the rotation values for these axes
can represent the 3D rotations
as the following,
as theta_x, theta_y, and theta_z
This approach significantly reduces complexity,
as it replaces the need for nine matrix elements
with just three values
for representing rotations in 3D space
In Unity, rotation values for each axis are managed
using the Vector3 structure,
while in Unreal Engine,
rotations are handled through a Rotator structure
A key distinction is that Unity
uses x, y, and z values directly,
whereas Unreal Engine employs Yaw, Pitch, and Roll
to define rotations,
which are modeled after airplane movements
Let's talk more about
the Yaw, Roll, and Pitch rotations
Yaw, Pitch, and Roll are specific types of rotations
based on how an object moves relative to its axes,
often visualized
using an airplane as you can see
This is the rotation in an airplane
We do not determine this
as x, y, and z axis
We instead determine the rotation based on the shape
Let me explicate
The Yaw rotation
is rotating around the Up vector,
akin to
a helicopter propeller's rotation
that we all know of
That shape of rotation
occurring in a 3D space
is what we call a Yaw rotation
As for the Pitch rotation,
it rotates around the left-to-right axis,
resembling
a nodding motion like so
The Roll rotation happens around the forward axis,
where the object spins
like a barrel roll
These three types of rotation define how objects move in 3D space
If the rotation occurs around the Up vector, it is referred to as Yaw
If the rotation occurs around the left-right axis
with a nodding motion, it is Pitch
Finally, if the rotation happens around the forward axis,
it is Roll
Regardless of which axes (x, y, z) are used,
the shapes of the rotations remain consistent
This consistency allows for easier exchange of rotation data
between different programs that use varying 3D coordinate systems
By standardizing rotations
with Yaw, Pitch, and Roll based on these rotational shapes,
it becomes much clearer
and more precise to share rotational information
across different
systems or applications
For us, Yaw, Roll and Pitch are the following
Our coordinate system is the right-hand one
The left-hand one does not matter here
So for each of x, y, and x axis,
we can assign Yaw, Roll, and Pitch
In the context of a Y-up coordinate system,
Yaw corresponds to rotation around the y-axis
or the vertical axis
Now the x axis is the left-right, while the z is the forward-backward
Pitch corresponds to rotation around the x-axis
Roll corresponds to rotation around the z-axis
That's how each of them is assigned
in our program
The Yaw, Pitch, and Roll convention
originally came from aeronautics,
adopted in mechanical engineering
over time with the original methods
and later became a standard in computer graphics,
where it is still widely used today
As previously mentioned,
different programs may use axes differently,
but representing rotations based on their shapes
ensures that the rotation information
can be clearly exchanged between systems
That's the major advantage
Ultimately, Euler angles
need to be converted
into rotation matrices, why?
To create a TRS (Translation, Rotation, Scaling) matrix,
a rotation matrix is necessary
Even though Euler angles are user-friendly,
for operations involving a large number of points
like tens of thousands or millions,
matrices are essential for efficient transformations
Therefore, based on the information of the Euler angle,
creating rotation matrix is necessary
Let's dive deeper into it
First, Euler angles
do not represent
a single instantaneous rotation
It's not an instantaneous thing
Instead, they describe a sequence
of three rotations, each around a local axis
First, the object is rotated around the x-axis
After this rotation, the local y- and z-axes shift to new positions
Now based on its new local axes,
the object is rotated around the y-axis
Finally, the object is rotated around the z-axis, again using its updated local axes
This sequence of rotations, broken into three steps,
intuitively represents 3D rotations
I say intuitive for users,
but in terms of theory, it involves
a layered transformation process
That's how it works, essentially
So the order of these opretaions is critical
x, y, and z, or Yaw, Roll, and Pitch
These three rotations, Yaw, Pitch, and Roll,
are applied one by one
Depending on the chosen order,
six possible cases of applying the rotations can occur,
of which we need to choose one
To determine the order of applying
rotations to the local axes,
a common sequence
is Roll, Pitch,
and then Yaw, in that order
This method is widely adopted in game engines
such as Unreal Engine and Unity,
making it the standard approach
for handling Euler angles
If you are wondering
how to remember this order,
think of the process
as similar to controlling an airplane
First, the airplane stabilizes
its horizontal orientation to be able to fly
by rolling around its forward axis
Next, to fly upward,
the airplane nods
upward or downward
by pitching around its left-right axis
Finally, to steer toward the destination,
the airplane turns left or right
by yawing around its vertical axis
This sequence,stabilize the roll, adjust the pitch,
and steer with yaw,
matches the order
Roll, Pitch, and Yaw,
making it intuitive for applications
Once the order is set,
the next step involves
calculating the rotation matrix
based on this sequence
Each axis's rotation matrix
will be derived like so
The rotation matrix for the x-axis
means x is the basis
that represents a rotation
around the x-axis,
where the x-axis itself remains unchanged
In this case, only the y- and z-axes undergo rotation,
without the x axis rotating,
effectively describing a planar rotation within the yz-plane
For the x, y, and z axis,
Since I'm a right-handed person, like this,
let's think about a yz plane based on this x axis
In a right-handed coordinate system,
y axis is Up, x axis is Left-Right, and z axis, Forward-Backward
This right-handed positioning
is the 3D coordinate
that my program uses
For a rotation about the x-axis,
for this rotation,
the yz-plane rotates,
with the direction of rotation
being from the y-axis
toward the z-axis
When looking at the rotation matrix for the y- and z-axes,
it includes cosine and negative sine components,
which form the basis of the rotation matrix
Thus, for the x-axis rotation matrix, it can be represented in this way
Moving on to the rotation matrix for the y-axis,
the y-axis remains unchanged
What’s critical here
is whether this y axis rotation
goes from the x-axis to the z-axis or vice versa
It's determining the sequence of rotation within the plane
When the rotation is based on the y-axis, it starts from the z-axis
and moves to the x-axis, forming the zx-plane rotation
If you list the sequence x, y, z repeatedly,
like so,
and you rotate about the x-axis, the remaining plane is yz
Then, for the y-axis,
the sequence becomes zx,
and for the z-axis, it becomes xy
This is how the order of rotations is determined when designing the matrices
Because it moves from zx,
it effectively flips the xz-plane,
creating a transposed matrix
It's a flip
This inversion results in the rotation matrix for the y-axis
having a negative sign
in the lower-left corner
It’s easy to get confused,
so it’s important to understand this clearly
For the z-axis rotation, it starts with the xy-plane,
and its rotation
behaves consistently as expected
In this context, the y-axis corresponds to Yaw,
the x-axis corresponds to Pitch, and the z-axis corresponds to Roll
Since we apply the rotations in the order Roll, Pitch, and Yaw,
Yaw is applied last,
which places its rotation matrix at the far left
R_y by
Roll, being the first applied, goes on the far right,
making the order of matrix multiplication
R_y×R_x×R_z
If Yaw, Pitch, and Roll are represented
as α, β, and γ, respectively,
each rotation matrix can be computed
and multiplied to yield the final result
Although this composite rotation matrix is lengthy,
it represents the 3D rotation derived from Euler angles effectively
So, this is what it is,
the 3D rotation matrix
derived from Euler angles
The calculated rotation matrix
is identical to the rotation matrix for 3D space
The column vectors here
are the rotated results
of the local x, y, and z axes
That's what it is
If you take this part
and extract it as a vector, it becomes the local x-axis
If you take this part, it becomes the local y-axis
Lastly, taking this part gives you the local z-axis
In game design,
this allows us to specify
a desired 3D space like this
Now, while this resolves two problems,
Euler angles still have their own limitations
Let’s take a look at this
It might seem like a perfect solution,
but there is a fundamental limitation to Euler angles
As I explained earlier,
if they look straight ahead and apply a Roll rotation,
the face rotates, right?
The face, or your nose as the center,
turns sideways like this
Then, if I apply a Pitch rotation
about theneck,
then it goes this way
After this Pitch rotation,
when I proceed to the Roll, Pitch, and Yaw rotations,
and continue,
what happens with the Yaw rotation?
The face rotates around its center again,
around the face
It's rotating around the center of the face
This is the replica,
the exact same result
as the initial Roll rotation
as we've seen here
Essentially, the rotations from two axes
end up being used for rotating the face,
This means that a rotation that should involve three axes
becomes
unnaturally constrained to two axes,
resulting in an inability to properly represent the rotation
This phenomenon is called gimbal lock
To demonstrate this,
let’s look at a simple example
In this demonstration, as the object rotates freely,
there’s a specific condition
Here, despite using different keys for control,
the same rotation is applied
You can see that both the Yaw and Roll rotations are continuously changing,
but in the end, they only affect the face's rotation
Even when pressing
separate keys for Yaw or Roll,
both seem to control the same motion
As a result,
the freedom to express rotation
becomes severely limited in this situation
This phenomenon can occur occasionally,
but detecting the exact moment it happens
is very challenging
To prevent this issue,
developers need to write defensive code,
making it difficult
to safely implement rotation
Euler angles
work fine when the object is static,
or when the rotation doesn’t change
It’s effective for representing fixed rotations
However, when the rotation dynamically changes and shifts freely,
unexpected situations like gimbal lock can occur,
making it very tricky to handle
Thus, while setting fixed angles
for static objects
in engines is fine, like this
since we’re assigning values without movement
Euler angles pose critical problems
when it comes to objects
that need to rotate freely
That's one
The second issue is interpolation of rotations
When we rotate an object using Euler angles along one axis,
such as a Yaw rotation by 15 degrees
followed by another Yaw rotation by 30 degrees,
the result is intuitively a Yaw rotation of 45 degrees
In terms of rotation, this means
a 15-degree rotation plus a 30-degree rotation equals a 45-degree rotation
If we represent this as R_2 and R_1,
combining a 15-degree and 30-degree rotation
should logically result
in a 45-degree rotation
Mathematically,
this holds true because,
for Euler angles, only one axis rotates
while the others remain stationary
Since the other axes contribute nothing to the rotation, or 0 degrees,
so that's a Roll rotation
For Pitch rotation,
It's treated as an identity matrix, or I
So the related things here use I
Ultimately, these two matrices
result in the same conclusion
By adding two angles,
we can create a new angle
This demonstrates that interpolation is valid
If the sum of these two angles results in the same outcome,
for example,
if we interpolate halfway,
we only need to include half of each angle
This allows us to determine the angle at any proportion
between the start and end,
making partial rotation possible
However, if more than two rotations
are involved and angles are applied simultaneously,
issues arise at this point
In such cases,
the previously valid equations no longer hold
For example, if you apply both a roll rotation and a yaw rotation,
the 45-degree rotation represented as R_yaw3×R_roll3
differs from the outcome of applying each rotation
separately, by 30, right?
By 15 degrees or 30 degrees
This is Ru3×Rl3
While this is R_yaw2, R_roll2, R_yaw1, R_roll1
For the angles to align,
rotations must follow the same axis and sequence
However, since roll and yaw
alternate across different axes,
their summed rotations
do not guarantee consistent results
for their rotations
Consequently, the results differ
This inconsistency makes interpolating Euler angles with more than two rotations
challenging and impractical
Since these rotations cannot be expressed as a simple sum of angles,
the process becomes more complex
For instance,
in animations,
let's say that we're going for some
animation work in a timeframe
if you simply define a starting and ending angle
to create a smooth transition
with keyframes in between
this approach fails with Euler angles
Instead, you need to use methods like axis-angle rotation, where a specific axis is defined,
and rotation occurs around it
to interpolate between the start and end rotations
Common techniques for this include Rodrigues’ rotation formula or quaternions
However, in this session,
we will focus solely on Euler angles
We explored how Euler angles are used
to define rotations in 3D space and their limitations
This concludes today’s lecture
Thank you for your hard work
Thank you
Design of 3D Space 3D space is divided into left and right-handed coordinate systems, defined by three axes Here, we use the right-handed Y-up
3D Transform Setup The rotation mechanism: M=T·R·S= [x_x·s_x y_x·s_y z_x·s_z t_x]
[x_y·s_x y_y·s_y z_y·s_z t_y] [x_z·s_x y_z·s_y z_z·s_z t_z] [ 0 0 0 1 ]
3D Camera System To view the world from the camera's perspective, the x-axis points to the right
Rotating the y-axis 180 degrees aligns the screen's axes with a Cartesian system Flipp x and y axes to create the view coordinate
View Matrix Construction V= [-x_x -x_y -x_x x·y] [y_x y_y y_z -y·t] [-z_x -z_y -z_z z·t] [ 0 0 0 1 ]
Euler angle representation Rotation matrix: local vectors in columns Rotations are expressed with three angles
Unity Engine uses x, y, z in a Vector3 structure, while Unreal Engine uses Yaw, Roll, Pitch in a Rotator structure
Yaw, Roll, Pitch Rotation Yaw: Rotation around the up vector, resembling a propeller
Roll: Rotation about the forward axis Pitch: Rotation about the side axis, like nodding
Euler Angle Application Order Roll→Pitch→Yaw Rotation Matrix for Euler Angles R= [cos_α·cos_γ+sin_α·sin_β·sin_γ·cos_β·sin_γ
-cos_a·sin_γ+sin_α·sin_β·cos_γ·cos_β·cos_γ sin_α·cos_β-sin_β]
[-sin_α·cos_γ+cos_α·sin_β·sin_γ sin_α·sin_γ+cos_α·sin_β·cos_γ cos_α·cos_β] Local Vectors with Euler Angles
x_local=(cos_α·cos_γ+sin_α·sin_β·sin_γ, cos_β·sin_γ, -sin_α·cos_γ+cos_α·sin_β·sin_γ)
y_local=(-cos_a·sin_γ+sin_α·sin_β·cos_γ, cos_β·cos_γ, -sin_α·sin_γ+cos_α·sin_β·cos_γ)
z_local=(sin_α·cos_β, -sin_β, cos_α·cos_β) Issues with Euler Angles
Gimbal Lock: Two axes align under certain conditions Interpolation of Rotation: Euler angles make interpolation difficult with many axes