Re: [OpenSCAD] STL Exports: Many need repair and I can't tell why
For normal geometry an OpenSCAD export should have a well formed STL.
If you use polygon() or polyhedron() and make a malfomed object that may
cause a bad STL.
If you import() a bad STL it may export a bad STL (tho often you will get a
error of you do CSG on it).
Can you share .scad code and the bad STL it exports?
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/STL-Exports-Many-need-repair-and-I-can-t-tell-why-tp16463p16474.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Hello and thanks for responding. As an example, below is code to make 1.1
threads on a threaded rod (I know it's not the most efficient way to make it
but it was a tutorial project for myself). I ran it at a very low
resolution because full resolution takes about an hour. As you can see from
the console output the script renders as valid and exports STL . Then when
I open the STL using 3D Builder (Windows 10) the STL needs to be repaired,
and the 3D Builder seems to repair it . The STL file is attached.
STL_Output_Immatutre_Thread.stl
http://forum.openscad.org/file/n16475/STL_Output_Immatutre_Thread.stl
Script:
// Try to make a threaded rod
// 1/4 20 rod
TPI = 20; // Threads per inch
P = 1/TPI; // Pitch of threads - thread distance peak to peak
D = 0.25; // Diameter of the bolt
T_Overlap = 0.10; // Thread overlap amount
Length= P * (1 + T_Overlap); // Length of Rod or segment
He = cos(30) * P ;
D_maj = D + (2 * He /8) ; //
Del_p = 1;
D_min = D_maj - 25/8 * He;
D_p = D_maj - 23/8 * He;
Resolution = 10; // Resolution of cylinders ->>>30
Trim_Resolution = 100 ; // Resolution of cylinders used to Trim Threads
T_Resolution = 60; // Resolution of threads ->>> 1
module Thread_Die (){
render (conveity = 4) translate ([-D_maj/2,0,0])
difference () {
rotate([0, 90, 0])
cylinder ( h = He, d1 = P, d2 = 0, $fn = Resolution);
translate ([3/4*He, -P/2, -P/2])
cube([P,P,P]);
};
};
module Thread_Rod (){
difference () {
cylinder ( h = Length, d = D_maj, $fn = Resolution);
for (z = [-P:P:Length+P]){
dz = z;
for (c= [0:T_Resolution:360]){
rotate ([0,0,c]) translate ([0,0,dz]) Thread_Die ();
dz=dz+P/(360/(360-c));
};
};
};
};
module Trim_Threads () {
render (convexity = 4) difference () {
translate ([0, 0, -0.05])
cylinder ( h = Length+ 0.1, d = D_maj, $fn = Trim_Resolution);
cylinder ( h = Length, d = D, $fn = Trim_Resolution);
};
};
difference () {
Thread_Rod ();
Trim_Threads ();
};
Console Output:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 10
Geometry cache size in bytes: 108848
CGAL Polyhedrons in cache: 69
CGAL cache size in bytes: 6386976
Total rendering time: 0 hours, 0 minutes, 4 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 394
Halfedges: 1184
Edges: 592
Halffacets: 400
Facets: 200
Volumes: 2
Rendering finished.
STL export finished.
--
View this message in context: http://forum.openscad.org/STL-Exports-Many-need-repair-and-I-can-t-tell-why-tp16463p16475.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Hmmm.
I've never seen F6 results look like this. Anyone know what green means?
http://forum.openscad.org/file/n16478/td16463_F6.jpg
NetFabb shows degenerate faces...
http://forum.openscad.org/file/n16478/td16463_degenatated.jpg
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/STL-Exports-Many-need-repair-and-I-can-t-tell-why-tp16463p16478.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2016-03-14 06:50, MichaelAtOz wrote:
Hmmm.
I've never seen F6 results look like this. Anyone know what green
means?
http://forum.openscad.org/file/n16478/td16463_F6.jpg
Isn't that quite common? You get it after using difference in my
experience, when you cut away something.
Yeh, thanks for reminder, I'm just not used to seeing it on the outside. But
looking at the code, it is difference()ing a hollow cylinder...
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/STL-Exports-Many-need-repair-and-I-can-t-tell-why-tp16463p16480.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Found it. I.e. got rid of the degenerate faces, whether this is a bug in
OpenSCAD probably needs debate.
You were working with very small numbers. I suspect that contributed to
floating point issues internally. But I would expect OpenSCAD to work at
1/20th unit size, so it could be a bug.
When I changed it to work in inches (tho theoretically it is unit-less),
i.e. 25.4 times bigger the degenerate faces went away.
inch=25.4;
TPI = 20; // Threads per inch
P = 1/TPIinch; // Pitch of threads - thread distance peak to peak
D = 0.25inch; // Diameter of the bolt
T_Overlap = 0.10inch; // Thread overlap amount
Length= P * (1inch + T_Overlap); // Length of Rod or segment
BTW - not related to he STL issue, but;
dz=dz+P/(360/(360-c));
Reassignment is generally a bad idea and doesn't work, usually.
It only works there due to the scoping of the for loops.
dz=z+P/(360/(360-c));
Would be better.
Also you misspelled convexity in one spot.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/STL-Exports-Many-need-repair-and-I-can-t-tell-why-tp16463p16481.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
FWIW I concur - this problem only shows up at this tiny scale.
But the scale is not that tiny. It should really work :(
0.025
--
View this message in context: http://forum.openscad.org/STL-Exports-Many-need-repair-and-I-can-t-tell-why-tp16463p16484.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
FWIW I concur - this problem only shows up at this tiny scale.
But the scale is not that tiny. It should really work :(
That might be another case of https://github.com/openscad/openscad/issues/999
Degenerate faces are usually not a problem for slicing, OpenSCAD
would have trouble re-importing those file as it currently does
not handle faces with zero area well.
FWIW, I never needed to repair the models I've created in OpenSCAD,
so "many need repair" is probably a bit exaggerated. Due to the
issue mentioned above it might occur more often for models with
very tiny details which I don't create as that would not print
anyway.
ciao,
Torsten.
I tried to understand what "degenerated faces" are but other than finding
that they caused bad STL files and happen at small scale I was not able to
find anything helpful to explain to me what they actually are. If you have
a link you could share I would be grateful, I am a newbie model hobbyist and
am still learning basic concepts and jargon.
MichaelAtOz wrote
BTW - not related to he STL issue, but;
dz=dz+P/(360/(360-c));
Reassignment is generally a bad idea and doesn't work, usually.
It only works there due to the scoping of the for loops.
dz=z+P/(360/(360-c));
Would be better.
Also you misspelled convexity in one spot.
Thank you for both observations. I do remember the reassignment of
variables not working in past projects.
So it all comes down to scale. I do tend to make small scale models (I
don't print them) that must be the ones that I get the problem of good scad
renders with the broken STL exports. You have been very helpful.
--
View this message in context: http://forum.openscad.org/STL-Exports-Many-need-repair-and-I-can-t-tell-why-tp16463p16487.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
All faces must be broken into triangular facets in an STL file. If a
triangle has zero area by having two corners coincident, or three corners
in a line, then it is degenerate.
On 14 March 2016 at 12:35, ajs a.j.scaraggi@gmail.com wrote:
I tried to understand what "degenerated faces" are but other than finding
that they caused bad STL files and happen at small scale I was not able to
find anything helpful to explain to me what they actually are. If you have
a link you could share I would be grateful, I am a newbie model hobbyist
and
am still learning basic concepts and jargon.
MichaelAtOz wrote
BTW - not related to he STL issue, but;
dz=dz+P/(360/(360-c));
Reassignment is generally a bad idea and doesn't work, usually.
It only works there due to the scoping of the for loops.
dz=z+P/(360/(360-c));
Would be better.
Also you misspelled convexity in one spot.
Thank you for both observations. I do remember the reassignment of
variables not working in past projects.
So it all comes down to scale. I do tend to make small scale models (I
don't print them) that must be the ones that I get the problem of good scad
renders with the broken STL exports. You have been very helpful.
--
View this message in context:
http://forum.openscad.org/STL-Exports-Many-need-repair-and-I-can-t-tell-why-tp16463p16487.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