Rendering principles

The functionality of All is Cubes’s two renderers (`all_is_cubes_render::raytracer` and `all_is_cubes_gpu`) is of course limited by what I have knowledge and time to implement, and what fits within the capabilities of the platforms I want to target. But besides that, it is also constrained by what I think makes a good picture. * Currently, there are no screen-space effects except for bloom. There is no screen-space ambient occlusion (SSAO), no pseudo-antialiasing (FXAA, etc.), no motion blur, and above all, no temporal accumulation. In general, I reject these kinds of effects because they create artifacts which shift as the camera or objects move, which I personally find highly distracting and unpleasant. (However, pome of these might make sense to add later, as non-default options for users to enable if they wish, but they are not priorities.) * I’ve spent a lot of effort on making `all_is_cubes_mesh` generate meshes that have no T-junctions and will therefore never render with single-pixel gaps in edges that should meet. Besides correctness in the abstract, this is also intended to make sure there are not noticeable light spots visible inside of dark areas. * The entire system of computing and storing light data in the world itself, which was of course inspired by Minecraft, serves to provide lighting that is completely stable as the camera moves because it is tied to the world and not the screen. (However, as per #641, I am also interested in providing full path tracing as an *option* and a development tool, to see what things look like without the approximation of only one light value per cube.) All of these individual choices align with prioritizing accurate depiction of the *shapes* in the world, to allow the user to comprehend them, over other considerations that might be more aesthetic or realistic. From the Bevy Discord, pcwalton told me about “The Sane Rendering Manifesto” ([text](https://gist.github.com/bazhenovc/c0aa56cdf50df495fda84de58ef1de5e), [video](https://www.youtube.com/watch?v=KwiwIbjcjW4)), which is a notably similar perspective from an independent source. Its headline points are: * “Do not use dynamic resolution [or fractional upscaling].” * “Do not render at lower refresh rates.” * “Do not use temporal amortization.” Half of these points are things I never would have considered doing anyway, but if you look at the details, the motivations are very similar to my own. I would particularly note: > These rules highly prioritize image clarity/stability and pleasant gameplay experience over photorealism and excess graphics fidelity. > Low refresh rates (under 60Hz) increase input latency and make the gameplay experience worse for the player. > You are making a game, make sure it looks great in motion first and foremost. ---- Now, at least, that’s all written down when it wasn’t, but these thoughts belong in some sort of design document, or possibly even the library documentation; that’s the condition for closing this issue. Note that these design choices aren’t just about “what does the renderer do” — they also inform what fields should be present in `all_is_cubes::block::Atom`, and thus what is possible to ask the renderer to do.