Character movement harder than it seems
Friday, 15-Jan-16 17:54:00 UTC, author: Ylon Schaeffer

These weeks I've been busy building the character movement part into the engine and it is much harder than you might be used too.

Playing and controlling characters in games is essential for gameplay, players need to feel in control over their character and not vice versa. Simply adding a body into the physics engine and moving it around will give you poor (direct) control over the character. Think of games like Mario, the player has direct control over the character, everything that goes wrong is the player's doing, leading to players only getting better instead of cursing and raging at the game.

This requires a so called "Kinematic Character" which in simple words means everything (physics and movement related) will be controlled by a dedicated script instead of the physics engine. Things like moving the character away when a giant ball rolls against him must be programmed specific, this way we can make the characters flat or fall over so the ball will roll over him or simply move the character aside. This is at the same time also the downside of the kinematic controller, you need to program it all yourself.

I've started with Bullet's own Kinematic Character example code, which was quite nice to start understanding the basics of moving a character, making it move through a world stepping up and down stairs and enabling a maximum slope/angle the character could walk up. I've refactored this whole script into the engine, removing parts so I could use it in a wider variety, like using it for flying objects etc. Example below:

The result was almost good, but not good enough, sadly. So today I started with designing the kinematic character's behaviour myself with feedback of Alex, it brings quite some interesting insights and design choices of what makes a character behave like you expected it to do. To make it easier I illustrated the rules in an image:

This will be the task which I will be working on these days and when that is done we can finally start building the basics of the game! You'll be posted.

Tags: Character, Controller, Kinematic, Movement
Octree's a path to culling (plain, loose and very loose)
Saturday, 31-Oct-15 15:48:37 UTC, author: Ylon Schaeffer

These days I've been busy developing the culling system of the engine. It's working quite good, didn't even reach the 1 ms CPU cost per frame with this approach and it's not even optimized!

Plain Octree - The plain octree is a nice way to handle axis-aligned and axis-cut geometry, it devides each box into 8 more boxes — hence 'oct'tree — and will check which boxes are visible to the player. This approach will make sure big chunks of geometry will be culled which is not in our view frustum.

Loose Octree - The idea come from:, this approach will make sure the geometry inside a box will always be visible by expanding the box by half the containing object's size. I currently use this octree for dynamic objects, look at the video for all the popping boxes.

Very Loose Octree - I really liked the idea of the Loose Octree and continued on this idea. I made it more fit for static geometry, not only does the boxes expand they also contract to get an ideal fit for all the containing objects. This does take some more calculations to get right so it's less advised to move all the objects in this system. Look in the video at the houses their volume/bounding box to see it in action.

Tags: Octree, VeryLoose, Loose, Very, Plain, Video, Esteem, Engine
Animations and cutoff support in shadowing and a new rendering method
Sunday, 18-Oct-15 14:13:10 UTC, author: Ylon Schaeffer

Animations are working, aswell the shadows that are representing it, plus a little extra.

A few months back I've implemented the animations again, only this time in a component way. Animations can be loaded and added when you want and if you want, simply attach it to the desired entity which holds a model (who has bone information) and it automaticly applies the matrix calculations in the shaders. It did cost me quite some time rebuilding this system and still needs more improvement. In my first prototype it was only aimed on letting it work, now I need to take resuablity and the Esteem Engine's design in mind.

In the last week, next to my tasks for the Zelda inspired game, website, marketing and running the company I found some time continuing my engine. I've put animation support into the shadow shaders plus added cutoff support, which you can see in the upper image.

Alex Wijnbeek came to me with this awesome article: it is a new way of rendering next to forward rendering and deferred rendering, which combines the benefits of both, called: Light Indexed Rendering - he used the term deferred in there but I could not find anything deferred instead it was more like the opposite - . Deferred rendering (lighting) is known for rendering unlimited lights with low costs vs forward rendering and the benefit is: it only calculated lighting once per fragment on the screen which is also a downside of forward rendering. The downside of deferred rendering is the amount of memory usage - this approach only uses 1/3 of that - and how fast you'll hit the fillrate of the gpu's (especialy the older gpu's) which will make the engine run slow on older pc's if not running forward rendering.

The benefit of using only a forward renderer is; you can make different shaders/materials which interact different with lighting, achieving this with deferred lighting requires a huge lighting shader or extra data like a material texture per material. So this approach - which combines the oth ideas - is very interesting. It can be seperated in 3 passes:

  1. Render opaque objects depth only;
  2. Disable depth writing (depth testing only) and render light geometry, check if the fragments on the depth map are being hit and if so write the current light's index in the light index texture. (if transparency is required then write the light index if the geometry fragment depth is lower then the depth map's depth value);
  3. Render geometry using standard forward rendering - lighting is done using the light index out of the light index texture and do lighting calculations like normal.

It does has some downsides in comparison with deferred rendering, you cannot have infinite lights. It restricts the usage of - in his method - of using only 16 lights per fragment, this can be enlarged but I wouldn't recommend it. 16 lights per fragment is kind of too much already, most forward renderers only uses 4 per object (thats not even per fragment).

I'm gonna try this approach in my week off and see if my laptop - which is 5 years old - will run it smoothly, fingers crossed!

Tags: Animations, Shadow, Shadowing, Cutoff, Lighting, Light, Indexed, Rendering
Transparency implemented! PreProcessor and performance
05-07-2015 10:37:00, author: Ylon Schaeffer

Took me a couple of hours enabling my engine to render transparent objects, rearranging the csm shadow map creation and altering more things in the engine.

Rendering transparent objects is not ideal in a deferred renderer, so I had to setup the forward renderer.

The forward renderer was easy to setup, just render the objects in the correct order. The material system and all of the UBO's (which are be automaticly bind on shader creation), made this an easy setup. The big and slow parts were the shaders for forward rendering and the shadow calculations. I've decided to move the shadow calculations into a function in the lighting.glinc file (which is my include file for all the shader lighting operations), so that took some extra time.

This took a lot of time, first I had to combine the directional and other light calculations into 1, which were almost the same but with a few different steps in the calculations. Also a problem could arise in the near future, because we might not always use the CSM technique, this was an easy fix with the C PreProcessor which I wrote for my files (which also allows including other shaders).

This PreProcessor allows the following command: #pragma once, #define, #include, #ifdef, #ifndef, #if (with operators: ==, !=, <, <=, >, >=), #else, #endif, #switch, #case, #default, #endswitch. I've added some non default commands like the switch, this gives ideal advantages over the use of #ifdef, just use 1 #switch and test them with #case.

Rendering time was kind of high for my pc, I've been searching for the problems and found out I used a lot of texture2D() texture fetching, texture2D allows to use normalized texture coordinates and does filtering for you (like checking which mipmap to use, bilinear or trilinear filtering). I could replace this with texelFetch(), this function will only grab a pixel out of a texture and do nothing with it (some call it an: image when using the texture like this). texelFetch() gave a big performance improvement, instead of 4ms while up close to an object it stayed on a 1ms rendering time!

I've also added some checks into the shadow checking function, like checking if the light actualy reached the fragment pixel we try to enlight, it will not execute all of the heavy shadow calculations if it cannot reach it. Big improvements everywhere + the UBO's their reusablity in all these shaders and for uploading data makes them ideal for all these purposes.

Like previous post a: GPU timer is ideal to test out your code and finding the bottlenecks in your shaders.

Shadow Atlas, UBO's and GPU timing
01-07-2015 17:31:00, author: Ylon Schaeffer

Development is going steady, had to rework a bit of my rendering pipeline. I was reusing a single shadowmap for the lights, this approach gave me nice results, but I encountered issues with this approach.

The problem arised when I started development of the alpha/transparent render pass, deferred lighting is not an ideal option for rendering non-opaque objects (it is possible but it'll take a lot more memory on the gpu). I've chosen to render alpha/transparent objects with the oldschool forward rendering method, but I did not had any shadow data left when we'll actualy start rendering these objects. We only got the shadowmap of the last light which we used in the deferred rendering pass, but we need all of those shadowmaps as well in this pass.

I started searching for options and opened the pdf Playing with Real-Time Shadows_0.pdf once again, it revealed a common idea for textures: an atlas. A shadow atlas, 1 texture containing all of the shadowmaps we need. First I disliked the idea because I wanted high quality shadows!, after I saw how the Cryengine is storing their shadowmaps into the atlas I was convinced, an awesome idea plus an overall major performance increase with shadowmapping. The idea is simple; use more space of the atlas to store shadowmaps which are more present in the screen, this can take up to 1/4th of the shadowmap. On a 1024x1024 texture it will be 512x512 precision, good enough for me!

An additional performance boost will come from this, not only do we bind 1 texture and do we render smaller shadowmaps for distanced objects we are also able to blur the shadowmap in 1 pass. The previous approach was to create the shadowmap and blur it afterwards per light, this will take a lot more drawcalls and we will soon hit the fillrate.

For this approach I've setup the UBO's (Uniform Buffer Objects) to store the lights and shadowmap meta information. This gave me another big boost in performance, instead of sending light data when I was rendering a light, I'm sending all the light data at once (light data is next to eachother in memory). After I got this working I also created an UBO for camera information (position, forward, matrix, etc), not sending these values per shader change is also a big improvement.

And for all these changes I also created a timer for GPU draw time. I did know what the CPU rendering time was (<= 1ms) but that didn't mean rendering the frame was taking this long, I only knew how long the cpu was busy with his calculations and sending commands to the gpu (gpu is working async). For this reason I found out I could query the elapsed time it took for opengl/gpu to finish my commands, this revealed nice insight into fragment writing. When my screen is full of written pixels the draw time is going up (around 4ms), when I zoomed out and only a part of my screen was being written it was going down (1ms). A big advice to those who want to get the best performance!

Next stop will be the alpha/transparent rendering pass.

Spotlights and directional lights (CSM) implemented
30-03-2015 15:00:00, author: Ylon Schaeffer

Now development starts to speed up, adding new techniques such as spot and directional lights are done in no time. Setting up the correct FBO's and reusing shadow maps (factories!) are like a piece of cake.

As you can see the spotlight and directional lights are functioning with shadows!. Next stop will be building the logic/gameplay part of the engine, adding the component based world objects will make sure I can use and setup my engine in any way I'd like.

Model and rendering factories and deferred lighting/shadowing
29-03-2015 11:17:00, author: Ylon Schaeffer

It cost me a lot of time building all of the basic OpenGL types, like a FBO (Frame Buffer Object) is encapsulated into an object, which holds the id of the FBO and has methods to attach render buffers and textures. You can see these objects as the opengl object itself only it will manage itself and together with the rendering factory they make sure the objects are valid.

The Rendering part took me a little more time than I expected, because this engine is build to support both DirectX, OpenGL and any other render software that accepts meshes and materials/shaders. The answer in my case was templates, it helped me a lot to achieve a none casting way of sending the render list to all of my render techniques, the rendertechnique simply tells te compiler for what kind of object they will work.

Now I'm gonna setup CSM again, and continue to implement the basic functions like post processes and such.

The Esteem Proto Game Engine & Development started!
16-03-2015 11:34:00, author: Ylon Schaeffer

It has been a while since I posted on this blog. I've been busy designing the whole engine, which really took a lot of time. The Technical Design Document is done and ready to be used. After all of this designing my head could use a long break, until now!

The game engine finaly has gotten its own name: Esteem Proto, thanks to Thomas van der Berg who came with the name: "Esteem". Every first major version will get the suffix: Proto, which means: the first one. And every last version of this major version will get the suffix: Prime, which means: best one.

Also a big announcement to make: Production has started!. I'm hoping I'll be done in a few months which should be able next to my personal research in marketing.

Cascaded Shadow Mapping implemented!
23-11-2014 21:55:00, author: Ylon Schaeffer

As I said in the previous post; I would continue to work on the csm implementation of the engine. I divided all the tasks over 4 days of work (Design, Math, Matrices calculations and Deferred Rendering of the csm (shader)), And the results are nice:

I've chosen for a basic and robust way of calculating the cascades as you can see below (Every circle will take a certain cascade of the view frustum from which shadow maps will be made, this example will go to a far distance/plane of: 1000):

I've got this idea by the following article: With the following example given, you can see 4 examples of how the frusta/matrices can react. I've chosen for the lower ones (C and D) because that would give me the least amount of artifacts when looking around in my engine (pixels are still not round you know! :D)

It worked out very good and I'm very pleased with the result. I did a lot of head scratching while building this and opengl/GLSL wasn't always playing along as I'd like but the last efforts were done in no time.

Hope you all like it!