Importing STL files shows all sorts of artifacts

[celer]

Importing the HeartGears2-3.stl file from here:

https://www.thingiverse.com/thing:243278/files

using this code, has lots of artifacts, and holes in the outputed stl file.

package main 
 
import ( 
    "github.com/hschendel/stl" 
    "github.com/soypat/sdf/helpers/sdfexp" 
    "github.com/soypat/sdf/render" 
) 
 
func main() { 
 
    solid, err := stl.ReadFile("HeartGears2-3.stl") 
    if err != nil { 
        panic(err) 
    } 
 
    tris := make([]render.Triangle3, len(solid.Triangles)) 
 
    for i, t := range solid.Triangles { 
        for k := 0; k < 3; k++ { 
            tris[i][k].X = float64(t.Vertices[k][0]) 
            tris[i][k].Y = float64(t.Vertices[k][1]) 
            tris[i][k].Z = float64(t.Vertices[k][2]) 
        } 
    } 
 
    object, err := sdfexp.ImportModel(tris, 0) 
    if err != nil { 
        panic(err) 
    } 
 
    err = render.CreateSTL("out.stl", render.NewOctreeRenderer(object, 500)) 
    if err != nil { 
        panic(err)
    }
            
} 

[soypat]

I am aware of artifacting bug(s) somewhere in the sdfexp.Import -> CreateSTL pipeline.

That said there may be an issue in how you import the triangles. sdf's triangles are oriented and have their normal implicitly defined by their vertex ordering, unlike STL triangles.

Modify the for loop block to do the following

norm := r3.Vec{X:t.Normal[0],Y:t.Normal[1], Z:t.Normal[2]}
 for k := 0; k < 3; k++ { 
            tris[i][k].X = float64(t.Vertices[k][0])
            tris[i][k].Y = float64(t.Vertices[k][1])
            tris[i][k].Z = float64(t.Vertices[k][2])
}
if r3.Dot(tris[i].Normal(), norm) < 0 {
    tris[i][0], tris[i][1] = tris[i][1], tris[i][0] // Swap two vertices to invert normal direction to match render.Triangle type
}

Let me know if this helps. Keep in mind it might not fix all of the artifacts, or any at all if stl triangles were already oriented well.

[soypat]

I'd like to let you know https://github.com/soypat/sdf/commit/b079e74fbeb92dfb4d8414720bc3a88a7916cdd3 replaced the renderer.Triangle3 type with r3.Triangle type. This resolved #2 and will be a breaking change for many programs.

[celer]

Thanks! Yeah it didn't help much. I'm sick ATM so it won't be for a while before I can look at this again. Thanks for taking a look.

[soypat]

Alright, good to know others are experiencing this bug. I've been wanting to fix it for some time now but I'm quite swamped with university work. If all goes well I'll be graduating this year and so be free to put in some more time to sdf.

[cactorium]

Hey there! I'm not sure what the plan is with this but I ended up writing my own SDF for meshes a while ago that seems fairly stable. I think the issue is that the kd-tree that's being used doesn't always give the proper closest triangle. I ended up writing my own boundary interval hierarchy implementation of it, which worked well for a few meshes I tried, although sharp edges tended to disappear (not sure if it's because of some bug in my SDF or because of how the mesh generation process works in general)

I ended up switching approaches in my project so it won't be developed further, but I could try to work it into this repo if you're interested, here's a link to it: https://gist.github.com/cactorium/91ac2d917a6d9378a43d70ef881aea44

[soypat]

Thank you so much for your suggestion! That looks awesome and I'd love to see how it stacks up against the current buggy implementation! If you have time to incorporate it into the exp package- that'd be awesome!

[cactorium]

I'll try to work on it this weekend!

[soypat]

Moving development to https://github.com/soypat/gsdf. Closing all issues here.