Add 3D rendering release notes

release-content/0.14/release-notes/12910_Implement_percentagecloser_filtering_PCF_for_point_lights.md

@@ -1 +1,8 @@
-TODO
+Percentage-closer filtering is a standard anti-aliasing technique used to get softer, less jagged shadows.
+To do so, we sample from the shadow map near the pixel of interest using a Gaussian kernel, averaging the results to reduce sudden transitions as we move in / out of the shadow.
+
+As a result, Bevy's point lights now  look softer and more natural, without any changes to end user code. As before, you can configure the exact strategy used to alias your shadows by setting the [`ShadowFilteringMethod`](https://dev-docs.bevyengine.org/bevy/pbr/enum.ShadowFilteringMethod.html) component on your 3D cameras.
+
+TODO: add image from https://github.com/bevyengine/bevy/pull/12910
+
+Full support for percentage-closer shadows is [in the works](https://github.com/bevyengine/bevy/pull/13497): testing and reviews for this are, like always, extremely welcome.

release-content/0.14/release-notes/12916_Implement_visibility_ranges_also_known_as_hierarchical_lev.md

@@ -1,4 +1,19 @@
 <!-- Implement visibility ranges, also known as hierarchical levels of detail (HLODs). -->
 <!-- https://github.com/bevyengine/bevy/pull/12916 -->
 
-<!-- TODO -->
+When looking at objects far away, it's hard to make out the details!
+This obvious fact is just as true in rendering as it is in real life.
+As a result, using complex, high-fidelity models for distant objects is a waste: we can replace them with simplified equivalents (whose lower resolution textures are called mipmaps).
+
+By automatically varying the **level-of-detail** (LOD) of our models in this way, we can render much larger scenes (or the same open world with a higher draw distance), swapping out models on the fly based on their proximity to the player.
+Bevy now supports one of the most foundational tools for this: **visibility ranges** (sometimes called hierarchical levels of detail, as it allows users to replace multiple meshes with a single object).
+
+By setting the `VisibilityRange` component on your model entities, developers can automatically control the range from the camera at which their models will appear and disappear, automatically fading between the two options using dithering.
+Hiding meshes happens early in the rendering pipeline, so this feature can be efficiently used for level of detail optimization.
+As a bonus, this feature is properly evaluated per-view, so different views can show different levels of detail.
+
+Note that this feature differs from proper mesh LODs (where the geometry itself is simplified automatically), which will come later.
+While mesh LODs are useful for optimization and don't require any additional setup, they're less flexible than visibility ranges.
+Games often want to use objects other than meshes to replace distant models, such as octahedral or [billboard](https://github.com/bevyengine/bevy/issues/3688) imposters: implementing visibility ranges first gives users the flexibility to start implementing these solutions today.
+
+You can see how this feature is used in the [`visibility_ranges` example](https://github.com/bevyengine/bevy/blob/main/examples/3d/visibility_range.rs).

release-content/0.14/release-notes/13009_Implement_fast_depth_of_field_as_a_postprocessing_effect.md

@@ -1 +1,12 @@
-TODO
+In rendering, **depth of field** is an effect that mimics the [limitations of physicals lenses]((https://en.wikipedia.org/wiki/Depth_of_field)).
+By virtue of the way light works, lens (like that of the human eye or a film camera) can only focus on objects that are within a specific range (depth) from them, causing all others to be blurry and out of focus.
+
+Bevy now ships with this effect, implemented as a post-processing shader.
+There are two options available: a fast Gaussian blur or a more physically accurate hexagonal bokeh technique.
+The bokeh blur is generally more aesthetically pleasing than the Gaussian blur, as it simulates the effect of a camera more accurately. The shape of the bokeh circles are determined by the number of blades of the aperture. In our case, we use a hexagon, which is usually considered specific to lower-quality cameras.
+
+TODO: add image
+
+The blur amount is generally specified by the [f-number](https://en.wikipedia.org/wiki/F-number), which we use to compute the [focal length](https://en.wikipedia.org/wiki/Focal_length) from the film size and [field-of-view](https://en.wikipedia.org/wiki/Field_of_view). By default, we simulate standard cinematic cameras with an f/1 f-number and a film size corresponding to the classic Super 35 camera. The developer can customize these values as desired.
+
+To see how this new API, please check out the dedicated [`depth_of_field` example](https://github.com/bevyengine/bevy/blob/main/examples/3d/depth_of_field.rs).

release-content/0.14/release-notes/13057_Implement_volumetric_fog_and_volumetric_lighting_also_know.md

@@ -1 +1,13 @@
-TODO
+Not all fog is created equal.
+Bevy's existing implementation covers [distance fog](https://en.wikipedia.org/wiki/Distance_fog), which is fast, simple and not particularly realistic.
+
+In Bevy 0.14, this is supplemented with volumetric fog, based on [volumetric lighting](https://en.wikipedia.org/wiki/Volumetric_lighting), which simulates fog using actual 3D space, rather than simply distance from the camera.
+As you might expect, this is both prettier and more computationally expensive!
+
+In particular, this allows for the creation of stunningly beautiful "god rays" (light shafts) shining through the fog.
+
+TODO: add image.
+
+Bevy's algorithm, which is implemented as a postprocessing effect, is a combination of the techniques described in [Scratchapixel](https://www.scratchapixel.com/lessons/3d-basic-rendering/volume-rendering-for-developers/intro-volume-rendering.html) and [Alexandre Pestana's blog post](https://www.alexandre-pestana.com/volumetric-lights/). It uses raymarching in screen space, transformed into shadow map space for sampling and combined with physically-based modeling of absorption and scattering. Bevy employs the widely-used Henyey-Greenstein phase function to model asymmetry; this essentially allows light shafts to fade into and out of existence as the user views them.
+
+To add volumetric fog to a scene, add `VolumetricFogSettings` to the camera, and add `VolumetricLight` to directional lights that you wish to be volumetric. `VolumetricFogSettings` has numerous settings that allow you to define the accuracy of the simulation, as well as the look of the fog. Currently, only interaction with directional lights that have shadow maps is supported. Note that the overhead of the effect scales directly with the number of directional lights in use, so apply `VolumetricLight` sparingly for the best results.

release-content/0.14/release-notes/13121_Implement_filmic_color_grading.md

@@ -1,4 +1,16 @@
 <!-- Implement filmic color grading. -->
 <!-- https://github.com/bevyengine/bevy/pull/13121 -->
 
-<!-- TODO -->
+Artists want to get exactly the right look for their game, and color plays a huge role.
+
+To support this, Bevy's [existing tonemapping tools](https://bevyengine.org/news/bevy-0-10/#more-tonemapping-choices) have been extended to include a complete set of filmic color grading tools. In addition to a [base tonemap](https://dev-docs.bevyengine.org/bevy/core_pipeline/tonemapping/enum.Tonemapping.html), you can now configure:
+
+- White point adjustment. This is inspired by Unity's implementation of the feature, but simplified and optimized. Temperature and tint control the adjustments to the x and y chromaticity values of CIE 1931. Following Unity, the adjustments are made relative to the D65 standard illuminant in the LMS color space.
+- Hue rotation: converts the RGB value to HSV, alters the hue, and converts back.
+- Color correction: allows the gamma, gain, and lift values to be adjusted according to the standard ASC CDL combined function. This can be done seperately for shadows, midtones and highlights To avoid abrupt color changes, a small crossfade is used between the different sections of the image.
+
+We've followed [Blender's](https://www.blender.org/) implementation as closely as possible to ensure that what you see in your modelling software matches what you see in the game.
+
+We've provided a new, [`color_grading`](https://github.com/bevyengine/bevy/blob/main/examples/3d/color_grading.rs) example, with a shiny GUI to change all the color grading settings.
+Perfect for copy-pasting into your own game's dev tools and playing with the settings!
+Note that these settings can all be changed at runtime: giving artists control over the exact mood of the scene, or shift it dynamically based on weather or time of day.

release-content/0.14/release-notes/13423_Implement_subpixel_morphological_antialiasing_or_SMAA.md

@@ -2,3 +2,13 @@
 <!-- https://github.com/bevyengine/bevy/pull/13423 -->
 
 <!-- TODO -->
+
+Jagged edges are the bane of game developers' existence: a wide variety of anti-aliasing techniques have been invented and are still in use to fix them without degrading image quality.
+In addition to [MSAA](https://en.wikipedia.org/wiki/Multisample_anti-aliasing), [FXAA](https://en.wikipedia.org/wiki/Fast_approximate_anti-aliasing) and [TAA](https://en.wikipedia.org/wiki/Temporal_anti-aliasing), Bevy now implements [SMAA](https://en.wikipedia.org/wiki/Morphological_antialiasing): subpixel morphological antialiasing.
+
+SMAA is a 2011 antialiasing technique that detects borders in the image, then averages nearby border pixels, eliminating the dreaded jaggies.
+Despite its age, it's been a continual staple of games for over a decade. Four quality presets are available: low, medium, high, and ultra. Due to advancements in consumer hardware, Bevy's default is high.
+
+While you can see the differences in the image below, the best way to get a sense for it is to experiment with a test scene using the [`anti_aliasing` example](https://github.com/bevyengine/bevy/blob/main/examples/3d/anti_aliasing.rs) or trying it out in your own game.
+
+TODO: add image comparing AA techniques

release-content/0.14/release-notes/13450_Implement_PBR_anisotropy_per_KHR_materials_anisotropy.md

@@ -1,4 +1,10 @@
 <!-- Implement PBR anisotropy per `KHR_materials_anisotropy`. -->
 <!-- https://github.com/bevyengine/bevy/pull/13450 -->
 
-<!-- TODO -->
+> This commit implements support for physically-based anisotropy in Bevy's StandardMaterial, following the specification for the KHR_materials_anisotropy glTF extension.
+
+> Anisotropy (not to be confused with anisotropic filtering) is a PBR feature that allows roughness to vary along the tangent and bitangent directions of a mesh. In effect, this causes the specular light to stretch out into lines instead of a round lobe. This is useful for modeling brushed metal, hair, and similar surfaces. Support for anisotropy is a common feature in major game and graphics engines; Unity, Unreal, Godot, three.js, and Blender all support it to varying degrees.
+
+> Two new parameters have been added to StandardMaterial: anisotropy_strength and anisotropy_rotation. Anisotropy strength, which ranges from 0 to 1, represents how much the roughness differs between the tangent and the bitangent of the mesh. In effect, it controls how stretched the specular highlight is. Anisotropy rotation allows the roughness direction to differ from the tangent of the model.
+
+> In addition to these two fixed parameters, an anisotropy texture can be supplied. Such a texture should be a 3-channel RGB texture, where the red and green values specify a direction vector using the same conventions as a normal map ([0, 1] color values map to [-1, 1] vector values), and the the blue value represents the strength. This matches the format that the KHR_materials_anisotropy specification requires. Such textures should be loaded as linear and not sRGB. Note that this texture does consume one additional texture binding in the standard material shader.

release-content/0.14/release-notes/9924_PerObject_Motion_Blur.md

@@ -1 +1 @@
-TODO
+> This is a post-process effect that uses the depth and motion vector buffers to estimate per-object motion blur. The implementation is combined from knowledge from multiple papers and articles. The approach itself, and the shader are quite simple. Most of the effort was in wiring up the bevy rendering plumbing, and properly specializing for HDR and MSAA.