Sunday, March 04, 2007
Cause of continuing drama with Slice and Dice found
Over my 40+ years of programming this and that I've found that to be a good rule of thumb. Like all rules of thumb, however, there are instances where it just isn't so. It turns out that the last several weeks of drama I've had trying to get the Slice and Dice routine that I wrote to slice STL descriptions of objects so that Tommelise can print them has been one of those instances.
This morning I was way past my wit's end. You've undoubtedly followed my litany of troubles trying to get Slice and Dice running so that I can start to print meaningful things with Tommelise. I've no doubt that many of you have got the idea that I've either gone softheaded or am too old to be writing code. I've certainly felt that way.
I'd got floodfilling going yesterday and ran some extensive tests on it to see that it was robust. It was immensely more robust than it had been but I still found some problems when I tried to slice the Mk 2's clamp plate. More bugs.
For a change, this time I decided that instead of assuming that everything was all right prior to the flood fill, in exasperation I started at the beginning of the program, or what I took to be the beginning, and started working down to the floodfill routine instead. Bang! Right off the bat I started getting creepy numbers, within 20 lines of code from the beginning of the main analysis loop. After about an hour of that I was on the point of deciding to apply of a slot in an assisted care facility. I gave it one last shot, though, before putting on my bib so that I wouldn't drool on myself and turning on daytime cable TV. Mind, this would be a little difficult since I had cable TV taken out five years ago.
Since there was no more code to analyse, well not completely. There was the little routine that reads the STL file, so I took a look at that. It looked good, so I started checking to see if, perhaps, I was reading in some data in a way that I shouldn't have been.
I opened the coupling's STL file in WordPad and was comparing it with what I was reading when something jumped out at me, not in my code, but in the STL file.
solid "drive-coupling"; Produced by Art of Illusion 2.0, Sun Feb 18 14:59:42 PST 2007
facet normal -0 -1 0
vertex 3 -7.5 6
vertex 3 0.407902201579 8
vertex 3 8.5 6
Just looking at it you could see instantly that the triangle lay on the X plane where X = 3. That means that a vector normal to the triangle should be a pure plus or minus X value.
I took a cross product of the first two line segments making up the triangle and got...
facet normal -1 0 0
I then wrote some code to calculate the normal vector from the triangle vertices and used the calculated value and guess what? All the flooding errors went away.
Furthermore, I plugged that patch of code into the Slice and Dice routine dating back to when I started having all this trouble over two weeks and 18 successive versions of the Slice and Dice routine ago and guess what? That old, old Slice and Dice code worked perfectly.
What it works out to is that I've spent over two weeks trying to fix my code when my code was working fine, it was just getting bad data from the STL file that Art of Illusion generated.
on a plus side it means that you made your slice and dice routine work really well. hopefully all those fixes and changes you made will be relevant to correct STL files.
Links to this post: