You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## `mesh_to_sdf`: Convert a mesh to a signed distance field (SDF).
26
26
27
-
⚠️ This crate is still in its early stages. Expect the API to change.
28
-
29
-
---
30
-
31
27
This crate provides two entry points:
32
28
33
29
-[`generate_sdf`]: computes the signed distance field for the mesh defined by `vertices` and `indices` at the points `query_points`.
@@ -47,9 +43,8 @@ let sdf: Vec<f32> = generate_sdf(
47
43
&vertices,
48
44
Topology::TriangleList(Some(&indices)), // TriangleList as opposed to TriangleStrip
49
45
&query_points,
50
-
AccelerationMethod::Bvh, // Use bvh to accelerate queries.
51
-
SignMethod::Raycast, // How the sign is computed.
52
-
); // Raycast is robust but requires the mesh to be watertight.
46
+
AccelerationMethod::RtreeBvh, // Use an r-tree and a bvh to accelerate queries.
47
+
);
53
48
54
49
forpointinquery_points.iter().zip(sdf.iter()) {
55
50
// distance is positive outside the mesh and negative inside.
@@ -67,9 +62,11 @@ let sdf: Vec<f32> = generate_grid_sdf(
67
62
&vertices,
68
63
Topology::TriangleList(Some(&indices)),
69
64
&grid,
70
-
SignMethod::Normal, // How the sign is computed.
71
-
); // Normal might leak negative distances outside the mesh
72
-
// but works for all meshes, even surfaces.
65
+
SignMethod::Raycast, // How the sign is computed.
66
+
// Raycast is robust but requires the mesh to be watertight.
67
+
// and is more expensive.
68
+
// Normal might leak negative distances outside the mesh
69
+
); // but works for all meshes, even surfaces.
73
70
74
71
forxin0..cell_count[0] {
75
72
foryin0..cell_count[1] {
@@ -89,7 +86,7 @@ Indices can be of any type that implements `Into<u32>`, e.g. `u16` and `u32`. To
89
86
If the indices are not provided, they are supposed to be `0..vertices.len()`.
90
87
91
88
For vertices, this library aims to be as generic as possible by providing a trait `Point` that can be implemented for any type.
92
-
Implementations for most common math libraries are gated behind feature flags. By default, only `[f32; 3]`is provided.
89
+
Implementations for most common math libraries are gated behind feature flags. By default, `[f32; 3]`and `nalgebra::[Point3, Vector3]` are provided.
93
90
If you do not find your favorite library, feel free to implement the trait for it and submit a PR or open an issue.
94
91
95
92
---
@@ -102,9 +99,26 @@ This crate provides two methods to compute the sign of the distance:
102
99
-[`SignMethod::Normal`]: uses the normals of the triangles to estimate the sign by doing a dot product with the direction of the query point.
103
100
It works for non-watertight meshes but might leak negative distances outside the mesh.
104
101
105
-
For grid generation, `Raycast` is ~1% slower.
106
-
For query points, `Raycast` is ~10% slower.
107
-
Note that it depends on the query points / grid size to triangle ratio, but this gives a rough idea.
102
+
Using `Raycast` is slower than `Normal` but gives better results. Performances depends on the triangle count and method used.
103
+
On big dataset, `Raycast` is 5-10% slower for grid generation and rtree based methods. On smaller dataset, the difference can be worse
104
+
depending on whether the query is triangle intensive or query point intensive.
105
+
For bvh the difference is negligible between the two methods.
106
+
107
+
---
108
+
109
+
##### Acceleration structures
110
+
111
+
For generic queries, you can use acceleration structures to speed up the computation.
112
+
-[`AccelerationMethod::None`]: no acceleration structure. This is the slowest method but requires no extra memory. Scales really poorly.
113
+
-[`AccelerationMethod::Bvh`]: Bounding Volume Hierarchy. Accepts a `SignMethod`.
114
+
-[`AccelerationMethod::Rtree`]: R-tree. Uses `SignMethod::Normal`. The fastest method assuming you have more than a couple thousands of queries.
115
+
-[`AccelerationMethod::RtreeBvh`] (default): Uses R-tree for nearest neighbor search and Bvh for `SignMethod::Raycast`. 5-10% slower than `Rtree` on big datasets.
116
+
117
+
If your mesh is watertight and you have more than a thousand queries/triangles, you should use `AccelerationMethod::RtreeBvh` for best performances.
118
+
If it's not watertight, you can use `AccelerationMethod::Rtree` instead.
119
+
120
+
`Rtree` methods are 3-4x faster than `Bvh` methods for big enough data. On small meshes, the difference is negligible.
121
+
`AccelerationMethod::None` scales really poorly and should be avoided unless for small datasets or if you're really tight on memory.
108
122
109
123
---
110
124
@@ -123,25 +137,15 @@ Currently, the following libraries are supported:
123
137
-[nalgebra] ([`nalgebra::Vector3<f32>`] and [`nalgebra::Point3<f32>`])
124
138
-`[f32; 3]`
125
139
140
+
[nalgebra] is always available as it's used internally in the bvh tree.
141
+
126
142
---
127
143
128
144
##### Serialization
129
145
130
146
If you want to serialize and deserialize signed distance fields, you need to enable the `serde` feature.
131
147
This features also provides helpers to save and load signed distance fields to and from files via `save_to_file` and `read_from_file`.
132
148
133
-
---
134
-
135
-
##### Benchmarks
136
-
137
-
[`generate_grid_sdf`] is much faster than [`generate_sdf`] and should be used whenever possible.
138
-
[`generate_sdf`] does not allocate memory (except for the result array) but is slow. A faster implementation is planned for the future.
139
-
140
-
[`SignMethod::Raycast`] is slightly slower than [`SignMethod::Normal`] but is robust and should be used whenever possible (~1% in [`generate_grid_sdf`], ~10% in [`generate_sdf`]).
141
-
142
-
---
143
-
144
-
TODO: Add benchmarks against other libraries.
145
149
146
150
## `mesh_to_sdf_client` Mesh to SDF visualization client.
Copy file name to clipboardexpand all lines: mesh_to_sdf/README.md
+17-22
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,5 @@
1
1
# mesh_to_sdf
2
2
3
-
⚠️ This crate is still in its early stages. Expect the API to change.
4
-
5
-
---
6
-
7
3
This crate provides two entry points:
8
4
9
5
-[`generate_sdf`]: computes the signed distance field for the mesh defined by `vertices` and `indices` at the points `query_points`.
@@ -42,9 +38,11 @@ let sdf: Vec<f32> = generate_grid_sdf(
42
38
&vertices,
43
39
Topology::TriangleList(Some(&indices)),
44
40
&grid,
45
-
SignMethod::Normal, // How the sign is computed.
46
-
); // Normal might leak negative distances outside the mesh
47
-
// but works for all meshes, even surfaces.
41
+
SignMethod::Raycast, // How the sign is computed.
42
+
// Raycast is robust but requires the mesh to be watertight.
43
+
// and is more expensive.
44
+
// Normal might leak negative distances outside the mesh
45
+
); // but works for all meshes, even surfaces.
48
46
49
47
forxin0..cell_count[0] {
50
48
foryin0..cell_count[1] {
@@ -64,7 +62,7 @@ Indices can be of any type that implements `Into<u32>`, e.g. `u16` and `u32`. To
64
62
If the indices are not provided, they are supposed to be `0..vertices.len()`.
65
63
66
64
For vertices, this library aims to be as generic as possible by providing a trait `Point` that can be implemented for any type.
67
-
Implementations for most common math libraries are gated behind feature flags. By default, only `[f32; 3]`is provided.
65
+
Implementations for most common math libraries are gated behind feature flags. By default, `[f32; 3]`and `nalgebra::[Point3, Vector3]` are provided.
68
66
If you do not find your favorite library, feel free to implement the trait for it and submit a PR or open an issue.
69
67
70
68
---
@@ -77,22 +75,26 @@ This crate provides two methods to compute the sign of the distance:
77
75
-[`SignMethod::Normal`]: uses the normals of the triangles to estimate the sign by doing a dot product with the direction of the query point.
78
76
It works for non-watertight meshes but might leak negative distances outside the mesh.
79
77
80
-
Both methods have roughly the same performances, depending on the acceleration structure used for generic queries.
78
+
Using `Raycast` is slower than `Normal` but gives better results. Performances depends on the triangle count and method used.
79
+
On big dataset, `Raycast` is 5-10% slower for grid generation and rtree based methods. On smaller dataset, the difference can be worse
80
+
depending on whether the query is triangle intensive or query point intensive.
81
+
For bvh the difference is negligible between the two methods.
81
82
82
83
---
83
84
84
85
##### Acceleration structures
85
86
86
87
For generic queries, you can use acceleration structures to speed up the computation.
87
-
-[`AccelerationMethod::None`]: no acceleration structure. This is the slowest method but requires no extra memory.
88
+
-[`AccelerationMethod::None`]: no acceleration structure. This is the slowest method but requires no extra memory. Scales really poorly.
88
89
-[`AccelerationMethod::Bvh`]: Bounding Volume Hierarchy. Accepts a `SignMethod`.
89
-
-[`AccelerationMethod::Rtree`]: R-tree. Only compatible with`SignMethod::Normal`. The fastest method assuming you have more than a couple thousands of queries.
90
-
-[`AccelerationMethod::RtreeBvh`] (default): Uses R-tree for nearest neighbor search and Bvh for raycasting.
90
+
-[`AccelerationMethod::Rtree`]: R-tree. Uses`SignMethod::Normal`. The fastest method assuming you have more than a couple thousands of queries.
91
+
-[`AccelerationMethod::RtreeBvh`] (default): Uses R-tree for nearest neighbor search and Bvh for `SignMethod::Raycast`. 5-10% slower than `Rtree` on big datasets.
91
92
92
93
If your mesh is watertight and you have more than a thousand queries/triangles, you should use `AccelerationMethod::RtreeBvh` for best performances.
93
94
If it's not watertight, you can use `AccelerationMethod::Rtree` instead.
94
95
95
-
`Rtree` methods are ~4x faster than `Bvh` methods for big enough data. `AccelerationMethod::None` scales really poorly and should be avoided unless for small datasets or if you're really tight on memory.
96
+
`Rtree` methods are 3-4x faster than `Bvh` methods for big enough data. On small meshes, the difference is negligible.
97
+
`AccelerationMethod::None` scales really poorly and should be avoided unless for small datasets or if you're really tight on memory.
96
98
97
99
---
98
100
@@ -111,20 +113,13 @@ Currently, the following libraries are supported:
111
113
-[nalgebra] ([`nalgebra::Vector3<f32>`] and [`nalgebra::Point3<f32>`])
112
114
-`[f32; 3]`
113
115
116
+
[nalgebra] is always available as it's used internally in the bvh tree.
117
+
114
118
---
115
119
116
120
##### Serialization
117
121
118
122
If you want to serialize and deserialize signed distance fields, you need to enable the `serde` feature.
119
123
This features also provides helpers to save and load signed distance fields to and from files via `save_to_file` and `read_from_file`.
120
124
121
-
---
122
-
123
-
##### Benchmarks
124
-
125
-
[`generate_grid_sdf`] is much faster than [`generate_sdf`] and should be used whenever possible.
126
-
[`generate_sdf`] does not allocate memory (except for the result array) but is slow. A faster implementation is planned for the future.
127
-
128
-
[`SignMethod::Raycast`] is slightly slower than [`SignMethod::Normal`] but is robust and should be used whenever possible (~1% in [`generate_grid_sdf`], ~10% in [`generate_sdf`]).
0 commit comments