Approximately this many:
No kidding!
Understanding the basic concepts of OpenGL
In my opinion, what makes OpenGL complicated to grasp is that you need to understand two different concepts simultaneously. When you read an OpenGL book, you are introduced to the OpenGL API. The OpenGL API is the linkage between your application and the GPU. You are also introduced (in later chapters) to OpenGL Shaders and to the OpenGL Shading Language. Shaders are small programs in the GPU that informs the GPU how to render.
In other words, not only do you need to know how to send data to the GPU. You also need to know how to write a program that a GPU can understand.
To help you with OpenGL, in this post, I provide answers to the most important OpenGL concepts that you need to understand.
I hope you find it useful.
What is OpenGL?
OpenGL is an API for drawing graphics. Its purpose is to transfer data from the CPU to the GPU.
How is data transferred to the GPU?
Data is transferred to the GPU with objects known as OpenGL Buffers.
What is a Buffer?
A buffer is a linear block of untyped data. Think of it as generic memory allocation.
Can a buffer store multidimensional data?
No. Data storage used for multidimensional data, such as images, are known as Textures.
What is a Vertex Attribute?
The input variable to a Vertex Shader.
What is a Vertex Shader?
The Vertex Shader is responsible for computing and passing forward the coordinates of a model to the Fragment shader.
How does the Vertex Shader receives data?
The mechanism for getting data in and out of a shader is to declare them as in or out storage qualifiers. When you declare a variable as in, it marks it as an input to the vertex shader. This sets the variable as an input to the graphics pipeline.
What is a Fragment Shader?
The basic operation of a fragment shader is to provide a color to each pixel. More specifically, the fragment shader takes the output from the rasterizer and computes the color of the pixel for each fragment.
What is the difference between Vertex Attribute vs. Uniform?
A Vertex Attribute can only be received by a Vertex Shader. A Uniform is data that can be received by any shader: Vertex, Tessellation, Geometry and Fragmet.
What is a Target?
A target is also known as Binding Point in OpenGL. A target determines the type of an object. Just like int or float determines the memory allocated for a variable in C++, a target determines the behavior of an object.
What is a Texture Object?
A Texture Object is an OpenGL object which contains texture data.
What is a sampler?
A Sampler represents a texture and sampling parameters in a shader.
What is a Sampler Object?
A sampler object stores the Wrapping and Filtering parameters that control a texture.
What is a Texture Unit?
A texture unit contains a Texture Object and a Sampler Object.
What is Texture Filtering?
It is the process of calculating color fragments from a stretched or shrunken texture map.
What is Magnification/Minification?
Stretching a texture is known as Magnification. Shrinking a texture is known as Minification.
How do you integrate a Vertex & Fragment Shader into your application?
Before your Vertex and Fragment shader programs can be integrated into your application, you must perform the following steps:
- Create one or more shader objects by using glCreateShader.
- Provide source code for these shaders by calling glShaderSource.
- Compile each of the shaders with glCompileShader.
- Create a program object by calling glCreateProgram.
- Attach the shader objects by calling glAttachShader.
- Link the program object by calling glLinkProgram.
- To use the program object as part of OpenGL’s current state call glUseProgram.
I hope these questions and answers were helpful.
Game character modeling for game engine developers
For the past week, I have been working on a demo for the game engine. I have not written a single line of code. Instead, I have been modeling game characters and game environments for the demo.
Contrary to what you may believe, game engine development requires some artistic skills. As someone who has been doing this for the past three years, I can say that game engine development is 75% coding, 25% game asset modeling.
I learned this fact the hard way. In the beginning, I bought game characters and tried to render them with my primitive engine. It didn't go so well and spent hours trying to figure out the problem. Against my will, I was forced to learn 3D modeling tools such as Blender. As I learned 3D modeling techniques, Computer Graphics concepts started making sense. As a result, I was able to improve the engine and know its limitations.
There are plenty of 3D modeling tutorials, videos, etc., online. Unfortunately, their target audience is game-artist students. As an engineer, it was a bit hard to follow. The other issue that I encountered is that these tutorials don't focus on low-polygon characters. Instead, they focus on high-polygon characters which mobile devices can't handle. This is a problem since my game engine targets mobile devices.
Recently I found three amazing low-polygon modeling tutorials written by Karan Shah.
Karan teaches you, step by step, how to model a low-polygon character. (I'm currently using this modeling techniques in the second engine demo.)
Modeling a low polygon character
Karan also shows you how to unwrap a character and add texture to it.
Unwrapping a low polygon character
Finally, my favorite tutorial is where he shows you how to model a low-polygon game scene. I ended up using his techniques in the first engine demo.
Modeling a low polygon scene
I hope these tutorials helps you as much as they helped me.
I wish I had found these tutorials when I started developing the engine.
Understanding Git commands visually
In the next six months, I'm planning to release the engine as an Open Source project.
Am I excited? Hell Yeah!
Am I prepared? No! The game engine will be my first open source project.
There are so many things I don't know about managing an open source project. Technically, I think I will do OK. Management-wise, I have no idea. I ended up buying this book from Amazon: Producing Open Source Software. Hopefully, it helps.
To manage an Open Source project (I believe) you need to have strong Git skills. I don't feel that I do. Of course, I know the familiar commands like add, commit, checkout, merge. But I don't know it good enough to manage an open source project.
The best way I learn is through visuals and hands-on. Luckily, I found two fantastic sites that teach Git visually and interactively. I have played around with their tutorials for about three days, and they have helped a lot.
The first site is by Wei Wang. The site has an interactive terminal, and after typing a Git command, you get to see Git in action.
The second site is LearnGitBranching. It is very similar to Wei Wang site, but it has more tutorials, more Git commands, and nicer visuals.
If you are a visual learner, you need to check out these sites. I believe you will learn a lot from these sites.
Try to design user-friendly APIs
One of the goals of an API developer is to make the API user-friendly. Your public API should be compact and intuitive. It should provide enough information to start development without the need to read the whole manual.
The game engine is the first API that I have ever developed. As I used the API in several demos, I realized that the API's naming convention was not user-friendly. It didn't inform the user when and where to use certain functions. For example, the Collision Response of a character depends on its inertia tensor, center of mass, etc. These properties should be set in the initialization routine. So instead of using the "set" keyword as shown below:
void setInertiaTensor();
void setCenterOfMass();
I hint the user to use these functions in the initialization routine by prefixing it with the "init" keyword:
void initInertiaTensor();
void initCenterOfMass();
Also, the API did not indicate whether a function enables a behavior or property. For example, Collision Detection is a behavior that can be enabled, paused and resumed. In contrast, a character's name is a property that is set to a value. So instead of using the keywords "set" and "disable" as shown below:
void setCollision();
void disableCollision();
I hint the user that the function enables, pauses or resumes a characters' behavior. I also append the suffix "Behavior" to each function as shown below:
void enableCollsionBehavior();
void pauseCollisionBehavior();
void resumeCollisionBehavior();
In contrast, all properties use the prefix "set".
void setModelName();
A good API design is akin to a good GUI design. It should be simple enough for anyone to start using it and hard enough for anyone to use it incorrectly. Do not discount the importance of a well designed API. It is as important as writing documentation and as your (app) source code itself.
So make an effort to review, simplify and improve your public API.