Rewrapping

content/news/044/index.md

@@ -79,37 +79,45 @@ If needed, a section can be split into subsections with a "------" delimiter.
 ### [rust-gpu-sdf]
 
 ![3d-distance-field](rust-gpu-sdf.gif)
-_An implicit surface defined compositionally, raymarched, and shaded entirely in Rust_
-
-Announcing [rust-gpu-sdf], by [@Shfty]; a `no-std` signed distance field library designed for use across both CPU and GPU.
-
-At time of writing, this library is the primary consumer of [bevy-rust-gpu], and is in a heavy-development pre-release state.
-Its main goal is to enumerate the distance field domain to the fullest extent allowed by Rust's type system;
-this covers a great many applications, such as collision detection, rendering, mesh generation,
-and volume modeling. And, contrary to its working title, is [rust-gpu]-agnostic, so can be used anywhere Rust can!
-
-But what is a distance field? In short, it's a function that defines a shape in terms of its distance from a point.
-This can be used as an alternative to traditional meshing approaches in order to achieve perfectly smooth surfaces,
-the dynamic morphing depicted above, and many other effects that would traditionally require a powerful modeling package.
-
-On paper, this also makes SDFs a great fit for accelerated rendering via GPU;
-a given distance function can be encoded directly in a shading language,
-and rendered by evaluating it on a per-fragment basis.
-In practice however, this presents a pipeline problem;
-distance fields (such as the ones found in [Inigo Quilez' excellent reference](inigo-quilez))
-are generally defined in mathematical form, i.e. as a single monolithic function.
-
-Thus, in order to effectively leverage SDFs for CGI, an artist must also be both a competent mathematician
-and shader programmer. Even then, organization via abstraction eventually becomes necessary,
-which is often limited in shading languages. This is often solved by introducing a preprocessor,
-but forks away from the base language, introducing more machinery, specification,
-and points of failure to the process.
-
-[rust-gpu] allows us to sidestep this problem, using Rust's language features
-to model powerful abstractions that can be compiled directly into SPIR-V.
-This is ideal for SDFs, since the algorithms involved can often be decomposed into reusable,
-generalizable operators that lend themselves well to functional composition.
-[rust-gpu-sdf] aims to do this, and provide a go-to library able to compose complex SDFs for any use-case. Watch this space!
+_An implicit surface defined compositionally, raymarched, and shaded entirely in
+Rust_
+
+Announcing [rust-gpu-sdf], by [@Shfty]; a `no-std` signed distance field library
+designed for use across both CPU and GPU.
+
+At time of writing, this library is the primary consumer of [bevy-rust-gpu], and
+is in a heavy-development pre-release state. Its main goal is to enumerate the
+distance field domain to the fullest extent allowed by Rust's type system; this
+covers a great many applications, such as collision detection, rendering, mesh
+generation, and volume modeling. And, contrary to its working title, is
+[rust-gpu]-agnostic, so can be used anywhere Rust can!
+
+But what is a distance field? In short, it's a function that defines a shape in
+terms of its distance from a point. This can be used as an alternative to
+traditional meshing approaches in order to achieve perfectly smooth surfaces,
+the dynamic morphing depicted above, and many other effects that would
+traditionally require a powerful modeling package.
+
+On paper, this also makes SDFs a great fit for accelerated rendering via GPU; a
+given distance function can be encoded directly in a shading language, and
+rendered by evaluating it on a per-fragment basis. In practice however, this
+presents a pipeline problem; distance fields (such as the ones found in [Inigo
+Quilez' excellent reference][inigo-quilez]) are generally defined in
+mathematical form, i.e. as a single monolithic function.
+
+Thus, in order to effectively leverage SDFs for CGI, an artist must also be both
+a competent mathematician and shader programmer. Even then, organization via
+abstraction eventually becomes necessary, which is often limited in shading
+languages. This is often solved by introducing a preprocessor, but forks away
+from the base language, introducing more machinery, specification, and points of
+failure to the process.
+
+[rust-gpu] allows us to sidestep this problem, using Rust's language features to
+model powerful abstractions that can be compiled directly into SPIR-V. This is
+ideal for SDFs, since the algorithms involved can often be decomposed into
+reusable, generalizable operators that lend themselves well to functional
+composition. [rust-gpu-sdf] aims to do this, and provide a go-to library able to
+compose complex SDFs for any use-case. Watch this space!
 
 [@Shfty]: https://github.com/Shfty
 [rust-gpu-sdf]: https://github.com/bevy-rust-gpu/rust-gpu-sdf