d3d (Deferred 3D) - A 3D Engine Using SFML

[lolz123]

Hello all,

I originally wrote a 3D game engine with SDL + OpenGL + Bullet + Ogg + Vorbis + OpenAL + LUA. This original version had a lot of features, but was not very user-friendly. So I decided to re-write it, this time using SFML 

The new version is especially different in that all game logic can be executed in parallel: there is a thread pool (using C++11 threading) that runs game entities all at once. It double-buffers the game logic and has special buffer-shifting smart pointers to make working in such an engine relatively simple.

The aim is to use only the most modern C++ as well as only the most modern OpenGL. The engine never uses raw new/delete or primitive arrays and only uses OpenGL 4+ features.

Here is an example of voxel terrain (it can do overhangs) with massive amounts of grass rendering.



Here is the engine's real-time global illumination in action:



Finally, here is a link to the bitbucket repository:

https://bitbucket.org/CireNeikual/deferred3d-parallel-game-engine/

[eXpl0it3r]

Looks awesome!

Will be looking forward to see more of it.

[Nexus]

Looks really nice! Great to see bigger projects that build upon SFML for 3D!

Also, it seems like you have spent a lot of effort on the code! It looks mostly good, here are some random suggestions:

• Use auto x = std::make_shared<T>(...) to create shared pointers, it's more efficient.
  
• Avoid shared pointers where they're not really necessary, consider unique pointers instead
• Use std::unique_ptr in the place where you return raw pointers, such as the copyFactory() method
  
• Some static factory functions like rotateMatrixY sound as if they're non-static and modify the current object; it might be worthwhile to rename them. For other functions like interpolatedNoise3D that do modify the current object, it's exactly the opposite.
  
• I'd personally forward-declare unknown classes rather than prefixing them when being used (e.g. class Matrix3x3f in the function declaration).
  
• Binary operators such as + should be global functions for symmetry reasons, not member functions.
• You should reuse more code, e.g. Planef::distanceTo() could call Planef::signedDistanceTo(), and operators like + could call +=.
  
• It's unclear why you inline some functions and others not, even though they're of similar length. I'd personally put more function definitions into .cpp file, it decreases compile times and exposes fewer implementation details.
• Why are some parts of the library outside the namespace?
• friend ThreadPool; is not valid C++, there should be a class in between.
  
• Just noticed that the parameter const Vec3f translation is not a reference.
  
• Inherit privately from Uncopyable.
  
• Uncopyable should not be polymorphic; it introduces a VTable in every class that inherits it, although you'll hardly ever delete the classes through that base class, because of the last point.
  
• static enum is invalid C++. enums defined inside class definitions are always at class-level scope.
  
• If possible, you should avoid exposing OpenGL in the headers (just like SFML). Maybe this requires to use unsigned int instead of GLuint in some places.

[G.]

Do you have a devblog?

[lolz123]

@ Nexus: Thank you very much for the tips! I was hoping that you would come by and help me straighten it out 

@ G.: Unfortunately not. I should probably make one 

[Grimshaw]

Man you just keep bringing awesome stuff to the community! Probably one of the best contributors in the whole community.

Thanks!

[Nexus]

Ah, I first didn't realize you were the creator of Let There Be Light/GLLight2D and all the AI-related simulations/games (NEAT Visualizer, NNBrain, Alife, Hero Must Die). I agree with Grimshaw, your contributions are indeed amazing!

[eXpl0it3r]

• Inherit privately from Uncopyable.
  
• Uncopyable should not be polymorphic; it introduces a VTable in every class that inherits it, although you'll hardly ever delete the classes through that base class, because of the last point.
  

Is that even needed with C++11? Shouldn't one just use = delete instead or is that more of a design choice?

[DJuego]

Man you just keep bringing awesome stuff to the community! Probably one of the best contributors in the whole community.

Ah, I first didn't realize you were the creator of Let There Be Light/GLLight2D and all the AI-related simulations/games (NEAT Visualizer, NNBrain, Alife, Hero Must Die). I agree with Grimshaw, your contributions are indeed amazing!

True!. A fantastic contributor with -inspired contributions very inspiring-.  A pioneer in exotic domains for SFML

I only am sorry (selfishly) that he lose interest/abandon so quickly his projects. . Let's hope that he decides to found a project with mileage. And so, he will enter in the club of Nexus (Thor), SFGUI (Tank+binary), Ceylo(sfeMovie)... or Laurent (SFML)!

DJuego

[Lee R]

Looks like you have a potential deadlock in your thread pool implementation.

mutex mut_worker;
mutex mut_pool;

thread1:
ThreadPool::destroy() {
    std::lock_guard<std::mutex> lock(mut_pool);
    // mut_pool is now locked.

thread2:
ThreadPool::WorkerThread::run(...) {
    std::unique_lock<std::mutex> lock(mut_worker);
    _conditionVariable.wait(lock, ...);
    // mut_worker is now locked.
    _pPool->onWorkerAvailable(...); // takes lock on mut_pool.
    // thread2 is now blocked until thread1 unlocks mut_pool.

thread1:
    std::lock_guard<std::mutex> lock(mut_worker);
    // thread1 is now blocked until thread2 unlocks mut_worker.
 

At this point, there is a deadlock; neither thread can make progress.

I've only recently started seriously looking into multithreading so it's quite possible that I've misunderstood something, though.

[lolz123]

Cascaded shadow maps!

[Grimshaw]

Hey lolz, can you please elaborate on what kind of GI you had? The technique you used, efficiency?

Also, can you elaborate a bit more on your process of rendering that grass?

[lolz123]

Sure!

I sort of made up my own global illumination technique (I like to think I did anyways  ), it is based on path tracing.
I compile the scene into a KD-tree, and then convert that tree into a OpenGL texture buffer object (TBO) so I can read it in a shader. I then path trace at a low resolution, and then blur the results with a special blur that keeps edge details intact.

Performance is not bad, I get 60fps on that simple scene, but I haven't gotten it to work at all (like, nothing shows up) on large scenes for some reason. I think my KD-tree is broken somehow  .

The grass isn't too special really  basically I just generate it using the voxel data, and then group the grass into chunks and compile it into a VBO. The vertex shader animates it to sway a bit.

[Grimshaw]

http://3d.benjamin-thaut.de/?p=16

Have you looked at that before? I am really leaning towards implementing that GI system in my engine. Fully working source code included, there are papers for both the original technique and the crytek improvements. The results seem to be really pleasant and are more than proven since CryEngine has GI since version 2.

What do you think? Does it seem viable?

[lolz123]

Yeah, I have read papers on their technique before. From what I gather, it is basically like doing Minecraft lighting (a flooding algorithm).

Cryengine didn't *really* have global illumination until 3 AFAIK, they only had some screen space effects.
The technique seems good, not as accurate as the raytraced version though. Cryengine 3 in its entirety, however, is a total mess from what I have seen  Unreal Engine 4 blows it out of the water in my opinion, especially code quality-wise. Cryengine 3 was clearly not made with indie development in mind.

Unreal Engine 4 uses voxel cone tracing, it is more accurate than Light Propagation Volumes but less accurate than full-blown polygonal path tracing 

I am sure my technique can be improved upon A LOT, since I know my dream game engine Brigade 3 runs in real time, and for low-res GI you only need a fraction of the capabilities it has.

Here is a link to Brigade 3, the ultimate graphics engine IMO: http://icelaglace.com/portfolio-type/brigade-3-0/ (and no, it is not a scam, they released a demo for Brigade 2 (I tried it), which also looks fantastic already)