Add 3D rendering release notes

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

@@ -1 +1,13 @@
-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 anti-alias your shadows by setting the [`ShadowFilteringMethod`](https://dev-docs.bevyengine.org/bevy/pbr/enum.ShadowFilteringMethod.html) component on your 3D cameras.
+
+{{ compare_slider(
+    left_title="Without PCF filtering",
+    left_image="before_pcf.png",
+    right_title="With PCF filtering",
+    right_image="after_pcf.png"
+) }}
+
+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 their meshes with simplified equivalents.
+
+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 meshes 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 mesh entities, developers can automatically control the range from the camera at which their meshes 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,17 @@
-TODO
+In rendering, **depth of field** is an effect that mimics the [limitations of physical lenses]((https://en.wikipedia.org/wiki/Depth_of_field)).
+By virtue of the way light works, lenses (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.
+
+{{ compare_slider(
+    left_title="No Depth of Field",
+    left_image="no_dof.png",
+    right_title="Bokeh Depth of Field",
+    right_image="bokeh_dof.png"
+) }}
+
+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 film format. 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,20 @@
-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" (more properly, crepuscular rays) shining through the fog.
+
+{{ compare_slider(
+    left_title="Without Volumetric Fog",
+    left_image="without_volumetric_fog.png",
+    right_title="With Volumetric Fog",
+    right_image="with_volumetric_fog.png"
+) }}
+
+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 ([ported to WGSL by h3r2tic](https://gist.github.com/h3r2tic/9c8356bdaefbe80b1a22ae0aaee192db)) 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.
+
+Try it hands on with our [`volumetric_fog` example](https://github.com/bevyengine/bevy/blob/main/examples/3d/volumetric_fog.rs).

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

@@ -1,4 +1,18 @@
 <!-- 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 separately 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.
+
+![A very orange image of a test scene, with controls for exposure, temperature, tint and hue. Saturation, contrast, gamma, gain, and lift can all be configured for the highlights, midtones, and shadows separately.](filmic_color_grading.png)
+
+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

@@ -1,4 +1,10 @@
 <!-- Implement subpixel morphological antialiasing, or SMAA. -->
 <!-- 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.

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

@@ -1,4 +1,26 @@
 <!-- Implement PBR anisotropy per `KHR_materials_anisotropy`. -->
 <!-- https://github.com/bevyengine/bevy/pull/13450 -->
 
-<!-- TODO -->
+[Anisotropic materials](https://en.wikipedia.org/wiki/Anisotropy) change based on the axis of motion, such as how wood behaves very differently when working with versus against the grain.
+But in the context of phsically-based rendering, **anisotropy** refers specifically to a 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.
+
+{{ compare_slider(
+    left_title="Without Anisotropy",
+    left_image="without_anisotropy.png",
+    right_title="With Anisotropy",
+    right_image="with_anisotropy.png"
+) }}
+
+Two new parameters have been added to [`StandardMaterial`](https://dev-docs.bevyengine.org/bevy/pbr/struct.StandardMaterial.html): `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 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.
+
+Like always, give it a spin at the corresponding [`anisotropy` example](https://github.com/bevyengine/bevy/blob/main/examples/3d/anisotropy.rs).

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

@@ -1 +1,14 @@
-TODO
+We've added a post-processing effect that blurs fast-moving objects in the direction of motion.
+Our implementation uses motion vectors, which means it works with Bevy's built in PBR materials, skinned meshes, or anything else that writes motion vectors and depth.
+The effect is used to convey high speed motion, which can otherwise look like flickering or teleporting when the image is perfectly sharp.
+
+Blur scales with the motion of objects relative to the camera.
+If the camera is tracking a fast moving object, like a vehicle, the vehicle will remain sharp, while stationary objects will be blurred.
+Conversely, if the camera is pointing at a stationary object, and a fast moving vehicle moves through the frame, only the fast moving object will be blurred.
+
+The implementation is configured with [camera shutter angle](https://en.wikipedia.org/wiki/Rotary_disc_shutter), which corresponds to how long the virtual shutter is open during a frame.
+In practice, this means the effect scales with framerate, so users running at high refresh rates aren't subjected to over-blurring.
+
+![A series of cartoony cars whiz past low polygon trees. The trees and the cars blur as the camera moves, with faster objects (relative to the field of vision) blurring more.](motion_blur_cars.mp4)
+
+You can enable motion blur by adding [`MotionBlurBundle`](https://dev-docs.bevyengine.org/bevy/core_pipeline/motion_blur/struct.MotionBlurBundle.html) to your camera entity, as shown in our [`motion blur` example](https://github.com/bevyengine/bevy/blob/main/examples/3d/motion_blur.rs).