Skip to content

Commit 4801e2f

Browse files
committed
Rewrapping
1 parent 7401164 commit 4801e2f

File tree

1 file changed

+39
-31
lines changed

1 file changed

+39
-31
lines changed

content/news/044/index.md

+39-31
Original file line numberDiff line numberDiff line change
@@ -79,37 +79,45 @@ If needed, a section can be split into subsections with a "------" delimiter.
7979
### [rust-gpu-sdf]
8080

8181
![3d-distance-field](rust-gpu-sdf.gif)
82-
_An implicit surface defined compositionally, raymarched, and shaded entirely in Rust_
83-
84-
Announcing [rust-gpu-sdf], by [@Shfty]; a `no-std` signed distance field library designed for use across both CPU and GPU.
85-
86-
At time of writing, this library is the primary consumer of [bevy-rust-gpu], and is in a heavy-development pre-release state.
87-
Its main goal is to enumerate the distance field domain to the fullest extent allowed by Rust's type system;
88-
this covers a great many applications, such as collision detection, rendering, mesh generation,
89-
and volume modeling. And, contrary to its working title, is [rust-gpu]-agnostic, so can be used anywhere Rust can!
90-
91-
But what is a distance field? In short, it's a function that defines a shape in terms of its distance from a point.
92-
This can be used as an alternative to traditional meshing approaches in order to achieve perfectly smooth surfaces,
93-
the dynamic morphing depicted above, and many other effects that would traditionally require a powerful modeling package.
94-
95-
On paper, this also makes SDFs a great fit for accelerated rendering via GPU;
96-
a given distance function can be encoded directly in a shading language,
97-
and rendered by evaluating it on a per-fragment basis.
98-
In practice however, this presents a pipeline problem;
99-
distance fields (such as the ones found in [Inigo Quilez' excellent reference](inigo-quilez))
100-
are generally defined in mathematical form, i.e. as a single monolithic function.
101-
102-
Thus, in order to effectively leverage SDFs for CGI, an artist must also be both a competent mathematician
103-
and shader programmer. Even then, organization via abstraction eventually becomes necessary,
104-
which is often limited in shading languages. This is often solved by introducing a preprocessor,
105-
but forks away from the base language, introducing more machinery, specification,
106-
and points of failure to the process.
107-
108-
[rust-gpu] allows us to sidestep this problem, using Rust's language features
109-
to model powerful abstractions that can be compiled directly into SPIR-V.
110-
This is ideal for SDFs, since the algorithms involved can often be decomposed into reusable,
111-
generalizable operators that lend themselves well to functional composition.
112-
[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!
82+
_An implicit surface defined compositionally, raymarched, and shaded entirely in
83+
Rust_
84+
85+
Announcing [rust-gpu-sdf], by [@Shfty]; a `no-std` signed distance field library
86+
designed for use across both CPU and GPU.
87+
88+
At time of writing, this library is the primary consumer of [bevy-rust-gpu], and
89+
is in a heavy-development pre-release state. Its main goal is to enumerate the
90+
distance field domain to the fullest extent allowed by Rust's type system; this
91+
covers a great many applications, such as collision detection, rendering, mesh
92+
generation, and volume modeling. And, contrary to its working title, is
93+
[rust-gpu]-agnostic, so can be used anywhere Rust can!
94+
95+
But what is a distance field? In short, it's a function that defines a shape in
96+
terms of its distance from a point. This can be used as an alternative to
97+
traditional meshing approaches in order to achieve perfectly smooth surfaces,
98+
the dynamic morphing depicted above, and many other effects that would
99+
traditionally require a powerful modeling package.
100+
101+
On paper, this also makes SDFs a great fit for accelerated rendering via GPU; a
102+
given distance function can be encoded directly in a shading language, and
103+
rendered by evaluating it on a per-fragment basis. In practice however, this
104+
presents a pipeline problem; distance fields (such as the ones found in [Inigo
105+
Quilez' excellent reference][inigo-quilez]) are generally defined in
106+
mathematical form, i.e. as a single monolithic function.
107+
108+
Thus, in order to effectively leverage SDFs for CGI, an artist must also be both
109+
a competent mathematician and shader programmer. Even then, organization via
110+
abstraction eventually becomes necessary, which is often limited in shading
111+
languages. This is often solved by introducing a preprocessor, but forks away
112+
from the base language, introducing more machinery, specification, and points of
113+
failure to the process.
114+
115+
[rust-gpu] allows us to sidestep this problem, using Rust's language features to
116+
model powerful abstractions that can be compiled directly into SPIR-V. This is
117+
ideal for SDFs, since the algorithms involved can often be decomposed into
118+
reusable, generalizable operators that lend themselves well to functional
119+
composition. [rust-gpu-sdf] aims to do this, and provide a go-to library able to
120+
compose complex SDFs for any use-case. Watch this space!
113121

114122
[@Shfty]: https://github.com/Shfty
115123
[rust-gpu-sdf]: https://github.com/bevy-rust-gpu/rust-gpu-sdf

0 commit comments

Comments
 (0)