Horde3D

Next-Generation Graphics Engine
It is currently 21.09.2018, 17:11

All times are UTC + 1 hour




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: 25.03.2013, 17:09 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
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:
Code:

context OPAQUE
{
   VertexShader = compile GLSL VS_GENERAL;
   PixelShader = compile GLSL FS_GENERAL;
#ifdef _F01_NoneCull
   CullMode = None;
#else
   CullMode = Front;
#endif
}
context TRANSPARENT
{
   VertexShader = compile GLSL VS_GENERAL;
   PixelShader = compile GLSL FS_SELECTED;
#ifdef !_F02_Selected
   Enabled = False;
#endif
}


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


Top
 Profile  
Reply with quote  
PostPosted: 27.03.2013, 12:13 
Offline

Joined: 23.07.2009, 21:03
Posts: 51
Location: Germany
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:
Code:
<DrawGeometry context="OPAQUE" class="opaque" />
<DrawGeometry context="OPAQUE_NOCULL" class="opaqueNoCull" />

shader:
Code:
context OPAQUE
{
   VertexShader = compile GLSL VS_GENERAL;
   PixelShader = compile GLSL FS_GENERAL;
   CullMode = Front;
}
context OPAQUE_NOCULL
{
   VertexShader = compile GLSL VS_GENERAL;
   PixelShader = compile GLSL FS_GENERAL;
   CullMode = None;
}


Top
 Profile  
Reply with quote  
PostPosted: 27.03.2013, 21:01 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
Roland wrote:
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?

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.

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

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.


Top
 Profile  
Reply with quote  
PostPosted: 30.03.2013, 19:35 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
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.


Top
 Profile  
Reply with quote  
PostPosted: 02.04.2013, 21:49 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
marciano wrote:
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...


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.

marciano wrote:
... 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 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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group