A minimalist rendering library.

[Julio Jerez]

This continues the discussion on the rendering API.

After researching the possibility of adopting a third-party rendering library, I’ve concluded there isn’t really a good solution.
Every candidate comes with numerous constraints, and most suffer from the same limitations you face when working directly with the low-level APIs.

About twenty years ago, I relied on GLUT, based on the promise of broad, long-term support across platforms. For a few years, that was true, until tech companies began redefining what OpenGL was supposed to be.
With the arrival of OpenGL ES for mobile, GLUT became practically useless on those devices unless you resorted to awkward workarounds and specialized variants like GLW.
Over time, things simply stopped working.

Since then, we’ve seen an explosion of new APIs: Vulkan, Molten, Metal, DX12, NVIDIA’s various libraries, and more, each making true cross-platform support increasingly difficult to maintain.

My conclusion is to build a lightweight rendering library, inspired by what RenderWare used to be. The goal isn’t to create a full rendering engine, but to provide a consistent cross-platform backend. This approach will also help clean up the demos, removing low-level API calls that can confuse users, while offering a path to improved basic rendering quality for teh demos.

[Julio Jerez]

The library now get to a slow part. That I hate the most.
The combinatorial effect of vertex shader/pixel shader
And shader parameters.

I miss the old day of the * pipe line. Now you get this
Problem that for each shader with a different set of parameter, you have to generate the difference combination

This is really a pathological side effect of that method
I have seen engine like unreal generation several gigabyte files of compiled shaders, that need to be preloaded in GPU
Before you start.
Building the shader cache takes over 24 hour in a very fast PC.
My method will just be at the primitive level.just like renderware was.
Yes is not that powerful, but good enough for demos.
Even that simple system requires carefully implementation consideration, other wise it gets very messy really fast.

[Julio Jerez]

it now has all of the feature that the old method had and a lot more.
new features are:
the scene has environment reflection, and instance rendering cast and receive shadows.

as a side not. I was plaining to have instance before adding the demos.
but then I remembered how slow it becomes when you render few thousand primitives.
so I added instancing.

there is one only small problem, the passes increase quadratically with the number of features.
so adding instancing generation shadow, do take a tall in rendering.
the fps is still in the 2k fps from almost 7 thousand.
without instancing, believe or not, rendering become slower that the physics update.

one improvement that I can make is adding a rendering to texture pass, that the environment with a filter of the reflection instances. and rendered to a lower (512 by 512) cube map,
that will generate a one level dynamics reflection. and should not be too expensive.

The secund feature is alpha blend for population the map lot of stuff like trees and grass or object with detail parts that I always have to edit out form models.

anyway, that's for the future, now I will add scene that use instancing