Infill is not generated

[Evil-Spirit]

When I using the attched example, all the fine

        CappedCylinderGenerator cylgen = new CappedCylinderGenerator() {
            BaseRadius = 10, TopRadius = 5, Height = 20, Slices = 32
        };
        DMesh3 mesh = cylgen.Generate().MakeDMesh();
        MeshTransforms.ConvertYUpToZUp(mesh);       // g3 meshes are usually Y-up

Attempt to generate gcode for this mesh:

Converted from unity mesh by using this function:

    public static DMesh3 ToDMesh3(this Mesh mesh) {
        DMesh3 result = new DMesh3();
        result.BeginUnsafeTrianglesInsert();

        var indices = mesh.GetIndices(0);
        var polygons = new List<Polygon>();
        var verts = mesh.vertices;
        for(int i = 0; i < indices.Length / 3; i++) {
            var v0 = verts[indices[i * 3 + 0]];
            var v1 = verts[indices[i * 3 + 1]];
            var v2 = verts[indices[i * 3 + 2]];
            result.AppendTriangle(
                result.AppendVertex(new Vector3d(v0.x, v0.y, v0.z)),
                result.AppendVertex(new Vector3d(v1.x, v1.y, v1.z)),
                result.AppendVertex(new Vector3d(v2.x, v2.y, v2.z))
            );
        }
        result.EndUnsafeTrianglesInsert();
        return result;
    }

Resulted in gcode that have no any infill:

STL is watertight. What I am doing in wrong way?

[Evil-Spirit]

NoteCADExport.zip

[rms80]

It works for me when I import your STL. My guess is that the unity Mesh you are starting with is not topologically closed, ie it has open boundary loops between the faces. Although it may be geometrically closed, the MeshPlanarSlicer will interpret such a mesh as being a set of separate 'open' sheets, and only pass their outlines to the toolpather.

So, you need to merge the boundary vertices. A quick-and-dirty way to do that would just be to write out and re-open the STL. You can do this all in memory with StandardMeshReader / StandardMeshWriter, they can take Streams instead of filenames.

Alternately you could try to hack MeshPlanarSlicer to chain the 2D polylines, eg by matching open polyline endpoints. Naive methods will work in this simple case, but it is extremely difficult to get right in arbitrary cases, eg like meshes with overlapping edges, etc.

[Evil-Spirit]

@rms80 Thank you for your answer!

[Evil-Spirit]

Strange thing: it seems this doesn't fix for me. I have my own stitching algorithm while loading STL and I apply it and this still not working.

[Evil-Spirit]

will try to figure out the problem tomorrow

[rms80]

check DMesh3.IsClosed(). if it returns false, there are boundary edges in the mesh, and that would be why the slicer leaves it open.

[Evil-Spirit]

got it! thank you!

[Evil-Spirit]

@rms80 btw managed to work slicer online! http://notecam.xyz

[rms80]

Cool! I tried a few files but I couldn't get it to work (either it said there were exceptions, or it said there were out-of-memory errors). I would be happy to post a link on twitter if you can give me a screenshot (if you want people to try it)

[Evil-Spirit]

sorry, I don't say - only text stl files supported. And I haven't released new version - so, only simple files not cause memory errors. A little bit later I will send you screenshot.

[Evil-Spirit]

escher_export.zip

[Evil-Spirit]

@rms80 I finally solve all the issues! Now you can try loading any stl files, memory problems should be rare (for simple input files)

Files like this processed with no problems

you can try it yourself: ImportSTL->Slice->GCode

stlFiles.zip

I think it is first true-online slicer, isn't it?

[rms80]

These guys have compiled a C++ slicer to javascript: http://shapeforge.loria.fr/slicecrafter/

I can load the files but nothing happens when I click slice (I do not see the toolbar you screenshotted above)

[Evil-Spirit]

You should click GCode to start real generation. Slice will be for parameters adjusting