We shall not write tens of pages explaining how this math actually works, we shall do a visual presentation of it. All modern graphics hardware, game engines, DirectX, OpenGL already have an encoded matrix helper function. Once you understand what these are, you will simply use matrix functions in order to have the desired effect.

Note: all drawings use an X and Z scale, as we would look on the scene from up. 2d presentations added for the sake of simplicity.

The Matrix

After wasting a big part of the Amazon forests and a substantial amount of graphite (I believe, some coffee was also involved in the process), mathematicians came up with a simple, handy, yet genius formula for effectively enslaving all kinds of objects into simulated computer worlds. The purpose was to move objects around, rotate them, stretch, and still be able to do that very fast, even if the objects consists of ten, hundred thousand vertexes. The project was a big success, and the solution is shared for all humanity to benefit and enjoy. Behold! The 4×4 homogeneous matrix:

The Matrix 4x4 presentation

As you see, the matrix consist of 16 float point/real numbers. Every section of it serves a different purpose. Data filled into the corresponding fields creates a matrix that you may use on any object. Don’t worry, you don’t have to fill in data yourself. All the platforms have ways of creating matrices.

The point is, when you multiply a matrix with a 3d point in space the result is the vertex transformed by values of the matrix.

While explaining this, I will mention the identity matrix. It is filled with default data, so when you multiply vertexes with this matrix, nothing will happen. Still, this is important, because if you need a transform matrix, you should first create and identity matrix (or have one filled with identity values), and then scale, rotate and move it. It also depends what platform are you using: some automatically add the identity values, some not. Check your documentation.

The identity matrix looks like this:

The Identity Matrix

It may confuse you that the rotation part is diagonally filled with 1’s and other are zeros. The reason for this is that in the rotation part you feed in the directions of the 3 axises that will rotate your input accordingly: row one is the X axis, row two is the Y axis and row three is the Z axis. In the given identity matrix example, row one points to the positive X direction, row two to positive Y direction (up), and the third points in the direction we are looking at: these match the axes on your scene, so no rotation is applied. Other fields are zero, because we do not modify anything.

In Ogre 3d, a loaded object, or a created one, already receives the matrix of it’s parent, so you do not have to think about these a lot. If you are programming in DirectX or OpenGL, you need to handle the matrices for yourself. Ogre has a number of functions that will modify matrices for different purposes, more-less automatically. You may use the setPosition (translation), setOrientation (rotation) using quaternions and setScale (scale) to update Ogre’s internal matrix values. View and projection matrices are internally created by Ogre, and those you may completely forget about handling those – it does it for you.

World Matrix

When you create an object in your favorite 3d art creation programme, the object itself is in object space. If you created it on coordinates e.g. x=10, z=10 these numbers are put in the object’s world transformation matrix. The object itself is never moved. Now, if you rotate it clockwise for 30 degrees, that one – you guessed – will also be put in the object’s transformation matrix. I probably should not say that scaling is handled the same way. Before displaying the created object is multiplied with it’s transformation matrix and then presented.

To be more clear, let’s take a look to the next picture:

Object and World Transform/Space

This what I explained is VERY handy! Every transformation you do while creating the object, or later in your 3d engine, is in the world transformation matrix, and the object itself never moves. This is far better than moving/rotating/stretching every point of the object on the scene, specially if it has a lot of vertexes. Also, after a lot of operation on the object, as the precision of the float point values used in 3d math is not perfect, the object might (would) become distorted as errors are introduced in every operation you do. This never happens with the world transform matrix, as the object never moves actually. And, yes – there is no spoon. Only the Matrix.

In Ogre you may use the mentioned object/node/root modifications to influence scene objects, as the matrix is an internal structure – regarding the Ogre scene class.

View Matrix

The view matrix is also known as the camera matrix. It transforms the entire world space into camera space. Similarly, as the world matrix transform puts the object form object space to world space, the view matrix transforms the space so the view space’s right points in the X direction, it’s top points to the Y direction, and the look direction becomes the positive z axis (if it’s a left hand matrix).

I’ll add that the view matrix is actually the inverse of the camera matrix, because it transforms back the entire wold to it’s local coordinate system.

Now, you may think that with world and view transform matrix applied, you can already present your object on your screen, what is true, but there would be no perspective. The view matrix only transforms the objects to the camera’s space. What we additionally need is the:

Projection Matrix

The projection matrix is automatically handled by Ogre (yep, otherwise you create it on your own, but do not worry, refer to the platform documentation for creating a projection matrix in DirectX, OpenGL…). It is based on near and far view distance, angle of the view of the camera and your screen resolution proportion. When you create a camera, you just feed it with the data, and everything is a go:

View and Projection Matrix

On the left is our object in world and view space, in which case we have no perspective – all the objects would be projected to the screen in a parallel fashion. On the right side, we introduce the projection matrix, which takes care of our perspective: the closer the object, larger it becomes, and vice versa. The X and the Y (Y here not visible, for the sake of simplification) axis becomes the surface of the computer display, and the Z axis is used to modify the size of the object. The white lines are the left and the right side of the display, near clipping is the closest point and the far clipping is the furthest plane limiting our projection space.

Conclusion

In order to display an object in 3d, we concluded that we need to have three matrices: world, view and projection. Another handy thing is that we can multiply all these matrices only once and create a combined World-View-projection matrix. Now, we only have to operate the vertexes of the objects with this combined matrix, and we already have a position on the screen! Simple! Ogre can give you this combined matrix e.g. in a shader automatically, you only need to call it. Otherwise, it is all done internally, and you do not have to worry about it.

On other platforms, the matrix is produced by:

matrix4×4 World_View_Projection = World x View x Projection

It is important to keep that order of multiplication, otherwise it will get messy. In this case x means matrix multiply. Refer to your platform documentation for details about matrix operators.

For using vertex/geometry/pixel shaders one needs to understand the subject we presented here: even in Ogre inputs to your shader need to be tunneled further, as you actually manually do all multiplications in order to get the object projected on the screen. And that is what gives you all the power with computer graphics – you can customize/enhance it further! Heh, I guess, after all, knowledge is power.

Happy coding!

It presents basics of how light and surfaces are interacting, the simply presented math (the math is actually quite complex, but presented in “plain english” so anyone can understand) will shed a lot of light on the subject. It also contains functions used by popular shader languages so one can learn to use those too.

In the following series we shall go deeper and deeper into more complex structures of 3D lightning, shaders, optimizations, normal mapping, displacement mapping… and I shall  explain how you should think to achieve to programme your favorite graphics card (may it be NVidia or ATI, they both work just fine) and have the most out of it!

Examples and work is accompanied with NVidia’s Cg shader code, OGRE materials and meshes, so you can implement what you learned right on the spot!

So, let’s dig in!

How light affects objects

“At the beginning, there was darkness, so God (yeah, in this case it’s You) created light, and everything was good.”

I’m not much of a religious guy but in this case I think it’s a really appropriate quote to use.  Without light you can not see your world, and you embedded so much time in creation of those 3d objects. As for the simplest case, let us for now reduce everything to 2d and consider the next image:

Surface and light example

There is our basic plane (e.g. ground surface) and a light source just above it. The ground flat, and our light in this case is point based. What this means is that the light is coming out of a point in space and spreads it’s rays in every direction. Also known as omni light.

Equation of Light

In reality, light is bounced off the surface or absorbed. The steeper the angle, more is “eaten” by the object, thus getting darker. The light we see it actually reflected by the surfaces to our eyes. Direct angle -> more light, steep angle ->darkness. Simple.

How we actually calculate the amount of light in a given point is that we take the direction of where the light came from, and the normal of the surface. The amount of light recieved on the given spot will be the cosine of the angles between the normal and the light direction.

Light amount  = cos(angle between (Normal and Light Direction))

The good people designing graphics hardware gave us a helper so we do not have to manually calculate the angle and do a cosine, we only do a dot product:

Light amount  = dot(N, L)

where N is the normal of the surface, and L is the direction to the light. So, once you have the normal and the light direction, it’s a piece of cake to calculate the amount of light recieved at a given point on the surface.

Light Decay and Distance

In reality light spreads to infinite, but in computer graphics we do not want that because everything has to be calculated and it needs to be done optimally. The more lights you have on the scene the more time it takes for the GPU (Graphics Processor Unit, the BIG square chip on your graphics card with the LARGE heat sink) to calculate everything. Unless, we could approximate/optimize light.

In 3d computer simulations we use a model that has a final range of effect. Modern graphics engines, or some custom project someone might create, should contain effective optimization methods for calculating if a light effects an object. This is important. If we just kick in all the lights with an infinite range and all the geometry together we shall have a problem. We would have to calculate effect of every light, even if it’s effect is undetectable (minor, too small to effect the scene). Thus we introduce the “optimized” light source distance decay model:

Decay of light intesity in real and simulated worlds

The real life model has light influencing objects to infinity. The optimized square distance has an ending that is defined with the light source and the intermediate values are modified with math to simulate the square distance decay. The simplest model is the optimized linear falloff linearly decaying to the finite range. All these models are well known, and actually without the “optimized” word in front of them. I added it so you understand that we optimized the reality model to better fit our 3d graphics needs.

OGRE game engine has an automatic mode of calculating does a light reach a given object, so it is done for you, and you do not have to think about it. Of course, you need to feed OGRE with the range data, otherwise the light’s range is infinite by default.

Light Types

We already mentioned the point/omni light source. Other basic light types are:

• directional light – light source is at infinite distance, so we are having parallel light rays. E.g. a Sun. It’s very far, so we do not bother with calculating where it comes from, we only declare it as a direction from where it arrived.
• spot light – has a source point and a target point.  It defines where the light comes and where it goes. There are two subcategories here. The light can be parallel or perspective. The point is that it always spreads from source to target, and behind the source point there shall be no light.

You may ask, what’s the difference? Well, a directional light as all present on the scene, no matter where you go, and basically used as a “day light” simulation. On the other hand the spot lights are good for simulating localized effects like car lights, to bring light to your baseball field in the evening and such. Here is more visual example:

Basic Light Types

Summary

You may wonder why all this is important? Well, lights, scene and shaders  set up in a proper way will bring you rich and fast 3d graphics. It is basically easy to overload your graphics card. Of course it’s a form of art to bring users colorful, precise, rich and also fast 3d graphics.

The following articles in this series will bring you closer to 3d graphics and shaders, introducing gradually all the new things, so you don’t get overloaded.

Next part: Basics of Light in 3D Computer Graphics – Your First Cg Shader (coming soon)

These were taken back home and at the Canary Islands, where I lived the last 5 months.

Cheers!

On Wed April 15, we’re going to release — for a limited time — the first chapter of “Fastest WordPress Graphics.”

This first chapter dives into designing and creating a “favicon,” that little image that sits on your web browser tab, in the URL window, and gets listed out with your bookmark:

Now, the entire ebook is $17, but we’re releasing Chapter 1 for free. We want you to have first crack at the material, and we’re interested in getting your feedback on how we can do even better in the rest of the ebook.

Here’s some of what you’ll find:

• Why favicons are necessary components of a well-designed website.
• “Best practice” design strategies for extremely small graphics. What’s small is good, but small is harder.
• Common pitfalls incurred using automated web-based tools. You definitely want to avoid these time wasters!
• Specific techniques in Photoshop (with screenshots) for creating favicons really fast and really accurately.
• Links to every file and image shown in the ebook. (We’re giving you Photoshop project files… hardly anyone does that… it’s worth at least triple the price of the whole ebook just for those alone… if you could even get them from your artist!)

Fastest WordPress Graphics Using Photoshop:
7 Killer Tutorials for $17

Just what you need for getting your WordPress Graphics sorted out!

Get Yours Now!

>>>IMPORTANT: Make sure to read the Website In A Weekend article on favicons to learn how to add your completed favicon to your WordPress website.