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

Vectors, Matrices, Quaternions, and Tangent Space

In Review
     We covered many mathematical concepts in the previous weeks. In a short, hopefully brief, and definitive way, here is what we have covered in recent weeks:

Vectors
      "A point in space represent by and x, y, z location. This point must come from an origin."

Unit Vectors
     "Normalized vectors"
          - Normalization: v =  ( v / ||v|| )

Representations:

Regularly Written:                                                               Code:

  Two-Dimensional Vector: X-Coord, Y-Coord                      Vec2(float x, float y)
Three-Dimensoinal Vector: X-Coord, Y-Coord, Z-Coord      Vec3(float x, float y, float z)

Components:

     - Magnitude
          For vector (A) below:


     - Direction
          tan(theta) = (y2 - y1) / (x2 - x1)
          For Vector (A) below:


Calculations:

     - Dot Product
          A (dot) B = Ax * Bx + Ay * By + Az * Bz

       
     - Cross Product
          a (cross/x) b = |a| * |b| * sin(theta) * n

       

Matrices
     "A table of data that represents the orientation, position and scale of an object"
          -

Rotation Matrices:

     It is easy to determine which axis the rotation will be performed around since it will be the only axis that is left as a one (meaning there will be no changes applied, and it remains the same while everything else rotates).


                       x              y          z





Orthogonal Matrix
     - A Matrix that consists solely of unit vectors.




MVP Matrix
     "A 4x4 matrix that consists of the Model, View, and Projection Matrices."

     - Model Matrix
           Holds the model's transformation values in regards to rotations, translations and scaling.








     - View Matrix
          Holds the orientation of the camera that it will be applied to. Sets which direction is up in the world, and in turn, the corresponding direction and right/left unit vectors.



     - Projection Matrix
          Calculates the values that make the corresponding positions in the table appear in the desired perspective view



Quaternions
     "A four dimensional vector in space that has three operations: addition, scalar multiplication, and quaternion multiplication. They are special because the multiplication of two quaternions in non-communative - meaning that the order in which they are multiplied will change the end result of the multiplication."

Representation:

     q = < 3D Vector, Float>  /  <Vec3, float>
     q = <x, y, z, w>


Tangent Space/Homogeneous Matrix 
     "Referencing N-space in N+1 space. For example, representing something in two-dimensional space of coordinates (x, y) as a three-dimensional object in space of coordinates (x, y, w)"

This is done through the increase of every dimension of all primitives:

1.
- Making Points into Lines
- Making Lines into Planes
- Making Planes into Cubes/Cuboids (3D -> 4D)

2. (Example for 2D-3D)
Projecting all points through a plane at position z = 1.
All lines will intersect at one point (called the "projective line" in 3D - or the vanishing point)

3.
These resulting lines from 2D point space give us the projected 3D shape of the objects that the points created in perspective.


Image of Tangent Space Representation (Tangent of a point on an object):





References

wikipedia.com (for a couple of definitions/images) google.ca/images (everything counts, right? :P)
http://www.mathsisfun.com/algebra/vectors-dot-product.html
http://www.mathsisfun.com/algebra/vectors-cross-product.html
http://www.dummies.com/how-to/content/calculating-magnitude-with-vectors.html
http://hotmath.com/hotmath_help/topics/magnitude-and-direction-of-vectors.html

Starting Your Engines. It's time for blog numero uno!

The year began with a review of terms that we need to know and so will I. The most important things that I now know are:

Heap
- Essentially this is a specialized tree-based structure that is not ordered in any particular manner. The highest item (or lowest, depending on how you look at it) has first priority in regards to the tree's accessibility and is commonly referred to as the root of the tree - or root node in more common coding terms.
Stack
- Works much like a pile of plates. A stack can see what is on the top of the pile, and can remove the top object or place an object on the top, but cannot access any items in the middle or on the bottom until the ones above it have been removed.

A pointer

Base *b;

Can be set as:

Base *b = new Der();  **Where Der() is the class the Base is derived from.

BUT

A pointer

Der *b;

Can NOT be set as:

Der *b = new Base();

That was something I already had a good idea about, but having the information solidified in my mind by a professor of mine was a nice confirmation to have.

Smart Pointers
- Unlike raw pointers that invalidate other pointers when they are assigned to the same data, and then delete that data, smart pointers keep track of the number of pointers that are pointing to the same data. This helps us to keep track of whether or not we can delete the information being pointed to without ramifications, and if one of the pointers for a specific piece of data wants to delete the data it is pointing to, that pointer itself is removed, the data remains because other pointers are pointing to it, and the other pointers remain unaffected and continue on as if nothing happened.
-The only downside, and it's a very small one, is that smart pointers have to keep track of a counter of how many pointers there are that point to the same data. This harms performance, but the effect is VERY minuscule.

Something that I learned that I needed to 'facepalm' over due to having made this mistake many times in previous years, is that a declaration of "using namespace <namespacenamehere>" should never be used inside of a header (or .h) file. I had no idea that this was such a poor practice or structure for a program and have learned not to do so very quickly.

Entity Component Systems

Scene Graphs vs Tables/Containers of Data

The problem with scene graphs is that they are too easy to use, and are not optimal for machine translation (ie inefficient/slow). Being too easy to use is a downside due to our human understandings and perceptions of this concept being so incredibly different than that of a computer's.

Scene graphs are essentially a type of tree that looks like this:

http://archive.gamedev.net/images.gamedev.net/features/programming/scenegraph/image001.jpg

This is a very basic idea, where at the center of a galaxy/solar system there would be a star. That start would be linked with planets through a rotational value of some sort that would make the planets spin around the star. Connected to those planets might be a moon or two, also connected through rotational values. This is how the human mind perceives a solar system setup whereas a computer would much rather have that information organized in a simple list because all it needs is raw data, instructions on how that data should be organized, and the means to do so. If the data is already pre-organized in a way that the computer is set up to recognize and it is fed to the computer in that way, the efficiency of that program increases drastically, and that is optimal for all code.

The Key Model

Essentially the key model is a way of looking at an entity component system and how all of it's parts fit together to perform the actions they are made to perform.

A blank key shaft is what we would consider an "entity" or object. That is all it is, and it can't be used for anything until is has components that it can insert into a system for use.

Components that are added to an entity in relation to game development are things such as adding health, a position, a velocity, and a sprite to a player entity.

A system is a set of calculations or instructions that when given components to use in their specified instruction sets, will return new values to those components. An example would be taking the previous player entity's position and velocity, using them in a movement system that would enter them in a calculation to make the player change locations in the world, and return those components their new values that would result in the player having a new position and a new velocity.



Small/Short Tidbits that are very helpful:

Pointers = Low Level Programming = FAST (ie use pointers often! but well)

Professor Khattak loves to drill points into our brains, which is good because repetition helps the mind remember better than anything.

Avoiding the "Virtual" keyword, inheritance (because it leads to doubly linked/included items and that causes way too many problems to want to deal with), and making classes extensible (small more organized classes that work together for bigger pictures are more efficient and clean).

Refactoring -> remaking code to do the same thing but BETTER (preferably :P)

I also learned that professor Khattak started by referencing an engine I didn't even know existed, and that doesn't surprise me, but I found it interesting and so I plan on doing the same.

I hope you learned something from this, or that you at least found something you didn't know, OR it was just a nice refresh.

Thanks for reading,

Brayden M.