but we are also looking for users, contributors and general feedback.
Documentation coming soon on a static github page.
Here is our completely non-exhaustive list of issues for potential contributors.
https://github.com/buildaworldnet/IrrlichtBAW/issues
Official Support Discord
https://discord.gg/4MTCVaN
There's also a skype support group, ask me for a private invite.
Our Project Goal:
Our goal with Irrlicht BAW is to have a GPU programming sandbox, so it
would be a pure data-oriented HPC and Hardware Rasterization library
with optional access to raytracing kernels, encompassing OpenGL and Vulkan.
We want to use it on headless GPU servers (Vulkan Compute), Nvidia GRID servers
(OpenGL/Vulkan) down to Mobile (but only very recent Android Vulkan
capable devices).
We want to keep 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.
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.
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 we want to make a skeleton of a 3D Engine 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 DONE
2) Access to OpenGL from multiple threads simultaneously DONE
3) Our own extensible native binary format with optional aes128_gcm DONE
encryption followed by lz4 or lzma compression DONE
4) An OpenGL global state tracker for interfacing with 3rd party OpenGL
middlewares (Silverlining, Triton, CEGUI) and intra-thread material system DONE (but will get phased out)
5) Access to Vulkan with OpenGL as a fallback
6) Generic library of useful functions for GLSL with some PBR-BRDFs, GPU
sort kernels and other functions in-progress mostly as irr::ext
7) Sparse Textures, Sparse Buffers
GPU Buffer memory allocators/pools DONE9) Examples showing the power of unobstructed OpenGL usage DONE
10) Multithreaded Model Loading DONE
11) GLI integration AVAILABLE
12) AVX/SSE3 2d and 3d math classes in-progress
13) GPU-side skinned mesh boning and scenegraph in-progress
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/buildaworldnet/Irrli ... master/ext:
1) A Deferred Renderer
2) Lightmapper
3) COLLADA Loader
4) Shadows
5) Postprocessing of any kind Already Have a Tonemapper, but in irr::ext::
6) Transparency but we have a demo/benchmark of tenchniques
7) 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 we were to support one in the core engine, we'd 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 (for which there is irr::ext::Bullet), Occulus, etc.
integration of which could see the light of day
being implemented in the engine core.
Release 0.3.0-gamma1 is out (RELEASES WILL NOT WORK IF NOT GIT CLONED)
https://github.com/buildaworldnet/Irrli ... 3.0-gamma1
08 Jun 2019
USE CMAKE-GUI TO BUILD
Check out the github wiki page for more info.
I guess you only care about pics, so selected examples from the examples_tests folder:
07.HardwareSkinning - 100 dwarves, pure GPU skinning with a configurable 120Hz limiter, no instancing, no batching - 1800 FPS
08.HardwareInstancing - your favorite cow mesh and a hundred poly flower mesh demonstrating GPU instance cloud culling and LoD selection via Transform Feedback
13. BRDF Explorer - See how GGX PBR and various diffuse models work with a single light
14.MSAA - 32 sample MSAA, 100 dwarves, 1000FPS
15.LayeredCubeMapShadows - 100 to 625 dwarves, GPU skinned, moving point light, omni shadows drawn in one pass, 56FPS with 625 dwarves (1MIl+ polygons)
16.OITZoo - over 10 planned transparency methods compared on the same scene (screenshot shows DevSH's modified stencil-routed k-buffer).
18.RaytracedAO - showcasing Radeon Rays integration to compute shadows from area and environment lights.
23.Autoexposure - A quick test of compute shaders for something useful (a must for HDR pipelines - uses ext::CToneMapper).
25. Blur -Compute Shader Radius-Independent Gaussian Blur Approximation (uses ext::CBlurPerformer)
Known issues:
1) Using RasterizerDiscard=true affects clearing and blitting frame buffers but setMaterial doesn't!!!
In other words you either have to draw something to change the RasterizerDiscard flag in OpenGLDriver or force reset all render states.