What went well:

* uploaded a project to itch for the first time

* got the shaders and executable working well

What could have gone better:

* pulling my hair out with matrix math for matrices I don't know anything about

* actually knowing what I'm doing

What I learned:

* Once you know how to write in shaders, practicing it gives you a better feel for what you can do. There's tons of cool things that can be done, literally anything you can imagine. Putting in a bit of time and care into the shaders of a game is how you create visual intrigue and a unique identity. Shaders are cool.

Full story:

I began working on this little shader sample after hitting a block in the development of my own game and being inspired by Doom The Dark Ages to make something retro.

In development, these shaders caused me lots of headaches, starting off with just trying to get the distance to work. Fragments are relative to the screen, so trying to get things back in world space for distance requires matrix calculations that I don't quite understand. lots of trial and error to get things into the right spaces and make and black magic work right. First it was by world space z direction, then it was snapping to  objects and not smoothly transitioning. The Model Matrix is not always your friend. 

Finally, after lots of hair-pulling and googling, the first version of the shader was basically done: the Automatic Real distance based mips. After this I went ahead and made a modification of the code to handle 5 textures and change between them linearly, however things weren't lining up when the two shaders had the same parameters and were lined up side by side. So then I had to re-figure out how to put the linear interpolation in the lod factor into log base 2 terms.

After all that, Things were lined up. the UV's were quantized, it interpolated wonderfully, but.. it was circular. that was not ideal. I mean, if we visualize the distance falloffs for mipmapping, they are spheres, but DOOM didn't have any circles like that. Odd

When I first realized this, I did not visualize it in 3D or try to understand why it was making circles logically. I tried to take the screen space circles and use functions and formulas and math to make them squares. That did not work. So, taking a step back, I realized "wow I'm an idiot"

Really, all I had to do was find the distance from the camera's plane to an object but how do I get the camera plane? I know -basis.z gives me that in gdscript but I can't have gdscript, it all has to be in the shader.  Maybe a screen space depth effect? fragment coordinates? (fragment coordinates did not work). Apparantly, in the fragment portion of the shader, -VERTEX.z is the depth of the pixel in relation to the camera. who knew, right? Using that, the logic for the automatic and manual plane distance shaders was a line short and several arithmetic operations faster per frame pixel than the real distance 

Making the map for testing out the shaders, importing, and most importantly, having everything imported saved locally so I could change the materials was probably the most tedious part of the whole process. It may be more effective to create modular asset models, apply shaders to just these individual pieces or tiles, and then make the map from those instead of making the whole map in blender and then importing as multiple large chunks that each need a different shader