Around 1 year ago, I spent a lot of time working on a basic OpenGL physic engine. This was my first experience with OpenGL and I’ve learned a lot from it. The project was coded using Visual Studio 2012(C++) and Freeglut(OpenGL). The only external library used is for rendering text. All the physic has been coded by myself and all models/structure are procedurally created at run-time. This project isn’t updated anymore and still have bugs in its current state. The goal of this project was to learn OpenGL and prototype an engine.
- AABB collision detection for all boxes
- Adjustable gravity
- Interaction with moving platforms(Horizontal and Vertical)
- Ability to shoot/drop boxes of different size/speed
- Freeze the time, move around and start the time back to have a different point of view on something.
I figured video-editing would be a good skill to learn if I want to make trailers for game or video tutorial and gave it a shot with this project. Here is a video of my OpenGL engine:
*Note : This video was my first real experience with video-editing. Video quality should increases in the following videos.
To be implemented in next version
I’ve learned a lot working on this project and on the other project I’ve worked on since then. Here is a list of things I would make like to implement in a new version of this engine.
- I would like to use a Test Driven Development approach to make it easier to maintain/scale the project. I’m considering using the Google C++ Testing Framework.
- Use an entity/component system to have a better separation of the data and logic of an object. I would be interested in using something like Artemis that already has 2 C++ port.
- Implement or Find a library to use Quaternion instead of Euler angles to avoid any Gimbal Locking issues. Quaternion also easily allow smooth rotation between any starting/ending orientation by using Slerp. Quaternion workflow is really nice to use once you get the hang of it.
- Change my integration method from Euler to a more precise integrator like Runge-Kutta4. This article from GafferOnGames(I would recommend reading all post from this blog to anyone interested in game development) explain why Euler is an imprecise integrator and is a bad solution if you want to have a realist simulation.
- Evaluate the best approach for Timestep management. The project currently use a completely variable time step that could lead to unwanted behavior in certain cases. Again, This Article from GafferOnGames is a really good resource for this question.
- Use a more robust approach to collision detection and response to the collision. Use a vectorial approach that is completely independent from the gravity used. Gravity should become a vector to allow intensity as well as direction changes at runtime.
- Evaluate the utilization of a bool for object that are grounded on something else for physic evaluation. It seems this would make some platform movement much easier.
- Use a sleeping mechanism for objects that are not moving. This would greatly reduce the collision calculation.
- When testing collision, use rough estimates to eliminate groups of object that are sure to not collide together, or far one from another.
This project was really interesting and I’ve learned a lot from the experience. Coding everything from the beginning (except for using C++/OpenGL) is a different experience than using a featured rich engine like Unity3D.
Doing this gave me a better understanding of the way Triangles are rendered on the screen and the differents matrix used in graphical development, such as Model, Projection and Persepective matrics. This was also my first project featuring Procedural Generation and it got me really interested. I’ll try to push this aspect farther in my current game in development, Dungeon Grind.
Hope you enjoyed looking at the video and reading my thoughts on this project. I’ll make sure to post it on my blog if I make a second version of this OpenGL Physics Engine.