3000th commit - IrrlichtBAW (GIT repo, v 0.3.0-gamma1)

[devsh]

I do even still know a project depending on the Burnings renderer (because unlike hardware renderers it's colors are the same on every graphic card which is needed in some industry - opengl is not color-exact as it depends on driver implementations).

I believe the GL 4.5 spec is very tight, could even say that 4.3 would suffice. I'd be very interested to see a concrete color reproducibility example that OpenGL 4.5 doesn't solve.

Maybe you'd like to hit me up for some information on cubemaps for global illumination... I know quire a few tricks.

P.S. I don't have the will or want to spread myself over multiple APIs, but irrbaw's API is in the process of being refactored to closely follow Vulkan's, hence D3D12 port would be almost a matter of filling in the blanks in identical classes with D3D12 pre-pended to the name instead of Vulkan. Thats a completely different problem to spanning the gap between Dx9 (or Dx10 even) and D3D12.
I actually have a plan for "write-once-run-anywhere" through the Vulkan Portability Initiative, you might want to snoop that approach.

[CuteAlien]

Nice if OpenGL has that now. Means we can get rid of inexact tests in the future ;-) Thought for that specific project they won't have a need to switch (at some point I suppose they will just have to stay with Irrlicht 1.8 or 1.9) - otherwise they would now have to write a burnings-renderer emulation in OpenGL as a few man-years of data is already created with current colors (edit: if you wonder why I'm not more specific, got an NDA in this case)

[devsh]

There is the GLSL keyword invariant, and GLSL now supports some form of IEEE which makes calculations consistent.

(We had a problem that the order of concaatenation (multiplication) of world view proj matrix made a problem and we had a Z-fighting issue when we switched to GPU instance culling, but making GLSL follow the same order (unoptimal) resolved the issue)

There is also
https://www.khronos.org/registry/OpenGL ... cations.tx
which solves problems for MSAA (new cards only) by introducing consistent sample locations, to the point that you can exploit that to do particle half-resolution shading, but full resolution composting (similar to stencil-K routed transparency).

If you wanted 100% reproducible MSAA then you would have to have your own resolve pass (screen quad shader) to control how samples influence pixels, but most engines which have fancy AA such as SMAA, SRLA, TXAA, etc. already control this.

W.r.t. backports, we have full support for 1D,2D,3D,Cubemap and MSAA textures and their Array variants in IrrlichtBAW, expecially we resolved the issue of glActiveTexture(texture type) so you may want to have a look at that for your cubmap implementation.

Finally, you want to slam all your cubemaps into a cubemap array texture if you can target OpenGL 4.0 hardware, this will enable you to go effectively bind-less and sample arbitrary GI probe in your scene without the need to switch textures or worse, performing additive blending with stencil volumes.

[CuteAlien]

We got cubemaps in array already in Irrlicht I think (not sure if you mean the same). Thought the interface will change once more in this case.

[devsh]

https://sourceforge.net/p/irrlicht/code ... ITexture.h
https://sourceforge.net/p/irrlicht/code ... eTexture.h

show that you've only implemented GL_TEXTURE_CUBE_MAP, not GL_TEXTURE_CUBE_MAP_ARRAY
And in D3D you'd need D3D11 for that.

====

Bonus Points, implement SSBOs then create and clear it every frame and write 1 into an associated array index whenever you sample from a given GI probe, then download the resulting SSBO asynchronously (with an ARB_sync fence indicating when done) and drop the SSBO. This will enable you to keep a boolean histogram of which probe was used 3 or 4 frames ago and you can prioritize the update of the ones which were use the most in the last 30,60 or 100 frames.
Hell you could even do an LRU cache (allocate a texture array with lets say 128 layers but have 1024 probes in the scene) which would evict the probes in and out.

Bonus Points for Bonus Points, if you used atomicAdd() instead of = 1 on your SSBO uint array then you would have a count of how many pixels were sampled from a GI probe allowing you to better schedule update (and LRU cache score)

Other Bonus Points, if you wrote atomicMax() of the fwidth(texcoordYouSampleCubemapWith) to the SSBO instead of 1, then you could even kick them to a lower-resolution texture pool!

[devsh]

Example 25 online: Compute Shader Radius-Independent Gaussian Blur Approximation

(hint hint, might help you with your PBR stuff).

[devsh]

Thread safe mesh, meshbuffer, animation, texture and shader loading is coming through an IAssetManager class which will take over some of the functionality of ISceneManager and IVideoDriver

Spec:
https://docs.google.com/document/d/1LGW ... U5n3f9HGNA

[devsh]

This is the way I imagine to unify OpenGL and Vulkan shader loading by supporting only one shader language with some tradeoff in functionality and not be a pain in the ass of a developer by requiring them to write two sets of shaders and/or have their vulkan shaders already compiled with glslang

The really cool thing about the system is that theoretically it could support loading and using HLSL shaders with OpenGL and Vulkan.

https://docs.google.com/document/d/1WA8 ... 7sVo1czXqs

[devsh]

Booted out irr::core::array, irrAllocator.h and some other trivial things

Provided a general use aligned_allocator and `using` aliases for all STL containers (ofc making the default allocator an aligned_allocator).

Holding off on the strings for now.

[devsh]

Pool Allocator for stl containers and gpu memory is coming!

[devsh]

Merged a very large pull request (and two more), closed 9 issues this week.

SPIRV-Cross and shaderc added to the library.

[devsh]

scoped gpu allocators are coming

[devsh]

Asset pipeline about to finished and Vulkan+OpenGL unification UML is available online.

https://repository.genmymodel.com/devsh ... ogramming/

[devsh]

So it turns out that integrating RadeonRays with IrrlichtBAW is pretty straight forward, since its has an OpenCL device stub with GL interop!

Pics coming soon.

Disclaimer, this is not my work... only an IrrBAW's user's.

[mant]

Here it is