Hey guys!

I'm new here and I recently started developing my own rendering engine. It's open source, based on OpenGL/DirectX and C++.
The full source code is hosted on github:
https://github.com/fleissna/flyEngine

I would appreciate if people with experience in game development / engine desgin could take a look at my source code. I'm looking for honest, constructive criticism on how to improve the engine.
I'm currently writing my master's thesis in computer science and in the recent year I've gone through all the basics about graphics programming, learned DirectX and OpenGL, read some articles on Nvidia GPU Gems, read books and integrated some of this stuff step by step into the engine.

I know about the basics, but I feel like there is some missing link that I didn't get yet to merge all those little pieces together.

Features I have so far:
- Dynamic shader generation based on material properties
- Dynamic sorting of meshes to be renderd based on shader and material
- Rendering large amounts of static meshes
- Hierarchical culling (detail + view frustum)
- Limited support for dynamic (i.e. moving) meshes
- Normal, Parallax and Relief Mapping implementations
- Wind animations based on vertex displacement
- A very basic integration of the Bullet physics engine
- Procedural Grass generation
- Some post processing effects (Depth of Field, Light Volumes, Screen Space Reflections, God Rays)
- Caching mechanisms for textures, shaders, materials and meshes

Features I would like to have:
- Global illumination methods
- Scalable physics
- Occlusion culling
- A nice procedural terrain generator
- Scripting
- Level Editing
- Sound system
- Optimization techniques

Books I have so far:
- Real-Time Rendering Third Edition
- 3D Game Programming with DirectX 11
- Vulkan Cookbook (not started yet)

I hope you guys can take a look at my source code and if you're really motivated, feel free to contribute :-)
There are some videos on youtube that demonstrate some of the features:
Procedural grass on the GPU
Procedural Terrain Engine
Quadtree detail and view frustum culling

The long term goal is to turn this into a commercial game engine. I'm aware that this is a very ambitious goal, but I'm sure it's possible if you work hard for it.

Bye,

Phil

10 minutes ago, turanszkij said:

Nice one! 

I don't have time to review, but feature list seems nice, also nice readme. Couple of things that I noticed:

• I don't like that there are external dependencies to look out for, for anyone who would want to build it.
• In the guidelines you mention "watch out for framerate when testing changes" - this is not really good advice, one should really look for frame timing instead
• Avoid dynamic memory alloc/open files in render loop when possible - this is absolutely necessary to keep in mind all times, not just "when possible"

Thanks, I will definitely follow your advice, and your'e absolutely right when you say that one should measure frame times instead of fps.
I did checkout your engine as well some time ago, it's awesome.
Can you recommend any resources about global illumination techniques for real time rendering?

Hi,

I only went through it really quick but I noticed the following:

- You are using GL types in your common interfaces
- You are mixing system layer and engine layer concepts into a single layer, this greatly reduces the portability and reusability of your code: 
  - System layer: swapchain,shaders,textures,buffers etc.
  - Engine layer: entities, transforms,lights,camera,image effects,materials etc

I recommend creating a UML design for your engine

Most engines I have worked with roughly used the following design:

Core: IO,math,memory,threads,containers etc
Graphics: swapchain,shaders,textures,buffers etc.
Framework: wrappers for UI,sound, physics,savegames,loading etc.
Engine: entities, transforms,lights,camera,image effects,materials etc
Game: game logic

Also notice that anything platform related uses macros so they do not get compiled if they are not used or present on the platform

Good luck!

Richard

I've made a quick checkup of your code and saw that you simply threw some dynamic libaries together with some kind of glue layer between them. This may be possible to call it "Custom Engine" but you need to keep an eye on your dependency list. You didn't write something about what version of the dependency you took so one building it in 5 years might get trouble with changed third-party API's.

Some critics I have come from the developer side of view. You splitted your code into header and implementation files as most old-school programmers do but as mentioned in this topic you will get a really complicated project structure if you get larger and it is anyoing for your developers.

A second point is documentation. Having some documentation files is good but more worth are comments on functions directly in your code. I always tag my public interface with a short 3 line comment what the function does and what there is to take attention to if existing. This really helps working with the interface and will be also shown e.g. in Visual Studio (2012 and above) as intellisence comment to your function

First of all, thanks for your feedback!

@R-type: I do NOT use GL types in my common interfaces. I use GLM at certain locations in the code which is a common math library that is not limited to just OpenGL, I use it for DirectX as well. I also wrote my own little math library and defined operators that allow to convert between GLM and my own Vector and Matrix types.

@Shaarigan@turanszkij: The dependency stuff is done this way on purpose, because I do not want my repository being convoluted with third party libraries. The best solution is probably to include them via git submodules.

Regarding documentation: I also like to put comments above methods that give a short description about how to use them. Then use tools like doxygen to generate the documentation automatically.

One more thing to note regarding heap allocations: It's not only important to avoid them when rendering, but also ACCESSING heap-allocated memory can be a huge problem.

In my engine I have a high-level component called StaticMeshRenderable, and the renderer creates a low-level component wrapper from it that holds pointers to shader and material. For hierarchial view frustum culling, the low-level component accesses the (heap allocated) hight-level component to return the bounding box used for visibility tests. Whereas in the current implementation, the low-level component copies the necessary data in the constructor, so it doesn't have to access the high-level one again during visibility tests and rendering.

With this simple change, frustum culling went from ~8 ms to ~5 ms, culling ~4 000 000 meshes, where ~20 000 remain after culling. So memory fragmentation is something to look out for when designing a game engine / renderer, even on a PC.