-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better STL Generation #6
Comments
I've been reading this book. |
Like a LOD algo ? Level of detail. It's been used in games for years based on distance. It would be very useful to allow the LOD to be driven changed at runtime based off distance too as it would make a 3d viewer very efficient |
Not so much LoD. More like minimizing the number of triangles needed to represent the local detail of the object. Marching cubes samples the bounding box and generates triangles whose size matches the sampling resolution. As a result even planar surfaces end up with lots of little triangles. Those surfaces would be more efficiently represented with a few large triangles. The CGAL project has code that can deal with kind of thing. E.g. https://doc.cgal.org/latest/Surface_mesher/index.html#Chapter_3D_Surface_Mesh_Generation |
I have been again playing with this to use with a Milling machine. Regarding the mesh generation and sharp edges, has there been any movements or thought on this. |
No code written - thinking about it on and off. It's a well recognized problem when it comes to representing objects with meshes. There are solutions out there that just remove triangles selectively from a given mesh. The difference here is that the triangle tuning can be done with on-going knowledge of the SDF, thereby leading to a more accurate mesh. BTW - when it comes to 3d printing the STL file I haven't had any problem with the corner aliasing - it's too small to make a difference- so it's mostly an annoyance in the mesh viewer. I'm sure the slicer would work faster if it wasn't dealing with so many triangles, but it hasn't been an insurmountable problem, and the output gcode will be roughly the same irrespective of the input mesh size. I assume the milling machine experience would be about the same. |
That might be easier if you have lot's of triangles on a surface to start off with - which is what you have here. |
ok thanks for the advice.
I will look around for examples in golang and other for how to push and
pull on 3d stl meshes. Gotta be some prior art. Your code can probably also
be used and just add more to move the local vertexes around based on the
"brush size" being used.
…On Sat, 25 Aug 2018 at 18:37 Jason Harris ***@***.***> wrote:
do manual adjustments for more organic looking shapes
That might be easier if you have lot's of triangles on a surface to start
off with - which is what you have here.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ATuCwotcEkBEuguulBakZEUpJkAFPyroks5uUX1DgaJpZM4SSAUZ>
.
|
found this ! All golang 3D gui viewer. I think i can use this as a canvas and load up the STL's into it to do the pushing and pulling. Its nice to see this type of 3D stuff in the golang world. |
https://github.com/danieltwagner/sdfx/tree/simplify has a WIP mesh simplification algorithm. The idea is to not lose any details, i.e. only reduce coplanar triangles. It's mostly working but I must be generating a few triangles with bogus normals (maybe zero-size triangles?). I'll try to sort out the issue and tidy it all up and then put it up as a PR but would appreciate another pair of eyes. I attach an example below. You can see that a few wireframe lines are visible in the wrong orientation and as a result the interior cutout doesn't appear smooth. |
I haven't had a chance to review your code yet... I saw this and thought it was of interest: Based on: https://www.cs.cmu.edu/~garland/thesis/thesis.html Also: There are (at least) two approaches to this:
Approach 2 is possible, we have an SDF model that can be sampled wherever we like, it's just a bit beyond my sophisication at the moment. :-) |
Problem: The marching cubes algorithm gives STLs that are large in size and have aliasing defects on sharp edges.
Solution: Have a mesh generation algorithm that is adaptive to the curvature of the object. ie- big triangles on flat surfaces, small triangles for sharper curves. A quality metric could allow trade-offs between file size and mesh accuracy.
The text was updated successfully, but these errors were encountered: