Day 78: 3D GJK

Today I finished my implementation of GJK, and now it works in 3D.
In the pictues there are 4 white objects and a textured sphere. The white objects are emitting light only if they are colliding with the textured sphere, so the big right cube is the only one who is not lighting the scene.
However a major problem is still there: collisions between  boxes and spheres are not correct, while box-box and sphere-sphere collisions are.
This is surprising, because I wrote the algorithm from scratch, while following a different source to check if I was not missing something...but even if the code is completly different, the problem remains...
I'm starting to think that the problem doesn't lie in the algorithm, but I'm also positive that the support functions I wrote are correct as well, so I'm not really sure on how to proceed.
Tomorrow I'll probably add a GenericConvexCollider, and see if it behave correctly.

Day 77: AABB collisions

Today I introduced a new kind of colliders, the Axis Aligned Bounding Boxes, which are just unoriented cubes, like the ones in the picture.

They have a little problem when the X or the Y values of the two colliders are identical, and I'll try and fix it as soon as I can, but except for that minor problem they work perfectly.

But, unexpectedly, the collision between AABB and spheres is not what I expected...it is a little off, basically it happens when the two colliders are still a little distant, like the big cube and the sphere in the picture ...I'm not sure if this is normal and GJK don't support collisions between eterogeneous colliders, but I think that it should, and so maybe something is wrong in my implementation

Day 76: GJK

In the last few days I started studying how to implement collisions.
This is actually way more difficult and time consuming than I imagined, especially considering that the colliders can also be convex objects, and not just spheres or cubes.

So I started studying collisions, which is the basis for any physics engine.

Instead of implementing everything with simple colliders, I decided to go directly to the algorithm for convex colliders, which is the GJK.

It is quite complex, especially in 3D, but it has a great advantage: it can check collisions between any kind of shape that can answer to the question: "Which is the farthest point I have in the given direction?"

So It is possible to check collisions between a mesh and an ellipse curve  for example.

Also, for convex meshes, it is faster than the SAT method.
In the picture I implemented it in just two dimension, and I used sphere colliders.

The three external spheres check collisions with the central one, and the left one is yellow because it is not colliding.

Tomorrow I'll add AABB colliders as well, and i'll try to make them collide between each other.

Extending the algorithm to 3D is pretty annoying and error prone, I expect it to  be hard, I'll try to do it soon

Day 75: Composite pattern

Today I wanted to add simple colliders to the GameObjects...However they would require a transform, and the GameObjects class already have transform informations...so does ligths, so I decided to do a big refactoring to create a system similar to the Unity one.
A GameObjects is the root object, and its behaviour is defined by its components, as in a slightly simplified composite pattern.
The refactoring took a lot of time, because lots of classes were dependent on lights or models information, while now they are dependent only on GameObjects.
Now each GameObject has 5 components: a Transform, a Model, and the three types of lights.
None of these, except the Transform, is mandatory. An object could choose to have it or not.
Directional lights are now multiple like point and spot lights, while before I could only have one.
In the picture there is an example of how the system is still working exacly like before.
I moved the boundaries of the physics to match the walls positions.
Hopefully the next screen of the engine will be exactly identical, but with real collisions with AABBs (Axis aligned bounding boxes).
The RigidBody class will be a component of the GameObject as well. If missing, the object will not interact with the physics simulation.

Day 74: Installer

Today I studied physics simulations because I need to better understand what I'm going to do, so I didn't actually wrote any code.
However I downloaded a plugin for Visual Studio called Visual Studio Installer, and with it I managed to create a working installer for the engine, because right now it was working only inside visual studio.
It was a bit problematic due to absolute and relative paths problems, but in the end I made it work.

Day 73: The limits of physics simulations

Today I experienced the hard way a problem about physics in a discrete time context.

Tweaking a few values of the drag formula I noticed that with certain values the ball was behaving unexpectedly. With other values its position was rapidly growing to infinite.
After quite a lot of time trying to understand what was wrong, I realized it was not fault of the formula, but of the fact that physics is processed only 60 times for second.

Let's say that a ball is travelling very fast inside water. The water applies a resistance force which is very high at the beginning, and gets softer with the ball losing speed.
If this happens in less than a frame, the force is calculated at the beginning, and it will be so high, that it will actually invert the speed of the ball, which is not the desired effect.
The force will be calculated again the next frame, but the damage will already be done.
The values of the speed were something like this (in m/s):

20 → -30 → 90 → -900 → 500000 → - INF → INF

These values shows that the drag force is so intense that it will actually invert the speed, and make it even more intense. This generates a sort of pong effect, and v will tend to infinite.
Thanks to these numbers I realized the problem, and actually there is not a real solution, except to avoid using "risky" values, or bring to 120 the fps of the physics simulation.
These methods don't solve the problem, but makes it less easy to happen.

Since I was stuck on this problem for quite some time, I just added a few things to the engine: lateral bouncing and a debug tail that changes color depending on how much time before the object passed from that point (as can be seen in the picture).

Day 72: Weight and Drag forces

Today I started working on physics.
This seems to be a very hard thing to implement efficiently, and I don't know if I will ever attempt to implement complex physics and collisions with irregular objects, so for now I'll start to implement the easier things, and gradually add new features.

Today I defined two classes, a WeightForce and a DragForce class.
These holds the important data to calculate the correspondent force (for example in WeightForce is stored a 3d acceleration and the mass of the object).
With these two classes I managed to implement a simple gravity system that uses a gravity weight force and an air drag force.

I also added a very useful debug tool: every 5 frames a red low-poly sphere is instanced in the position of the object.
This allows to follow the path of the object in a nice visual way (as you can see in the image).

Finally I added a few commands to the shell to make physics debugging easier: a pause method that leave the camera active, the automatic pause when shell is active, the command "\r" to restart the simulation, and so on.

Day 71: Reorganization

Today I finally decided to divide the headers, the souce files and the shaders in subfolders, because of their growing number.
Now everything is more organized, and in the process I also removed a couple of old classes I forgot to delete weeks ago because I didn't see them in the general disorder.

Day 70: Improvements to Shell and Log

Today I finished to fix a few bugs I had in the Log class.
Then I added a lot of commands to the shell, and they also helped me to add a few features to the engine.
For example I decided to make a slow motion command. So I added to the TimeManager a delta_time and a slow_motion_factor.
By tweaking the second value it is possible to make the game slower or faster, and I used the delta time to make movements fps-independent (which I had forgotten till today).
I also added a pause command to freeze everything except the shell, I added commands to handle music and sound effects and a few other stuff.

I also found a bad bug in  light directions:
I was using a lookat view matrix with vec3(0,1,0) as the up vector. For most situation this was fine, but I noticed that when lights were pointing upwards or downwards, the shadows were disappearing.
This is because having a forward and up vector in the same direction was generating some bad math error. So I replaced it with one of the vectors perpendicular to the forward one, and everything was solved.
The shell proved to be extremely useful to debug this problem, I was able to remove other lights, check immediatly if the shadows were properly activated and so on.

Day 69: Log console

Today I added a few commands to the shell, then I proceeded to implement a Log console, which is basically an output console on top of the shell.
I managed to make everything work, and I can also scroll up and down to see older output messages, and so on.
It is not perfect yet, but it does the job.
The shell can control the log as well, for example by changing it color, and with the tab key it is possible to enable or disable them.
In the picture I redirected the fps output I was printing on the windows prompt directly to the Log console, and it works perfectly.
Tomorrow I'll probably try to solve the little problems I have left behind.

Day 68: Control rendering with the shell

Today I added lots of commands to enable/disable the different rendering steps.
This was easy for the most part, but a few steps were actually not indepent.
For example I couldn't disable the shadows, because in the light pass the shadow information is read and processed. So I needed to do a few adjustments, for examples I added an uniform to the light shaders to disable shadow processing.
Another example of a problematic command was the disabling of HUD, because the shell is actually part of the gui.

In the picture are show a few commands to disable, in this order, hud sprites (but not texts), directional shadows, spot lights and skybox.
Using \x instead of \nox enables the rendering steps back again.

Probably the next thing I'm gonna do is an output shell, on top of the input shell.
This will be useful to output messages directly there instead of the windows terminal.
I will also probably add a function to pause the game (except the shell).

Day 67: Shell

Today I implemented a working shell to input commands to the game.
It was surprisingly easy, free of errors and bugs, and a very satisfying job.

First I managed to create the background of the shell, then I added 15 lines of text on it, and I spent a few hours adding multiple features:

- Reading text instead of button signals thanks to a SDL 2.0 feature
- Tab to show/hide the shell
- Enter to scroll the lines like in a standard bash
- Read commands when '\' is read, and stop reading when ' ' is read.
- Read parameters after a command, it works for both string and int parameters
- Different error messages (if argument is missing or is different, the message is not the same)
- Multiple commands on the same line

Except the last point which was a bit tricky, everything went pretty smootly and I don't think there are bugs until now.

In the picture there are a few examples of commands I implemented:

-\hide: same thing as the tab key, really not that useful
-\shellcolor: changes the color of the shell text, accept 3 ints
-\echo: output the string argument as is

In the next days I'll add other features, and add commands to actually control the game.

Day 66: Fonts

Today I finally made fonts work, and all the problems were due to bad conversions between different units of measure.
In the end I managed to make them work, but  I was not satisfied, I wanted to make them easy to adapt to the screen.
So I added an anchor system like the one for sprites, and I also made so that the text is correctly aligned to the border it is anchored to...much like the "align text" in Word.
I also added a new parameter called Depth to both the sprites and the text. It allows to decide in which "depth plane" the image will be, so that it is possible to decide what will be rendered in front of the other stuff.
It supports alpha, but only 0% or 100% alpha, which means that 10 overlapping sprites with 10% alpha and different colors will NOT blend as expected, but a text in front of a sprite, or vice versa, will be nicely blend.

Edit:
In the evening I managed to precalculate and preallocate all the memory used by the text glyphs, so now it avoids multiple allocations.
Faster and does not require to free memory, which is always good, it just needs to resize the memory every frame.

Day 65: Fonts and problems

Today I spent a lot of times trying to read .ttf fonts and use them.
The idea is read them inside a opengl texture, then draw them by sampling the correct uv-range from the texture.
I've had a lot of problems, and I wasn't able to finish the work, I'll continue tomorrow.

Day 64: Perfected GUI

Today was another very positive day, and I made a lot of improvements to the engine.

I started by refactoring the the PointLight, DirectionalLight, PointLight, GameObject and Sprite.
They all had in common the lack of a global list to track their presence.
After the refactoring you can just create an object, and the engine will know it's there and will be able to render it and so on.

I also moved the batches logic to the deferred renderer class, so that now in the main game class everything is clean and details independent.

After that I proceeded to improve the GUI I've written yesterday.

First I've written an anchoring system, which is something that is often missing in game engines and I find very useful.
As you can see from the image, I just placed 4 sprites at the coordinates (0,0), (0,1), (1,0) and (1,1), and by changing the anchoring point they are easily placed inside the screen.

Then I solved the ratio problem by dividing ratio and size.
The sprite has a default ratio (obtained from the image itself), and setting the size to, for example, (100,100), will make the image 100 times bigger, but with respect for the original ratio.
It is possible to set the ration to 1, and the image will be exactly 100x100

Day 63: GUI

Today I've written an enormous amount of code, mainly because somehow I didn't stumble in any stupid problem.
I started by creating a Sprite class, with the correct info to handle a 2D image.
Then I wrote a 2D batch to optimize the drawing of sprites (like I did for 3D stuff).
After that I proceeded to write a couple of shaders to render the 2D image on screen, and I added a method to my deferred rendered to draw with those shaders everything inside the batch.
I had a few troubles in blending the HUD on top of the 3D scene because of a pretty bad bug I never found till today, and I fixed that as well.
Once I got that working I needed to tweak a few parameters, implement the system to generate a 2D model matrix, fix a few other bugs, replaced the PNGLoading library, and now the system is working.
The coordinate system is quite good, but the scaling system is not, tomorrow I'll make it ratio-independent.
I also need to add an automatic system to add automatically to the batches the objects in the scene. Right now it is manually done, and it feels very unnecessary.
I'll probably refactor that as well.

Day 62: 3D graphic recap

Today I will officially stop to work on 3D graphic, for the moment at least .
I'll soon start to implement the (2D) GUI of the engine, because I decided I want to be able to draw a HUD, write output on screen, maybe even implement a custom console.
Before that I wanted to give a proper conclusion to the work I've done till today, so I built a little, nice environnement to replace the random stuff I had on screen.
It was useful to test again the lights and of course I want something nice rendered on screen if I'm not gonna change it for quite some time.
I also added copy constructor for lights in the process

Since this is the end of this part of the engine, I'll recap the main features I implemented, which are visible in the image for the most part:

*At the four corners there are 4 point lights, and each one of them has a diffuse component, and a very high specular component. They also cast shadows.

*The four spheres around the lights are flat color (non lit) and they don't influence shadow casting. It needed a few extra work, but it allowed me to create bulb lights

*At the top there is a spotlight, with the same properties of the point ligths (shadows, specular and diffuse color etc)

*On top there is a sphere that casts the directional light shadow

*In the background there is the skybox

*Everything is based on deferred rendering, which is nice for performances but made everything a little more difficult, and prevented me from using transparency and anti-aliasing, which I would really like to have.

Day 61: Problems with buttons mapping

Today I had little times, I just tried a few things and I noticed a problem with the button mapping of the controller...but I think the problem is SDL.
The keys are correctly read by windows, and the joystick is correctly read by games and stuff, but in SDL the enum values for each button are somehow swapped...if that is the prblem there is little I can do, I have to remap manually each SDL code to its true value...very, very annoying

Day 60: Copy constructors

Today I wanted to build something with the engine, like a little house, just to show the potentiality of the system...the big problem I faced, is that for each object I needed to set everything up from scratch. For every block on screen i had to write a lot of code, and the only difference was the position ad maybe the size...so I decided to allow the engine to copy objects, so that  i can make a copy and modify just the different parts.
It required the use of copy constructors, which do this process allowing to also duplicate the eventual pointed values inside the copied object.
The system is fine, and i can copy model and game objects. I think i'll extend it to light also, and maybe I'll write a common interface called iCopyable, but there are a few tricky things to handle, so I'll leave it for last.
In the picture I just imported an horrible model to test everything on a more complex environnement, and indeed the shadows were a little messy and i needed to change a few settings of the bias.

Day 59: Game Controller

Today I decided to configure the engine to work with a game controller.
Thankfully my ps4 controller is very easy to configure on a PC compared to the old ps3 dualshock, so I started very easily.
I had to configure SDL to read data from the controller, and then I needed to manually program a lot of things: button mapping, dead zones of the analogs, mapping from analog valus to the range [-1;1] and so on.
In the end I managed to give to the controller all the feature already used by the mouse: control the camera over the screen with rotations and movement, issue commands with buttons and so on.
I had litterally no problems today, everything went smooth and the system is perfect for now.
I will probably add in the future a few features, like a buffer to stabilize the joystick movement (sampling the last three values to avoid imprecise movements), but for now i'm happy with it.

Day 58: Huge refactoring

Today I made a substanctial refactoring.
I started by moving the MainGame class to the game, and I left to it just the base stuff a game programmer should implement, moving the rest to the super class.

I also moved all the glsl program initialization to the deferred renderer, because unitl now it was handled by lights, main game and deferred renderer, making the situation pretty messy.
Everything seems to work exactly like before.
Probably tomorrow or in the next days I'll add a few classes to the Game project and make something with the engine, just for fun and to test that everything is fine.