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?
Before that change, you couldn't distinguish between sky and sprites.
Btw - doesn't 790219ac kill transitions for material animations? Not the most critical use case, granted...
PS: okay, that was stupid of me. You didn't do anything about the rimlighting/ambient lighting but just the cleanup stuff, yet, right? :D
> Btw - doesn't 790219ac kill transitions for material animations? Not the most critical use case, granted...
Does it? If yes, how so? I thought this to be a pretty much 1:1 translation of the 3D texture to the 2D array.
> normal = normalize(normal);
Is that really needed in CommonShader.glsl? Shouldn't the part of the code that is providing the "normal" variable make sure it's normalized?
> * SpriteTextureShader: Applied to meshes ("unused"?) + sprites when requested. Not entirely sure what this does.
This does not apply to meshes but only for sprites. It multiplies the base color of the sprite that is set with glColor*() with the sprite's texture. Note that the "sprite" shaders are also used for other 2D drawing such as points and lines, such as PXS. Those don't have a texture and so the shader for those doesn't include SpriteTextureShader.glsl.
> * SpriteOverlayShader: Applied to meshes + sprites when requested. Probably where player colour comes in?
Again, only applies to sprites. Modulates the pixel color with the color from the overlay texture (Overlay.png) -- so yes, primarily, player color.
> * MeshShader: Gets loaded, but doesn't even exist?
Whoops. I probably started with MeshShader.glsl but then changed my mine at some point. Can go away of course.
> * Shaders dynamically generated from Ogre files.
These can either be dynamically generated or hand-written, e.g. when enabling normal maps for meshes a hand-written shader must be used, which is in Objects.ocd/normal_map_fragment.glsl (not a good location really, but the only place that makes sure this gets loaded before other OGRE materials, so it can be used by other OGRE materials. We might want to load OGRE materials from Graphics.ocg, too, so we can move it there).
> * LANDSCAPE: Set for landscape drawing
Now
OC_LANDSCAPE
.> * MESH: Set for meshes
Now
OC_MESH
.> * 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.
Now
OC_DYNAMIC_LIGHT
. This is usually set for ingame objects and not set for GUI objects. Not only relevant for 3D but also 2D sprites.> * HAVE_NORMALMAP: We have a normal map for our material, use it appropriately for shading calculations.
Now
OC_WITH_NORMALMAP
. Used both for sprites and meshes; for meshes the shader slice in Objects.ocd/normal_map_fragment.glsl activates this so it is picked up by ObjectLightShader.glsl.> * CLRMOD_MOD2: Adds player colour overlay instead of multiplying it.
Now
OC_CLRMOD_MOD2
. Doesn't affect player color but color modulation as set with SetClrModulation. This is activated when the blit mode is set to GFX_BLIT_Mod2 with SetObjectBlitMode, and also used for highlighting objects in the editor when pressing Shift.> * HAVE_2PX: Set by the landscape scaler, because we need to shade two full pixels for anti-aliasing at the edges.
Now
OC_HAVE_2PX
.Plus we now have
OC_SKY
as mentioned by Clonkonaut.Overall I think your suggestion makes sense, but we still need all these preprocessor flags, right?
> 3. Merge ObjectBaseShader+ObjectLightShader+SpriteTextureShader+SpriteOverlayShader as ObjectShader (?)
This will need additional preprocessor flags/checks to distinguish meshes from sprites with texture from sprites without texture from sprites with texture and overlay. But that should be fine. Overall I'm not sure we gain too much, but it probably makes sense to try it out and see how it works. I'm somewhat worried we merge some of the files but then have more preprocessor checks in those files. I don't know what's better.
> This does not apply to meshes but only for sprites. It multiplies the base color of the sprite that is set with glColor*() with the sprite's texture. Note that the "sprite" shaders are also used for other 2D drawing such as points and lines, such as PXS. Those don't have a texture and so the shader for those doesn't include SpriteTextureShader.glsl.
I guess the part that confuses me is - why do we need a special path for that? To do the color multiplication?
> ... renamings ...
Yeah, saw that you changed it. I would have preferred to keep the naming closer to the C4SSC names, but well.
> This will need additional preprocessor flags/checks to distinguish meshes from sprites with texture from sprites without texture from sprites with texture and overlay.
Beyond the OC_WITH_BASE / OC_WITH_OVERLAY that I added in lights3?
> I guess the part that confuses me is - why do we need a special path for that? To do the color multiplication?
Because in some cases we don't have a texture, so what do you want to multiply it with? Do you mean we could instead bind a 1x1 texture with a single (1.0, 1.0, 1.0, 1.0) pixel?
> Yeah, saw that you changed it. I would have preferred to keep the naming closer to the C4SSC names, but well.
I mostly changed it to add the OC_ prefix, but didn't think too much about the rest of the name. So since you are cleaning these things up anyway, feel free to change the definitions to match the C4SSC names.
> Beyond the OC_WITH_BASE / OC_WITH_OVERLAY that I added in lights3?
No, that should be enough. I wrote my reply before I saw your commits :)
Will probably still need a few iterations to look good in all situations... Especially note that the clouds in the second screen shot are too bright now.
Edit: Also the GUI elements are fairly dark now, e.g. the Clonk picture in the HUD is too dark compared to the Clonk in-game. Selections in editor mode are now gray where they used to be white before.
> Edit: Also the GUI elements are fairly dark now
Yeah - but if I change this, the main menu screen will become overly bright.
> Why would we ever want the sky to be illuminated by the Clonk's light?
At nighttime? I think this scenario of Sven does this.
> Yeah - but if I change this, the main menu screen will become overly bright.
But it should not be that a call to C4Draw::DrawLineDw() with color white gives you a gray line. Maybe the main menu should use a different shader?
For daylight, e.g. see the fireflies in Crash Landing. They look a bit stupid on top of that hill during the day.
https://trello.com/c/M7OKF7jC/96-lighting
This was before Peters change, tough.
Also made an effort to pull out all the important constants into the "init" slices of CommonShader and LandscapeShader. Furthermore, all shaders now automatically refresh when the underlying files are changed. This means that it should be a lot "safer" to experiment now, can only encourage everybody to try it!
Edit: See post above for new comparison shots.
Either have the shader itself figure out how transparent the texture of the material is, or
maybe have an extra parameter in *.ocm to determine how much ambience shines through? :F
Edit: Heh, if tiling matches, a dirt-cheap way of making this happen would be to have the engine automatically produce a "water with X background" material texture. Bonus points if it works with animation. Getting normals right might be tricky though.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill