BlitzMax (NG) - Render Pipeline ideas

Started by Derron, March 06, 2019, 07:17:15

Previous topic - Next topic

Derron

Ho ho ho,

If BlitzMax's Max2D needed a slight overhaul, which stuff would it need to get added for a proper and interesting renderpipeline?
I have no clue on what such a pipeline needed and only have a basic idea on how this stuff _might_ work.


The idea is to have a render pipeline which "works out of the box" but allows to intercept here and there - or to customize behaviour.
As said I have almost no clue about this but the keywords I think of are:
- Shader support (Pre, Post, attached to objects/textures?)
- Render 2 Texture
- Batch sprites
- and many more things I surely miss

So any expert here with graphics programming knowledge is welcomed to share their ideas on how such a thing could be structured - and maybe even layouted (abstracted-)code-wise.

There is currently a basic "bgfx.mod" allowing to interact with "bgfx". Still it needs a "simplified" way of accessing functionality. So think of "bgfx" being the hardware layer helper and "our module" to replace or enhance "Max2D" which interacts with "bgfx" to achieve what it wants.


bye
Ron

Derron

Having read
https://godotengine.org/article/godot-3-renderer-design-explained
I think there is way too many stuff to grasp for a one who never did such a thing in live.

Means it needs people who know the terms, know the inputs and outputs required of a renderer. It seems to be hard to keep eg. this "intermediate mode" used by BlitzMax' Max2D.
Also I am not sure if I misunderstood it - but if you create your own renderer (pipeline) it is almost a basic 3D engine - it just misses the "convenience functionality" (to create spheres, objects, setup lights, ...). Means if you did that you could "put over" your 3D-helper-stuff and get the 3d-capability ("RenderWorld()")). Means stuff like MiniB3D or OpenB3D either could plug into the new pipeline - or get replaced by it (seems OpenB3D has some drawbacks which get more "repaired in a rough and ready way" then it should) and maybe a physics engine/library-wrapping-module.

Still users of OpenB3D and MiniB3D have some knowledge of where they would want to configure stuff and how.



@ scene graphs in modern renderers
Seems many renderers use scene graphs to organize there stuff. For me that sounds too much like "scenes in flash" (I know, dumb comparison). Is the whole thing a pure "internal data organization" thing or has it already influence on the way the (end) developer can do its stuff?


All in all I think that the newly introduced NG features like "structs and interfaces" (maybe even the enums) would help to ease the pain developing such a renderer - yet it misses the expertise in that render-pipeline-subject.


Why am I trying to discuss that topic if I do not have a clue about it?
I think it need this functionality to finally replace the "beloved" Blitz3D. Even AGK would then only (for now) offer other platform targets (until Brucey achieves to fight emscripten/html5 successfully) and maybe a bigger user base.


bye
Ron

GaborD

As far as I understand it a scene graph is just a way to organize the data in a hirarchical way. You can do it in whichever way fits the needs of your engine best.
I am not an expert in low level programming (or even a programmer), can't help much in that area unfortunately.
Don't want to add half-truths or "stuff I heard" to the discussion, would just make things more confusing. 


Derron

The low level programming would be handled by bgfx.mod (so the communication with opengl, dx, vulkan, metal...).


The engine would need to provide the required instructions to bgfx.

Even if you could not programm your knowledge is surely very valuable. There are various shaders manipulating data at different stages of the render pipeline. What data must be made available to objects/shaders/... And surely a dozen of other questions.

How to properly layout data structures, ...

I am sure I only tackle the tip of the iceberg for having a so limited knowledge of that subject.
Still I try to help a tiny bit to bring NG forward in that direction. Seems better than to put almost all tasks on Bruceys shoulders.


Bye
Ron

GaborD

The Godot article you linked is interesting.
I won't claim I understood everything, but it was a good read.  :))

I like what they wrote about shader abstraction, that's something worth considering.
If the base renderer is strong, then users don't have to mess with core lighting/shadows anyway, so why not give them a method to very easily write "shaders" without the complexity of full shader coding.
Unity did something similar with the surface shader system back in the day, but they still kept it very shader-y.
I think one could take it further and try to close this divide between people who can't use shaders and those who do.
The trick would be to still have an option for power users who want to tweak everything.