While the Optifine environment is easy to work within, the learning curve caught me off guard many times.
General theory and work arrounds documented below.
Since this is a hobby project, a lot of debug or testing code still exists in the files. Most of which are commented out, but need to find more time to clean up and optimize the code. Just how life goes it seems, haha.
Since this was the first shader pack I made, initial target buffers weren't set as they were expected from the Optifine docs.
So until I go through updating all of the prorgams to point to the correct buffers, reference the target render buffers below-
0- vec4( XYZ; Color, W; Alpha )1- vec4( X; Depth, Y; Glow Strength, Z; null, W; Value Exists )2- vec4( XYZ; 0-1 fitted normals, W; Value Exists )6- vec4( Glow Color HSV; X; Hue, Y; Saturation, Z; Value, W; Value Exists )7- vec4( X; MC Block Lighting, Y; Optifine Dynamic Lighting, Z; null, w; Value Exists )9-
In shaders/programs/utils/texSamplers.glsl there are many different texture sampling blending functions.
They all have their individual uses, but generally speaking rely on Hue, Saturation, and Value to determine differences in neighboring pixels in the texture.
With HSV, I can find the deltas in the values, only blending found colors should they be similar enough. Allowing a blur more akin to Smart Blur in photoshop. Only bluring colors should they be similar, not blending if they vary too much.
In Mojang's promotional art, at a given distance, blocks become singular colors. Void of any detail at all.
I'm finding the solid block color by sampling the texture atlas a couple times in the Vertex stage of gbuffer_block.glsl and gbuffer_texture.glsl and mix the found colors together based on if there is an Alpha value or not.
Some issues I've found is that animated textures, like Water, Lava, Nether Portals, etc., cause rather large jumps in color as they animate.
For some aspects of this, having a uniform shift in Water and Lava looks pretty good, but does have a penchant for being a little nausiating out at sea or lava walking with a strider.
(This look and feel is still being worked on.)
Another issue comes from Ores blending to undesirable colors. For some ores, seeing a solid blue color for lapis at a distance, helps you find blocks at greater distances, but isn't in the vein of minecraft to have such an easy time finding ores.
Blending in tones that vary from the found "block color" from the vertex stage is allowing ore block colors to be retained at greater distances. Iron, Copper, Coal, Diamond, and Redstone's visible colors within stone/deepslate, retain more of their shape, and less solid block color tone.
Course lapis is still janky. Since the locations I'm sampling the block texture in the Vertex stage, is exactly where the lapis blue color shows through.... Fun times...
Tweak some values to fix one ore...
Causing other ore to break how lapis was broken....
In order to calculate block, entity, and other edges, I'm passing Depth Buffer and Normal Buffer data to post processing passes.
(Currently final.glsl, edge detection is being moved to a composite pass.)
With Depth Buffer data, we can sample near by pixels to detect jumps in depth of neighboring pixels. Allowing detection of object's Outside Edges in an image/render.
With Normal Buffer data, we can sample near by pixels to detect angle changes of a block or neightboring blocks in game. Allowing detection of object's Inside Edges in an image/render.
With Depth's Outside Edges and Normal's Inside Edges, we can customize look and feel of blocks we are facing or a cascade of blocks in a cave or build.
So of course I gotta tweak outside edges separate of inside edges. Changes in thickness or color, to push the desired style and vibe of the shader pack.
Gotta have that bloomish glow to really pull in ambiance for a shader pack!
I'm using a pretty standard 2 pass box blur; U/X Blur then V/Y Blur
To push the base glow a little more, I'm adding in a scaled down single pass box blur version of the glow buffer
When combined, the central pixels from the original glowing values pop a bit more with the single pass box blur
scale.composite1=0.4- Initial scaled down for core box blur glow. This aids in single pixel glow at a further distance to not pop in and out of existance as you look around.
Render Target -colortex8scale.composite2=0.3- U/X axis bluring using buffers fromcomposite1
Render Target -colortex10scale.composite3=0.3- V/Y axis bluring using buffers fromcomposite1
Render Target -colortex10
Texture Atlas dedicated texturing/shading is a common technique in games to get around excess texture buffers wasting space on the GPU.
In the past, I provide more information to my shaders through Uniform and Attribute variables to be read in the shader itself.
For Optifine, or Minecraft in general, important data doesn't pass to shaders unless the player themselves turn on specific options.
Texture bounds within the Atlas, center position of the apecific atlas texture, pixel size within the texture itself, or pixel size within the TextureMatrix multiplied TextureCoords, etc.
This introduced a rather persistant issue for detail bluring where the Texture2d lookups were reading the neighboring atlas texture.
While annoying, lead to some rather odd math to figure out color blending percentages and calculating atlas bounds.
This is still an issue, as you can see in sand, path blocks, gold blocks, and others.
Its more a matter of putting in the time to fix this issue at this point, than it is knowing how to fix it.
Uggghhhh, gotta love specific code for like 6 blocks in the entire game.
Grass, Snowy Grass, Warped Nylium, Crimsom Nylium Blocks and a couple others, use multiple texture lookups to draw the block.
So when it comes to Block Color and Detail Blurring, colors are blending into nothingness or the wrong color.
This is still an issue, and not exactly one I'm looking forward to fixing....