swiftcoder
diff --git a/‎Cargo.toml
Lines changed: 1 addition & 1 deletion b/‎Cargo.toml
Lines changed: 1 addition & 1 deletion
diff --git a/‎README.md
Lines changed: 5 additions & 2 deletions b/‎README.md
Lines changed: 5 additions & 2 deletions
diff --git a/‎examples/common/mod.rs
Lines changed: 27 additions & 0 deletions b/‎examples/common/mod.rs
Lines changed: 27 additions & 0 deletions
diff --git a/‎examples/common/sources.rs
Lines changed: 34 additions & 0 deletions b/‎examples/common/sources.rs
Lines changed: 34 additions & 0 deletions
@@ -1,6 +1,6 @@
 [package]
 name = "isosurface"
-version = "0.0.1"
+version = "0.0.2"
 authors = ["Tristam MacDonald <swiftcoder@gmail.com>"]
 license = "Apache-2.0"
 description = "Isosurface extraction algorithms"
 
@@ -1,5 +1,5 @@
 # Isosurface
-Isosurface extraction algorithms for Rust. Currently only Marching Cubes is implemented, fancier algorithms to be added at a later date.
+Isosurface extraction algorithms for Rust. Currently only a few techniques are implemented, fancier algorithms to be added at a later date.
 
 This crate has no dependencies, although the example relies on the glium, cgmath, num crates.
 
@@ -10,7 +10,10 @@ The implementation has been optimised for performance, with memory use kept as a
 
 Indices are 32-bit becuase for chunks of 32x32 and larger you'll typically end up with mor than 65k vertices. If you are targetting a mobile platform that supports only 16-bit indices, you'll need to use smaller chunk sizes, and truncate on the output side.
 
+# Point Clouds and Deferred Rasterisation
+Point cloud extraction is typically not all that useful, given that point clouds don't contain any data about the actual surface. However, Gavan Woolery (gavanw@) posted an interesting image of reconstructing surface data in image space on the GPU, so I've added a simple example of that.  
+
 # Why are optimisations enabled in debug builds?
 Without optimisations enabled, debug builds are 70x slower (1 minute to extract a 256^3 volume, versus ~800 milliseconds). 
 
-This implementation relies on a lot of nested for loops over integer ranges, and the range iterators themselves entirely dominate the CPU profiles in unoptimised builds. While this could likely be worked around by converting the `for 0..8` style of loop to a while loop with manual counter, that seems ugly and distinctly not in the spirit of rust. I'd rather leave optimisations enabled, and wait for the compiler to become better at handling iterators.
+The marching cubes implementation relies on a lot of nested for loops over integer ranges, and the range iterators themselves entirely dominate the CPU profiles in unoptimised builds. While this could likely be worked around by converting the `for 0..8` style of loop to a while loop with manual counter, that seems ugly and distinctly not in the spirit of rust. I'd rather leave optimisations enabled, and wait for the compiler to become better at handling iterators.
@@ -0,0 +1,27 @@
+// Copyright 2017 Tristam MacDonald
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+pub mod sources;
+
+use std::slice;
+
+/// This is used to reinterpret slices of floats as slices of repr(C) structs, without any
+/// copying. It is optimal, but it is also punching holes in the type system. I hope that Rust
+/// provides safe functionality to handle this in the future. In the meantime, reproduce
+/// this workaround at your own risk.
+pub fn reinterpret_cast_slice<S, T>(input : &[S], length : usize) -> &[T] {
+    unsafe {
+        slice::from_raw_parts(input.as_ptr() as *const T, length)
+    }
+}
@@ -0,0 +1,34 @@
+// Copyright 2017 Tristam MacDonald
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+//! Isosurface definitions for use in multiple examples
+
+use isosurface;
+
+/// The distance-field equation for a torus
+fn torus(x : f32, y : f32, z : f32) -> f32 {
+    const R1 : f32 = 1.0 / 4.0;
+    const R2 : f32 = 1.0 / 10.0;
+    let q_x = ((x*x + y*y).sqrt()).abs() - R1;
+    let len = (q_x*q_x + z*z).sqrt();
+    len - R2
+}
+
+pub struct Torus {}
+
+impl isosurface::source::Source for Torus {
+    fn sample(&self, x : f32, y : f32, z : f32) -> f32 {
+        torus(x - 0.5, y - 0.5, z - 0.5)
+    }
+}