Sign in to follow this  
vinnyvicious

BGFX and micro-shaders?

Recommended Posts

I'm trying to understand the examples behind bgfx, but take this for example:

 

https://github.com/bkaradzic/bgfx/tree/master/examples/16-shadowmaps

 

Why there are so many .sc files? How do they work with each other? Wouldn't it be easier to have a single "shadow.sc" that handles all those cases?

Share this post


Link to post
Share on other sites

Let it not ever be said that BGFX's samples demonstrate the way you [b]should[/b] be doing much of anything. 90% of those files are just setting up preprocessor constants.

 

In a practical scenario, you'll probably have a shader generator system that generates all those combinations at build time from your own intermediate shader representation.

Share this post


Link to post
Share on other sites

Do you recommend any books or articles covering such shader generating system?

Not to hand. Such systems range from perl scripts that munge together fragments of GLSL source code, all the way to fancy graph editors like Unreal has.

Share this post


Link to post
Share on other sites

Oh, so you mean a material system that dynamically generates shader instructions, instead of actually writing the shader files?

 

You can still write code, the material system with just nodes and no code (out of the box) is just epics specific implementation. In general the two problems here are first: There are many different shading languages and so far there is no good way to convert between them easily (*crossing fingers that SPIR-V and LLVM based transpilers catch on for everything including HLSL and whatever custom implementations the consoles have*), you need some way to write shader code once (or at least, mostly once) and have it work in DirectX, OpenGL, Apple's Metal (and the various versions of all of those). 

 

And second: A lot of your shaders will require many small variations (i.e. in the order of several hundreds or thousands or more for big engines like Unity), and you want a way to automate that (again, for various languages and platforms) so you don't have to write everything yourself.

 

So to do that, you need to have some kind of intermediate representation of what your shader is supposed to do, that is in the end converted to the actual output you need to run the shader code. It can start really simple where your intermediate representation is actually raw GLSL code with a bunch of custom macros at the top and your application just inserts #defines into the code before compiling it. Or it can end up as Epics Material system. 

Share this post


Link to post
Share on other sites

Yes, most of these systems work by concatenating together small fragments of GLSL code. Some fragments can be chained together, others are mutually exclusive. Not only is lighting a part of this system, but so is the vertex transform pipeline, because you need to be able to account for the differences between basic and skinned meshes.

 

 

For example, a single material might be composed out of the following chunks:

- Vertex Skinning

- Diffuse Map

- Normal Map

- Lighting Equation with Specular

 

And another might use:

- Basic Vertex Transform

- Vertex Color

- Environment Map

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this