What is Nabla

Nabla is a GPU programming sandbox, so it's mainly purely data-oriented HPC and Hardware Rasterization library encompassing OpenGL and Vulkan (soon).

As the end goal it will run on headless GPU servers (Vulkan Compute), Nvidia GRID servers (OpenGL/Vulkan) all the way down to Mobile (but only very recent Android Vulkan capable devices).

It's kept very close to the metal, so you should be able to use all OpenGL/Vulkan functionality you want without ripping it out of layer upon layer of abstraction (like some engines with "3D" in the name as a suffix :) ).

The idea is to have something that you'd want to use to develop a High Performance "Application Specific" Graphics Program, instead of building everything from scratch with pure GL or Vulkan.

This is why the backend graphics API set is restricted to only OpenGL 4.3+ core and Vulkan, and will always stay that way, although the minimum OpenGL version might get a bump or get dropped alltogether. If we wanted to bridge together DirectX, OGL, Vulkan and Metal in any combination under the same set of objects we'd end up with either over-abstraction (featureset limited by the least able API), a very divergent interface (different C++ code paths for different APIs) or an interface strongly influenced and modelled after one particular API. The problem of modelling after one particular API (DirectX9) and over-abstraction is experienced in 'stock' Irrlicht. Over-abstraction is an issue with the largest, most popular and most cross-platform game (not 3D) engines out there. I have yet to see a manageable un-abandoned engine with a divergent library interface/API.

If you just want to load a data-set (i.e. textures, spatial data), process it with a compute shader, visualize your results, and export them; you wouldn't want to spend hours writing PNG loaders from libPNG and fussing around with the basics of uploading textures to OpenGL (or worse in Vulkan), or worse the basics of creating an OpenGL core profile context and window (or worse in Vulkan) as well as loading all the function pointers, you'd want to jump straight to the Compute Shader or OpenCL kernel.

So essentially this is skeleton of a 3D Engine CORE without actually forcing rendering solutions down people's throats. This is why the following are being implemented and are viewed as important:

1. Compute Shaders
2. Access to Graphics API functions from multiple threads simultaneously
3. Our own extensible native binary format with lz4 or lzma compression followed by optional aes128_gcm encryption
4. An OpenGL global state tracker for interfacing with 3rd party OpenGL middlewares (Silverlining, Triton, CEGUI) and intra-thread material system
5. Access to Vulkan with OpenGL as a fallback
6. Vulkan and OpenGL interop
7. Generic library of useful functions for GLSL with some PBR-BRDFs, GPU sort kernels and other functions in the nbl::ext:: namespace
8. Sparse Textures, Sparse Buffers
9. GPU Buffer and texture memory allocators/pools
10. Examples showing the power of unobstructed OpenGL usage
11. Multithreaded Model Loading
12. GLI integration
13. AVX/SSE3 2d and 3d math classes
14. GPU-side skinned mesh boning and scenegraph

For the same reason following things would not ever be in the core-engine, would not be priority and if-done would have to live in an extensions repository https://github.com/Devsh-Graphics-Programming/Nabla/tree/master/include/nbl/ext:

1. PBR or Specific Lighting Models (GGX, Cook-Torrance, Blinn-Phong etc.)
2. A Deferred Renderer
3. Lightmapper
4. COLLADA Loader
5. Shadows
6. Postprocessing of any kind
7. Transparency
8. Automated Occlusion Culling This is simply because there are many many ways of doing the above, and none of them is "the right one" for even 80% of the use cases. So if Nabla to support one in the core engine, it would have to support the cornucopia of others (even as alternatives).

Secondly, the really good solutions to Deferred Rendering and Order Independent Transparency require the end user integrating the engine to 'make their assets fit into the pipeline' such as modifying shaders so that they write the correct data in the correct order to a G-Buffer or even change the entire order and the way their engine sets up the draw loop. So without someone's clear use case, already existing work and onobtrusive implementation which would not tie down the API, such things would have no right to exist in engine core. A brilliant example of an item which would have been on that list is the IGPUTransientBuffer, which is a useful stand-alone side-addition. We developed it for streaming very small data (<4kb) to and from the GPU to avoid VAO and Buffer object explosion (especially for the GUI).

There are however some things in the grey area, such as a Bullet Physics, Occulus, etc. integration of which could see the light of day being implemented in the engine core.

Again it's not that I'm bashing the development of a 3D engine, game engine or level design tools around Nabla or even normal 'stock' irrlicht. It's just that those things should be their own separate project with their own repositories even if maintained by the same community.

TL;DR We're making an engine, the gearbox and the steering you have to make yourself.