Horde3D

The current shader system uses shaderflags to create multiple versions of vertex/fragment shaders which is great.

But we still need to create separate h3d shaders for different alphablend/cull/zenable modes with the same vertex/fragment shaders. It would be great if states like ( ZWriteEnable, ZEnable, ZFunc, BlendMode, CullMode, AlphaToCoverage ) could depend on shaderflags too.
With a new Enabled flag one can also enable/disable context using shaderflag. (for example enable/disable a "selected overlay")

For example:

Something like this could work, but extending horde3d with this preprocessor magic is a little complicated.
Any idea on this?

Wouldn't this encourage a way of developing shaders which heavily rely on (opengl) state changes?
Whenever possible texture lookups and customInstData should be the more efficient option, no?

Obviously, if you need to e.g. change the cull mode of all objects using a specific material this might come in handy.

With the current system, one solution might be to use classes and multiple draw commands?
Something like:

pipeline:

shader:

Yeah, state changes should be minimized, but if you really need them (different blending/culling) they should be as cheap as possible.
If I use two h3d shaders it requires more state (shader) change because I need to compile shaderprograms (every combination) twice. In h3dRender instead of changing the cullmode only , shader program is changed too.


Thanks for this tip, I always forget classes.
My problem with the solution you proposed that each DrawGeometry does frustum culling for every node which takes significant time (depens on nodecount). With shadowing-enabled DoForwardLightLoop it is much worse as shadow maps are computed twice.

So I still would find this usefull, my only problem is with syntax. As allowing #ifdef/#else/#endif macros only in the context for states-only is a little awkward.

Hi attila, having states dependent on shader flags as you propose does make a lot of sense in my opinion, especially since Horde is very data-driven and does not provide fine-grained control over render states from the external API (on purpose). In fact adding this was something we were thinking of a long time ago already.

It means writing a small expression parser but since we are just limited to basic boolean operators, that shouldn't be too hard. Writing a lightweight expression evaluator is an interesting little challenge but I have to admit I won't be able to help out with this in the next time. To be fully honest, due to the amount of focus currently required for my professional work (this year is a very exciting one in the industry with all the things going on), I am sorry I have to say that most likely there won't be a lot of progress on Horde this year from our side.

It is not a huge task, but I'm not too experienced in writing evaluators. But learning new things are always rewarding, so I will probably give it a try, if there is nobody else who would like to implement it. About the implementation: I'm not sure if the whole FX section should be able to contain #ifdef/#endif (maybe C like if() {} else {} )conditions Or just the Context states (excluding the shaders) - which is needed for us right now.



It seems like community should help horde3d to move forward, but even that still would require work(discussing/accepting proposals, discussing possible implementation designs, reviewing the implementation,...) from you. The community roadmap on wiki is almost 5 years old, sadly in its current form it didn't really work.

These are very exciting times in game development, It's almost overwhelming to see so many new hardwares/platforms. Best wishes on your professional work.