STL Slicing Generates Incorrect Layer

[jmkao]

From Z 22 until 81, the CWH slicer appears to have trouble finding the correct boundaries of the shell of the part:

I ran this model through netfabb and it does not appear to have any non-manifold edges, and CW seems to be able to slice it fine:

The STL for this model is at:

GoPro-Frame.stl.zip

[WesGilster]

Darn. That's simple geometry too... I've tested this algorithm with inside-out geometry and slicing through fonts with high triangle counts without a problem. I'm going to release the remote install feature sometime this week before I get started on this because it's a time investment to dig into the slicing algorithm and I want to get as many problems fixed with it during one debugging instance. It may seem like you are piling on me, but the more instances of specific problems with different files you can find with the slicer, the better.

Since I'm digging into this anyway, it might end up being a good time to throw together a 3d renderer in CWH itself. That way we can see some benefit from these bugs.

[kloknibor]

Sorry to bother but where can we find that slice browser? (And the mask creator etc etc)

[jmkao]

Unzip the cwh-0..zip onto your computer and then run slicebrowser.bat. It looks like it's also in cwhClient-0.202.zip, but I usually run it out of the cwh install.

[Krizzza]

I have this same issue

I also get lots of warnings like this 2016-02-29 17:57:54,128 WARN o.a.r.s.Triangle3d [PrintJobProcessorThread-3] Could this situation happen and be a proper intersection?

Any ideas? I believe that Triangle3d is java-library, could this be problem that I have 800x600 resolution? It also seems that Warnings come for every layer, however they are not visible on every layer.

Here's another one with "OK" results (warnings in log all the same)

This STL for this is CornerBracket.zip

[WesGilster]

Now that my "user friendly" release is pretty close to production, I'll be able to start looking at this. It also looks like I have a couple of good example models with this problem, so shouldn't be too bad to fix.

[Krizzza]

Wes, do you have any news about this issue?

[WesGilster]

The user friendly release really turned into a user friendly release, plus developer friendly release, plus build re-haul release. I wanted to add some print start performance enhancements, but I suppose I could take a look at this.

[kloknibor]

I just reproduced this issue (stl slicer works again!) https://i.imgur.com/OyBTpSV.png if you need the file or logs to let me know ;)

[WesGilster]

Ok. I want to make sense of three different issues going on here:

1. 35 Vitruvian.stl (not water tight and should show errors)

2. 108 I can't recreate this. Does anyone have an example of this issue anymore?

3. 111/#194 CornerBracket.zip (Improper rendering)

[Krizzza]

I "somewhat assume" that slicing somewhat still leaves z-points between slices and that causes the error... eg. for example assume that z is 0.1mm and first layer is 0.35mm so layer 3 should be at 0.55mmm but I think that some of layer 3 z-points are actually 0.5500001 or similar.. This is all speculation of course..

[kloknibor]

194 wasn't about this error. But I installed it from scratch and it worked than. Could it be vitruvian.stl broke the stl slicer for further tries? It was the first file I tried. Otherwise I might suspect my printer profile... I will try to make some step by step reproducing when I get a new error. For this #111 a reproduction isn't needed I suppose?

[WesGilster]

@kloknibor That's right, I've reproduced this issue although I don't really know which of his slices he is showing above.

[WesGilster]

@Krizzza I didn't have much time this morning to do much, but I did find a bug a very nasty bug in the geometry slicing. This has also pointed out another bug I'll need to address, to fully fix your model. I also added a nice function to allow you to trace a triangle as it is sliced by subsequent vertical slices. It seemed like you were digging into the algorithm a bit, so I thought you might be interested in understanding how the function worked. If so, I'll document exactly what I did. It's actually pretty simple to understand...

[WesGilster]

The features are in the latest dev version of the slicer.

[kloknibor]

How is the progress on this bug?

[kloknibor]

or is this completely solved in "DEV023" ? maybe it would be nice to release a stable build soon :) I'll test the beta these days

[WesGilster]

No it's not fully fixed yet, only the geometry issue is fixed. I found a flaw in the way that the algorithm closes loops, and I still need to address that. I agree though I think we need to produce another stable prod build. It's long overdue...

[Krizzza]

I just tried to install unstable version and installer fails to find newest zipfile (says 404)..

[kloknibor]

I don't want to rush you in anyway but out of curiosity, in what time frame can that be solved? i personally feel like this needs to be adressed before we can say we have a public release like an 1.0 @krizzle are you using newstart.sh? with start.sh it will fail (from dev)

[Krizzza]

yes indeed, I was using start.sh.. will try soon when I'll be back to "garage"...

[WesGilster]

I'd like to do a few stable releases before 1.0 anyway.

[kloknibor]

Alright :)

Op 16 apr. 2016 om 03:28 heeft Wes G. notifications@github.com het volgende geschreven:

I'd like to do a few stable releases before 1.0 anyway.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[kloknibor]

In the latest DEV023 I still have the same error. I know Wes is still busy on it but when he needs more testing material he can ask ;)! First layer will look like this :

[WesGilster]

Krizza's corner bracket is working quite a bit better now and has most(all?) of the fatal problems fixed. As a side note, I'm so glad I've kept the original face geometry attached all the way to the poly fill algorithm. Debugging was easy and It's going to be pretty cool when I start shipping that info back to the web along with all of the STL file data. That feedback loop along with the js 3d slicing engine should be pretty cool.

The bad news is that I've discovered a pretty fatal problem with my intersection chaining algorithm. Unfortunately, it prematurely performs links without regard to the longest possible match. The good news is that I've wanted to add a performance boost to that part of the code for quite some time.

One thing that seems to be absent from all slicers(including mine) is a way to properly test them. So, I've added a new feature to the slice browser that you can right click on the slice to persist that pixel(and slice engine) information inside of a json file along with the name of the stl model. That way you can record extremely specific trouble spots and build these checks into our junit tests for later execution. This will really increase our confidence level in making code changes to this algorithm. Unfortunately, the right click feature only works when used inside of Eclipse because it takes advantage of resource loading external files on "srcbin" and not jars.

[jmkao]

I'll take a look at that and see how I can keep both Eclipse and Gradle behavior in sync...

[WesGilster]

@jmkao Thanks for the offer, but I'm not sure you should spend too much time on it. I had a whole string of these events that happened in a row, but I can't say that it's been a common occurrence outside the last couple of days.

[Krizzza]

Now it seems that most of the outlines are correct, but I get hollow layers now (0.298).

[WesGilster]

Are you saying that the full layer is hollow? I'll take another look at this.

[Krizzza]

yes, it is just outline of the shape. Im not currently near "garage" so I can't provide screenshots.

[kloknibor]

So can I help fix this issue or shall I concetrate me on the website? I really would like this to be fixed to be honest :$

[WesGilster]

I'd suggest focusing on the website. When I'm ready, I'll ask for people to start loading their models in the SliceBrowser and start right clicking on problem areas. This will collect slice/pixel information that will be used in our testing framework. That way we'll have repeatable tests of known problem areas. In the future if we have to modify the algorithm again, we'll have tests that we can verify against in the future. At the moment, I really just need a few consecutive hours to implement the new algorithm.

[kloknibor]

Any news on this? I want to start using photonic3D in an production environment, I got 3 3D printers here and I can't miss my laptop currently very much, so I can't print anything :( Ofcourse I'm not trying to rush you :) I'm gratefull for what you do for the project ;)! And I understand your busy too ofcourse! But if this is gonna take a very long time I might want to look for alternatives (like cheap windows devices) that's why I'm asking ;)!

[WesGilster]

I had some time to work on this today, so I rewrote the intersection geometry with commons-math instead of my own math. Initially I wasn't going to do that, but there was more edge cases than I wanted to deal with. I'm down to about 6 frames(that still need a bit of work and then I'll start the slicing algorithm.

On the subject of the slicing algorithm, I've started thinking about loading the stl file directly into a PolyhedronsSet and performing the entire slice with commons-math. Originally I didn't think that Java had the libraries to do this, but I really don't see any road blocks so far. If I look a bit further, I could probably find that the rasterization is already done as well.

[WesGilster]

I released a new dev version with these changes.

[kloknibor]

Alright sounds good! I'll try to test the algorithm today, but as I understand it still will have some problems but we're heading the right way, correct :)?

[kloknibor]

So it works a lot better now! But still not flawless! The file I sended Wes earlier and I posted above did I use to test it again. It slices much better but sometimes there are horizontal black lines in the print which shouldn't be there... like here : and in one slice it had an cirlce in it but it was devided in 2 halfs, the upper one was bigger in radius than the lower one, very strange!

[WesGilster]

Yep things should be slightly better.

Thanks, Wes G.

On 5/9/2016 2:02 AM, Robin wrote:

Alright sounds good! I'll try to test the algorithm today, but as I understand it still will have some problems but we're heading the right way, correct :)?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/area515/Creation-Workshop-Host/issues/111#issuecomment-217790044

[WesGilster]

I think you should find that the reliability of the latest version(photonic-dev005) is significantly better than the previous versions now. I was under the mistaken impression that my algorithm was responsible for most of the visual flaws that you see in this bug. Instead it was just good old fashioned sloppy programming without any tests.

This doesn't absolve the main algorithm of it's fundamental problem of closing short loops and joining reversed normals. It is still flawed and I'd like to make sure it's responsible for the rest of the irregularities that might be out there.

I've tested the 3 stl files that were attached to this bug and things are quite a bit better. It would help me significantly if everyone search your files for "all" issues and let me know the frames(slice numbers) that you are having trouble with.

Right clicking on the slice browser will automatically add the test points into the points.json file and it will help tremendously for the automated testing. These points will give me a really strong framework to start my algorithm rewrite.

In the mean time, I'll start adding in the web based stl progress slicer. With great pain, I've kept the watertight checking and manifold error checking and we should see some serious dividends paid in the future for all of this functionality integrated into the product.

This was a real maintenance trade off point for me since I could have cut my development time massively by using Apache commons math for the z slicing. I'm still not convinced that I've taken the correct direction, but we'll see what people think of this functionality integrated into the product.

[Krizzza]

I've been testing with Dev-5 version now, and this seems to work pretty good. Haven't noticed anything during printing some prototypes.

[kloknibor]

The result of mine fine is ok too. But in the slice viewer there are some double lines around the rounded corners, for example in layer 1.

[WesGilster]

Again, the slicing algorithm is not perfect and requires 2 fixes that I mentioned in the previous post. Those two issues aside, the "double lines" isn't actually a problem and isn't really a defect at all. The slice browser takes an academic approach to slicing while the slicing engine is designed to take a practical approach to hide problems and make things look good.

To illustrate my point a bit further and to show off the back-referencing feature of the slicing engine itself, I added a quick feature to dev007.

Load up your model in the slice browser again and try this:

1. Go to the slice you are having trouble with (layer 1).
2. Click on "Alpha Colorize".
3. In the left panel, click on one of the "double lines" around the rounded corners and the slice browser will find and highlight the line in the slice tree(right panel).
4. Scroll down in the slice tree(right panel) to find the selected tree node(line) that it found.
5. Expand that tree node and it will tell you the precise triangle from the STL that it found.
6. Since intersections are now being performed by Commons-Math, you are likely going to find that those "double lines" are completely legit. If you don't believe it, it's pretty easy to do a couple of plane intersection math yourself to double check.

[WesGilster]

Fixed long ago. If someone would like to submit a file that they are having trouble with I'll be glad to reopen.