Linear Dynamics, Forces, Momentum vs Inertia

     Hello, and welcome to my final blog for this semester on game engine design and implementation. Before I got started on my review of information I just wanted to say thanks to everyone who actually read my blogs, although it's really not necessary, I do appreciate you taking the time to do so.

My first topic for review today is going to be Linear Dynamics.

     Linear dynamics is, simply put, the calculations that an engine has and uses to drive the basic movements of objects in a game or program.

     Some examples of linear dynamics are the kinematics eqations seen here:

          http://www.physicsclassroom.com/class/1DKin/Lesson-6/Kinematic-Equations

     Or perhaps some more basic equations that people may have heard of the force and momentum equations:

     Force = mass x acceleration                      (F = ma)
     Momentum = mass x velocity                   (P = mv)
No, I don't know why they use "P" for momentum either :P
     Drag = -Mass x mass density x velocity   (F = -mpv)


     There are also some useful formulas for spring kinematics:

     Force = - spring stiffness x  distance of compression


 Momentum vs Inertia

     The most noticeable difference between the two is that momentum is a vector and inertia is a scalar value. I've shown the equation for momentum above, but what about inertia? Inertia is a property of an object, and is typically measured through something called "the moment of inertia".

   
Rerefences:

http://www.physicsclassroom.com/class/1DKin/Lesson-6/Kinematic-Equations
http://en.wikipedia.org/wiki/Drag_equation
"Momentum vs. Inertia". Saad R. Khattak. November 20, 2014.

Deferred Rendering and Review

  Deferred Rendering/Shading - A Brief Overview
 
     Deferred Rendering is a "screen-space shading technique". The reason it is called deferred is because no rendering is performed in the shaders in the first pass. Deferred meaning to be pushed back, postponed or delayed.

     Deferred Rendering is used primarily for detaching the geometry rendering from the rendering of the lighting. We use this technique mainly because it reduces the lighting calculations being done on a scene at any given time since we are now taking things like depth into consideration. By doing this, we are no longer performing the calculations needed to light backfaces that we won't actually view from the cameras current position, saving the GPU a few processes, making our game more efficient.



     One major disadvantage of deferred rendering is that its algorithms are incapable of handling transparency. Depth peeling can be used to solve this issue, which is a technique for rendering transparency in a 3D scene that does not require rendering geometry in sorted order for alpha compositing. The only issue involved in this technique is that it costs additional batches in order to render.
     - Batches: "Chunks" of data that are bundled together and passed through the shaders in one rendering pass.

REVIEW

     One of the more difficult concepts that we have discussed in class have being matrices. A lot of people have trouble with matrices, and since they are one of the most important base concepts involved in graphics and rendering I have decided to go into some nice detail and explain things at a very base level so that HOPEFULLY someone who didn't get the concepts before will get them now.

    I will not be talking about 2x2 matrices, unfortunately, because they are not very commonly used in 3D graphics and that is the main focus of my studies at the moment. My apologies for those who might need that information. (Check out Khan Academy, he's great : https://www.khanacademy.org).

3x3 Matrices.

- Used for representations of rotational matrices.
     + An object's rotational matrix specifies its orientation in a corresponding space. Typically this space will be related to its orientation in the world (or world space).

Creating/Representing a 3x3 Matrix:

     Below is a 3x3 Identity Matrix. This represents an objects orientation as being unaltered or in its "identity" form. This means that no transformations have been applied to the object.

|   1   0   0   |                |   a   b   c   |  
|   0   1   0   |     OR     |   d   e   f   |
|   0   0   1   |                |   g   h   i   |

     The only differences in matrix representations come from whether the user/programmer decides to create the matrix storage in column-major order or row-major order. In code, these matrices would be accessed and manipulated much differently because the data's positions in an array/vector would be much different depending on how they are arranged:
Column-Major               Row-Major
|   1   4   7   |                |   1   2   3   |  
|   2   5   8   |                |   4   5   6   |
|   3   6   9   |                |   7   8   9   |

     Applying Rotations is quite simple once your object has an applied matrix. For efficiency reasons, as well as avoiding things like gimbal lock (http://en.wikipedia.org/wiki/Gimbal_lock) we apply rotations to a single axis at a time.

Rotation Matrices Around each axis.

Base
|   x   0   0 |

|   0   y   0 |

|   0   0   z |

  Around X                               Around Y                                  Around Z
|   1       0          0      |     |   cos(β)   0   -sin(β)   |     |   cos(β)   -sin(β)   0   |

|   0   cos(β)  -sin(β) |     |       0       1       0        |     |   sin(β)    cos(β)   0   |

|   0   sin(β)   cos(β) |     |   sin(β)    0    sin(β)    |     |     0           0         1   |

**Note: The axis that is being rotated around is the one that remains unchanged by the rotational values.

4x4 Matrices

Commonly referred to as a general transformation matrix. This is, simply put, because it holds data for every common transformation on an object. This includes:
 - Rotations
 - Translations
 - Scale (typically done uniformly because of rendering issues in non-uniform scaling)

Rotations in a 4x4 matrix are simple. In order to make a rotation to an object using a 4x4 matrix you do the exact same calculations you did for 3x3 matrices, but you apply them only to the 9 positions in the top-left most corner of the matrix:

|   1   2   3   x   | **1 to 9 is your 3x3 matrix for rotations.
|   4   5   6   x   |
|   7   8   9   x   |
|   x   x   x   x   |

Scale is also quite simple, really. In order to scale an object using a 4x4 matrix all you need to do is multiply each of the values in the indicated (by x, y, z) positions below by your uniform scale value.

|   x   0   0   0   | x = x scale
|   0   y   0   0   | y = y scale
|   0   0   z   0   | z = z scale
|   0   0   0   1   |

Translations, like scale, is a very simple method to grasp. When you have a vector that you want to use to translate the position of an object you simply take that vector and add its x, y, and z values to the indicated x, y, and z positions in the 4x4 matrix below.

4x4 Matrix          Vector
|   1   0   0   x   |        | a |          |   1   0   0   x + a   |
|   0   1   0   y   |  +    | b |    =   |   0   1   0   y + b   |
|   0   0   1   z   |        | c |          |   0   0   1   z + c   |
|   0   0   0   1   |        | 1 |         |    0   0   0     1      |


References:
     http://en.wikipedia.org/wiki/Deferred_shading
     http://en.wikipedia.org/wiki/Order-independent_transparency
     http://en.wikipedia.org/wiki/Gimbal_lock
     http://en.wikipedia.org/wiki/Rotation_matrix
     http://en.wikipedia.org/wiki/Transformation_matrix
     http://gamedevelopment.tutsplus.com/articles/forward-rendering-vs-deferred-rendering--gamedev-12342