Topic Simplify fragment shaders?
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to PeterW
Following up on a discussion in #openclonk-dev... The idea with the "slice" model was that we could easily "plug" shader components into each other. So - for example - somebody could override the "scaler" shader to get a different landscape scaling behaviour without the need to override other parts of the shader.
However, I'm not quite sure this is going to happen, because clearly the whole thing is quite hard to understand currently. From having a look through the source code, we currently have the following shader "groups":
* UtilShader, LightShader, AmbientShader, GammaShader: Always applied.
* LandscapeShader, ScalerShader: Applied to the landscape.
* ObjectBaseShader, ObjectLightShader: Applied to meshes + sprites. This also applies to GUI elements, from what I can see.
* SpriteTextureShader: Applied to meshes ("unused"?) + sprites when requested. Not entirely sure what this does.
* SpriteOverlayShader: Applied to meshes + sprites when requested. Probably where player colour comes in?
* MeshShader: Gets loaded, but doesn't even exist?
* Shaders dynamically generated from Ogre files.
Furthermore, we have the following preprocessor macros switching on and off certain parts of the shaders:
* LANDSCAPE: Set for landscape drawing
* MESH: Set for meshes
* HAVE_LIGHT: Assume we have light information. If set, LightShader+AmbientShader query their respective textures to find how much light we have at the part of the landscape in question. Otherwise, we fall back to a basic shading model that makes sense for showing 3D GUI items.
* HAVE_NORMALMAP: We have a normal map for our material, use it appropriately for shading calculations.
* CLRMOD_MOD2: Adds player colour overlay instead of multiplying it.
* HAVE_2PX: Set by the landscape scaler, because we need to shade two full pixels for anti-aliasing at the edges.
All in all, this is a rather dizzying number of possible configurations, a lot of which aren't even used. Some things are turned on and off by adding slices, others by preprocessor macros. So how about we do the following:
1. Merge UtilShader+LightShader+AmbientShader+GammaShader into CommonShader
2. Merge LandscapeShader+ScalerShader as LandscapeShader
3. Merge ObjectBaseShader+ObjectLightShader+SpriteTextureShader+SpriteOverlayShader as ObjectShader (?)
Furthermore, we map *all* C4SSC shader flags (C4SSC_MOD2, C4SSC_BASE, C4SSC_OVERLAY, C4SSC_LIGHT, C4SSC_NORMAL) to shader preprocessor flags. The landscape shader will set them too for consistency. LANDSCAPE, MESH & SPRITE (?) set the drawing mode. End result: Everything in 3 files, we can focus on writing some good documentation for the preprocessor flags, hopefully overall less mess.
Makes sense? Clonk-Karl, especially?
However, I'm not quite sure this is going to happen, because clearly the whole thing is quite hard to understand currently. From having a look through the source code, we currently have the following shader "groups":
* UtilShader, LightShader, AmbientShader, GammaShader: Always applied.
* LandscapeShader, ScalerShader: Applied to the landscape.
* ObjectBaseShader, ObjectLightShader: Applied to meshes + sprites. This also applies to GUI elements, from what I can see.
* SpriteTextureShader: Applied to meshes ("unused"?) + sprites when requested. Not entirely sure what this does.
* SpriteOverlayShader: Applied to meshes + sprites when requested. Probably where player colour comes in?
* MeshShader: Gets loaded, but doesn't even exist?
* Shaders dynamically generated from Ogre files.
Furthermore, we have the following preprocessor macros switching on and off certain parts of the shaders:
* LANDSCAPE: Set for landscape drawing
* MESH: Set for meshes
* HAVE_LIGHT: Assume we have light information. If set, LightShader+AmbientShader query their respective textures to find how much light we have at the part of the landscape in question. Otherwise, we fall back to a basic shading model that makes sense for showing 3D GUI items.
* HAVE_NORMALMAP: We have a normal map for our material, use it appropriately for shading calculations.
* CLRMOD_MOD2: Adds player colour overlay instead of multiplying it.
* HAVE_2PX: Set by the landscape scaler, because we need to shade two full pixels for anti-aliasing at the edges.
All in all, this is a rather dizzying number of possible configurations, a lot of which aren't even used. Some things are turned on and off by adding slices, others by preprocessor macros. So how about we do the following:
1. Merge UtilShader+LightShader+AmbientShader+GammaShader into CommonShader
2. Merge LandscapeShader+ScalerShader as LandscapeShader
3. Merge ObjectBaseShader+ObjectLightShader+SpriteTextureShader+SpriteOverlayShader as ObjectShader (?)
Furthermore, we map *all* C4SSC shader flags (C4SSC_MOD2, C4SSC_BASE, C4SSC_OVERLAY, C4SSC_LIGHT, C4SSC_NORMAL) to shader preprocessor flags. The landscape shader will set them too for consistency. LANDSCAPE, MESH & SPRITE (?) set the drawing mode. End result: Everything in 3 files, we can focus on writing some good documentation for the preprocessor flags, hopefully overall less mess.
Makes sense? Clonk-Karl, especially?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill