When I run my slice() operator via the "adns2610_render_part=7" of adns-2610.scad I get valid data out, so my guess is that either the STL is bad (Meshlab didn't have any trouble with it though) or there's a bug somewhere in projection(), child() and/or import_stl().
"The future is already here. It's just not very evenly distributed" -- William Gibson
Re: bug: projection of child on complex import_stl object
On Jun 26, 2010, at 04:55 AM, Andrew Plumb wrote:
> Could you give the attached testcase a try? It unzips into a folder called "operations". Modify the OPENSCAD path at the top of the Makefile and run "make all".
I've given it a try and here is my take on it so far:
First of all, the object adns2610_dev_circuit_inv.stl has 3 null faces. This can be verified in MeshLab and will make OpenSCAD complain also without using the projection module by just importing it and rendering it using F6.
Removing the null faces in MeshLab kills this problem.
The fact that OpenSCAD appears to export STL's which cannot be used is of course not good :/
With the null-faces removed, the model renders fine, but I'm unable to do either unions, subtractions or projections:
Unions work with F5 and fails with F6.
Subtractions and projections fail with both F5 and F6.
Even your simple STL example fails rendering with F5 with this test:
I've committed some fixes which catch some of these exceptions to keep OpenSCAD from crashing, and added some info about these problems to the TODO list.
As it appears to me, STL import is largely broken and shouldn't be trusted.
This is pretty hardcore stuff to debug, so the simpler test cases you manage to produce, the bigger the chances to motivate someone to dig into this are.