On 27. jan. 2016 17:18, nop head wrote:
Yes you can't guaranteed an STL from another program is valid but can
guarantee to write valid ones and be able to read ones that are valid.
From what I said before it is clear this is not a sufficient requirement.
Anyway, I just shared some thoughts, you are of course free to ignore them.
Carsten Arnholm
http://arnholm.org
thanks for discussing my problem.
It is still not solved. I get the idea that I am doing things that openscad
is not suitable for?
Mayby good to explain what I am doing.
http://forum.openscad.org/file/n15940/mp.jpg
The picture shows the mouthpiece outside.
The mouthpiece is build in the following parts:
It works using F5 but takes quite long when I increase the accuracy.
It often refused to render using F6 giving all the known fault codes.
I can use correction using Meshlab but they don't work always.
So the question is: is Openscad the right tool to design this?
--
View this message in context: http://forum.openscad.org/CGAL-errors-when-combining-two-correct-STL-s-tp15909p15940.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Have you considered creating these 3 parts as a single OpenSCAD
operation, rather than as 3 separate ones? Is the issue that they each
take a long time to calculate, so you are trying to pre-compute some of
them to save time? Perhaps we can help you optimize some of the code so
that re-calculating each one is more tolerable.
Jon
On 1/27/2016 11:37 AM, Johan Jonker wrote:
thanks for discussing my problem.
It is still not solved. I get the idea that I am doing things that openscad
is not suitable for?
Mayby good to explain what I am doing.
http://forum.openscad.org/file/n15940/mp.jpg
The picture shows the mouthpiece outside.
The mouthpiece is build in the following parts:
It works using F5 but takes quite long when I increase the accuracy.
It often refused to render using F6 giving all the known fault codes.
I can use correction using Meshlab but they don't work always.
So the question is: is Openscad the right tool to design this?
--
View this message in context: http://forum.openscad.org/CGAL-errors-when-combining-two-correct-STL-s-tp15909p15940.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7357 / Virus Database: 4522/11495 - Release Date: 01/27/16
It isn't a good tool for reading STL files. If you create all the geometry
in OpenScad and then write an STL it should be fine.
On 27 January 2016 at 16:37, Johan Jonker johangjonker@zonnet.nl wrote:
thanks for discussing my problem.
It is still not solved. I get the idea that I am doing things that openscad
is not suitable for?
Mayby good to explain what I am doing.
http://forum.openscad.org/file/n15940/mp.jpg
The picture shows the mouthpiece outside.
The mouthpiece is build in the following parts:
It works using F5 but takes quite long when I increase the accuracy.
It often refused to render using F6 giving all the known fault codes.
I can use correction using Meshlab but they don't work always.
So the question is: is Openscad the right tool to design this?
--
View this message in context:
http://forum.openscad.org/CGAL-errors-when-combining-two-correct-STL-s-tp15909p15940.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I agree with this.
Also, we’ll eventually get this fixed, so the future will be brighter :)
-Marius
On Jan 27, 2016, at 11:56 AM, nop head nop.head@gmail.com wrote:
It isn't a good tool for reading STL files. If you create all the geometry in OpenScad and then write an STL it should be fine.
I tried to do the outside in one STL. But that results in errors.
It would be great when you can help me. But it is quite complex.
Here are the main files. I suppose the libraries are known.
mp_parameters.scad
http://forum.openscad.org/file/n15945/mp_parameters.scad
mouthpiece_outside_v11.scad
http://forum.openscad.org/file/n15945/mouthpiece_outside_v11.scad
--
View this message in context: http://forum.openscad.org/CGAL-errors-when-combining-two-correct-STL-s-tp15909p15945.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
In the program I tried to reduce calculation time by making the shapes that
are subtracted from the main body as small as possible. In an earlier
version the beak shape were two cylinders and I modified that into on
quarter of these. That appears to be a more complex function.
I put it back to the cylindrical version again. Now this part renders with
F6 and $fn=80.
http://forum.openscad.org/file/n15946/mp.jpg
Now I'll try to add the inside in the same scad.
--
View this message in context: http://forum.openscad.org/CGAL-errors-when-combining-two-correct-STL-s-tp15909p15946.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Isn't this a very good argument for the idea of an openSCAD format cache of objects, and the ability to programatically load/save individuals shapes from a list of shapes? These two concepts have been discussed at length in other threads and deserve consideration as a valuable in house feature if not of universal use to the 3-D community as a whole? Or have I oversimplified it all?
On 28 January 2016 2:11:21 AM AEDT, Carsten Arnholm arnholm@arnholm.org wrote:
On 27. jan. 2016 14:23, nop head wrote:
It is a sad fact that OpenScad can't import a lot of the STLs it
makes
itself. I think it re-quantises vertices and they collapse. It also
doesn't detect invalid meshes until you do a CGAL operation on them.
Regardless of how OpenSCAD treats the STL files on import (it probably
could be improved), it shows that STL is the wrong format for
intermediate storage of parts when the intention is re-import for
assembly.
Why is it the wrong format? Because STL files do not contain any
topology at all, so when you import the STL for further use in boolean
operations, the topology must be guessed and reconstructed using unsafe
coordinate comparisons. It is inefficient and bound to fail in many
cases, and it does. By 'fail' I mean the reconstructed topology is not
exactly the same as the original.
A better solution for this purpose would probably be to store one or
more computed polyhedrons to a file (assuming one takes an approach
native to OpenSCAD). The idea would be to allow such polyhedron files
to
be re-imported as an alternative to STL. It would guarantee that the
imported object is the same as the exported object, it would be more
compact since each vertex is mentioned only once, and it would be
faster
to process because no vertex matching would have to be done. You could
think of it as ready made 'parts' files that needs to be imported into
openscad as in the original mouthpiece example, just using a different
format for intermediate storage.
If you don't want to introduce another format for this purpose, perhaps
AMF could serve the same purpose, although the present (2015.03-2)
implementation of AMF export does not seem to separate between
independent bodies. I just tested it with a model containing several
bodies and they were written to AMF as a single <object>. For AMF to
work as intermediate format the way I described, each <object> on AMF
would have to be a valid polyhedron. AMF is an XML format so you could
perhaps add a property to the object type to indicate it is indeed a
polyhedron:
<object id="0" type="polyhedron">
Just my thoughts.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Yes, rendered with f6 and $fn=120 in 3 minutes.
Thanks for helping me out.
Conclusion: better a simple structure than a smalll structure?
http://forum.openscad.org/file/n15949/mp.png
--
View this message in context: http://forum.openscad.org/CGAL-errors-when-combining-two-correct-STL-s-tp15909p15949.html
Sent from the OpenSCAD mailing list archive at Nabble.com.