rendering for paper assembly manual...
Hello,
I used openscad to design my new thing.
(To fix ideas, imagine 16 alu profile, ~30 small laser cuts, ~150
screws-nuts-rivet, ~10 parts from shelf)
I'm currently in the process of writing an assembly manual for the end user,
who will assemble everything.
I'd like to get something that looks like an ikea manual.
Kind of simplified wireframe perspective view, black&white optimized for
printing.
And I'd like to be able to modify my model and simply regenerate all the
assembly views as automated as possible.
I know that in openscad I can programmatically set a view (camera position &
direction, angle, etc...)
How would you do?
Play with openscad wireframe view, change the colors to just black and
white, and export bitmap?
Rotate the object, and make a projection, to export dxf?
Or export a 3D model, STL, or CSG, and process with an external tool, and
which one?
any idea, advice, experience feedback will be much appreciated, Pierre
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Or export a 3D model, STL, or CSG, and process with
an external tool, and which one?
I'd probably try to go this way and export to Blender and
use the Freestyle renderer there.
ciao,
Torsten.
You are tackling a problem I had many times, but never found enough reason to
go deeper into it and implement a solution. I think many people are
confronted with it and would appreciate to have some build-in function at
best, or at least a viable solution for this.
Let me sketch my approach, which is - no wonder - quite similar to the
algorithm I proposed to Jon in the flattening curved surfaces
http://forum.openscad.org/flattening-curved-surfaces-tp19727p19736.html
thread.
Jon wanted to unroll dominant surfaces of 3D objects (by the way, Jon, how
is your progress?) on 2D. For this he had to separate the model into a set
of surfaces. Using the assumption the surfaces are unrollable, it is enough
to test the scalar product of the normals of adjoint triags against a
threshold.
The same approach can be used to find the dominant "borders" of a surface.
In this case the unrollability assumption can be weakend into a "almost
unrollable" criterium, which (I hope: to Ronaldos relief) is exactly the
semantics of the threshold test. Let's draw "almost unrollable surfaces", by
skipping less important lines and staying in 3D.
So a "cheap" recipe could be: find all common edges of all adjoint triag
pairs, for which the threshold test fails and draw them on top of the model
similar to the visualisation in my unrolling sufaces demo
http://forum.openscad.org/flattening-curved-surfaces-tp19727p19807.html .
While this little helper is a someliner e.g. in Matlab, it is (again) beyond
the scope of OpenSCAD language as long as no import function for STL data is
available. Having this import function would serve many more requests - from
boundingboxes, calculating distortions, calculating testless unions and many
more.
So my question to the dev team would be: Is it planned, or are there any
objections I might have missed?
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20110.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@tp3 : Thanks! Although I didn't know blender and it looks like an airliner
cockpit for beginner like me, I managed to find the three options to get
there :
http://forum.openscad.org/file/n20111/4.png
To be honest, the result is better than expected. :-)
Now I just have to found a way to render let's say 30 different views
without redoing everything 30 times.
But it's not anymore an openscad issue....
@Parkinbot, I must admit your approach is not very clear to me, but anyway,
thanks.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20111.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Interesting approach!
Parkinbot: I got distracted. Still on the list, just not at the top.
Thanks for the prod!
On 1/16/2017 8:27 AM, Parkinbot wrote:
You are tackling a problem I had many times, but never found enough reason to
go deeper into it and implement a solution. I think many people are
confronted with it and would appreciate to have some build-in function at
best, or at least a viable solution for this.
Let me sketch my approach, which is - no wonder - quite similar to the
algorithm I proposed to Jon in the flattening curved surfaces
http://forum.openscad.org/flattening-curved-surfaces-tp19727p19736.html
thread.
Jon wanted to unroll dominant surfaces of 3D objects (by the way, Jon, how
is your progress?) on 2D. For this he had to separate the model into a set
of surfaces. Using the assumption the surfaces are unrollable, it is enough
to test the scalar product of the normals of adjoint triags against a
threshold.
The same approach can be used to find the dominant "borders" of a surface.
In this case the unrollability assumption can be weakend into a "almost
unrollable" criterium, which (I hope: to Ronaldos relief) is exactly the
semantics of the threshold test. Let's draw "almost unrollable surfaces", by
skipping less important lines and staying in 3D.
So a "cheap" recipe could be: find all common edges of all adjoint triag
pairs, for which the threshold test fails and draw them on top of the model
similar to the visualisation in my unrolling sufaces demo
http://forum.openscad.org/flattening-curved-surfaces-tp19727p19807.html .
While this little helper is a someliner e.g. in Matlab, it is (again) beyond
the scope of OpenSCAD language as long as no import function for STL data is
available. Having this import function would serve many more requests - from
boundingboxes, calculating distortions, calculating testless unions and many
more.
So my question to the dev team would be: Is it planned, or are there any
objections I might have missed?
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20110.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.7996 / Virus Database: 4749/13780 - Release Date: 01/16/17
pierrepoulpe wrote
@Parkinbot, I must admit your approach is not very clear to me, but
anyway, thanks.
Sorry, it was not so much meant as immediate solution or direct answer to
your question, more as a feature request to bring some more functionality
(e.g. your helper function) into OpenSCAD on the longer run ;-)
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20113.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@Parkinbot
I haven't understood your approach either. Maybe you are trying to find the
silhouette edges of the model seeing from a point of view.
Regarding "import function for STL data": this is a reiterate
question/feature request here. I myself asked in a recent thread why
bounding box functions (which are computed by resize(), for instance) is not
available in code level. Torsten answer that: " internally the geometry will
be known, there's currently no
means to communicate this information to the back to the script." So, I
understand it as a language limitation: there is no way a function can
receive a model as input in the current language. It will be easy in
OpenSCAD2 though.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20115.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
pierrepoulpe wrote
@tp3 : Thanks! Although I didn't know blender and it looks like an
airliner cockpit for beginner like me,
I managed to find the three options to get there
:
Could you share them?
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20116.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
If you're inclined to shift gears a bit --- curious as to what people think
of the assembly approach which was used on the Shapeoko 2 manual:
http://shapeoko.github.io/Docs/content/tPictures/PS20028-100.svg
If you open that in a browser you can click on the part # list to highlight
the parts.
William
On Mon, Jan 16, 2017 at 8:54 AM, Parkinbot rudolf@parkinbot.com wrote:
pierrepoulpe wrote
@Parkinbot, I must admit your approach is not very clear to me, but
anyway, thanks.
Sorry, it was not so much meant as immediate solution or direct answer to
your question, more as a feature request to bring some more functionality
(e.g. your helper function) into OpenSCAD on the longer run ;-)
--
View this message in context: http://forum.openscad.org/
rendering-for-paper-assembly-manual-tp20108p20113.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
Of course (and it's a note to myself in the same time, good idea) :
after deleting default cube, importing your stl, set your view, ctlr+alt+0
to set the camera view.
In World properties, change "Horizon color" to white
In Render tab
resolution 1920x100 100%
check "Freestyle"
In Render layers tab :
under 'layer', uncheck solid
under 'freestyle line style, thickness at 1.5
Render...
That should be enough.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20118.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@William ....
beautiful... do you know the process to get to this result?
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20119.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo,
I was trying to sketch a function allowing you transform some STL into an
outline drawing. For this you want to do away with the "inner" triangulation
and this needs some filter approach.
http://forum.openscad.org/file/n20120/stl.png
My question to the dev team was, if it has just capacity reasons, why such
an "easy to implement" and "no side effect" function is not provided, or if
there are political reasons.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20120.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Mon, Jan 16, 2017 at 10:28 AM, pierrepoulpe contact@pierrebeck.fr
wrote:
@William ....
beautiful... do you know the process to get to this result?
Thank you! I'm flattered --- it's just a matter of editing the SVG for
interactivity --- I documented it pretty thoroughly on the Shapeoko forums,
Inkscape mailing list, and Github change logs I'd thought:
http://www.shapeoko.com/forum/viewtopic.php?f=10&t=2930&start=10#p22311
Hope this helps!
William
@Parkinbot
The trouble is the language sintax limitations. There is no way to define
something like
bb=boundingbox(sphere(20));
or
bb=boundingbox() cylinder(10,20);
Functions does not accept objects as parameters and modules doesn't return
any value. So a major language change is needed.
Ronaldo I am with you and you are right for the modules, but I am opting for
stl imports. It wouldn't be very difficult to implement
myStl = import("myDesign.stl");
with myStl denoting a list of triags respectively a list of list of
vertices. With this it is a one-liner to implement your own boundingbox:
function boundingbox(points) = let (x = [for (p = points) p[0]], y = [for
(p = points) p[1]], x = [for (p = points) p[2]]) [[min(x), min(y),
min(z)], [max(x), max(y), max(z)]];
Ronaldo wrote
@Parkinbot
The trouble is the language sintax limitations. There is no way to define
something like
bb=boundingbox(sphere(20));
or
bb=boundingbox() cylinder(10,20);
Functions does not accept objects as parameters and modules doesn't
return
any value. So a major language change is needed.
OpenSCAD mailing list
Discuss@.openscad
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20123.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
Ronaldo I am with you and you are right for the modules, but I am opting
for stl imports. It wouldn't be very difficult to implement
myStl = import("myDesign.stl");
I see your point now. An import stl function would not conflict with the
language syntax. And it would be a great value indeed.
I have consulted the Github/OpenSCAD forum and there is an issue on that
opened on Apr, 2015 https://github.com/openscad/openscad/issues/1324 .
The proposed syntax is not the same though:
my2Dobj=read("my2dmodel.dxf");
my3Dobj=read("my3dmodel.stl");
There was not much discussion about it and it seems to be forgotten.
Disappointing.
A second issue on the same idea, opened (and closed) on Feb, 2016, has
proposed your syntax which seems better to me.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20124.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo,
I would like to give an example concerning the rendering of large number
unions, and present a technique I use for calculating lazy unions to speed
up this process. The implementation has some similarities with your sweep
interface - it stuffs everything into a single polyhedron call.
The Problem: We all know it can take hours to F6-render something like this:
http://forum.openscad.org/file/n20126/lazy.png
$fn = 30;
X = 800;
Y = 800;
for(x=[0:21:X], y=[0:21:Y])
translate([x, y])
cylinder(r=10,h=10, center = true);
cube([10, 10, 30], center = true); // final boolean operation
My machine takes about 33 min to F6-render this array. F5 is almost
instantly.
Now, let's look at the stony way. We sweep each of the cylinders and bypass
CGAL for the array union using some OpenSCAD function code that stuffs all
into a large polyhedron. With this approach F5 now takes some 12s, and F6
only 11s. This is a gain of factor 200 for F6 - just for being lazy.
As the cube intersects the first cylinder, we can't bypass CGAL and F6 takes
about 2 min.
In a large design I can visually analyze the situation using via F5 and find
out easily, which object groups need boolean operations and which can be
bypassed. After F6-rendering them one by one and generating STLs they could
be reimported for lazy unioning. Of course a lazy union primitive would do a
much better job, but I doubt, we will ever get one, because it is prone to
generate faulty output.
Here the code for the lazy union:
lazy_union.scad http://forum.openscad.org/file/n20126/lazy_union.scad
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20126.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Of course a lazy union primitive would do a much better job, but I doubt,
we will ever get one, because it is prone to generate faulty output.
Why is it error prone?
If union determined two objects don't overlap it could bypass CGAL's union
and just merge the facet data. That would speed up cases like this.
Determining when objects overlap if their bounding boxes overlap could get
tricky but you could always default to CGAL in those cases.
I am surprised CGAL doesn't do this itself already. Seems like a low
hanging optimisation.
On 17 January 2017 at 02:06, Parkinbot rudolf@parkinbot.com wrote:
Ronaldo,
I would like to give an example concerning the rendering of large number
unions, and present a technique I use for calculating lazy unions to speed
up this process. The implementation has some similarities with your sweep
interface - it stuffs everything into a single polyhedron call.
The Problem: We all know it can take hours to F6-render something like
this:
http://forum.openscad.org/file/n20126/lazy.png
$fn = 30;
X = 800;
Y = 800;
for(x=[0:21:X], y=[0:21:Y])
translate([x, y])
cylinder(r=10,h=10, center = true);
cube([10, 10, 30], center = true); // final boolean operation
My machine takes about 33 min to F6-render this array. F5 is almost
instantly.
Now, let's look at the stony way. We sweep each of the cylinders and bypass
CGAL for the array union using some OpenSCAD function code that stuffs all
into a large polyhedron. With this approach F5 now takes some 12s, and F6
only 11s. This is a gain of factor 200 for F6 - just for being lazy.
As the cube intersects the first cylinder, we can't bypass CGAL and F6
takes
about 2 min.
In a large design I can visually analyze the situation using via F5 and
find
out easily, which object groups need boolean operations and which can be
bypassed. After F6-rendering them one by one and generating STLs they could
be reimported for lazy unioning. Of course a lazy union primitive would do
a
much better job, but I doubt, we will ever get one, because it is prone to
generate faulty output.
Here the code for the lazy union:
lazy_union.scad http://forum.openscad.org/file/n20126/lazy_union.scad
--
View this message in context: http://forum.openscad.org/
rendering-for-paper-assembly-manual-tp20108p20126.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
nophead wrote
Why is it error prone?
You are right, a lazy_union() could be implemented to do a boundingbox test
and offer the option to completely omit all tests, for kamikaze fighters
like me.
I have reported the huge potential
http://forum.openscad.org/No-bounding-box-test-for-union-before-entering-CGAL-tp17538.html
to speed up unions dramatically by conducting at least boundingbox tests to
bypass CGAL operation some time ago, with not much reaction, as it seems.
Indeed, I used this example to demonstrate part of the enormous potential of
an STL-import function, which would have much less impact on OpenSCAD code
compared to an optimization of Boolean operations of this scope. And even
getting an explicit /lazy-union()/ operation, which is much easier to
implement, will not do away with the "get hands on the point representation"
problem. An /import()/ function would and also open a broad range of paths
to tackle other problems, like lazy unions or distortion and morph
operations.
Beyond time, since the whole workflow is defined for linux being on Windows
it doesn't seem viable to me to branch out an own version and just implement
it.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20133.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@Parkinbot.
I think I need a new computer: the render of your code with the cube took
almost 7min! But that is really fast for a model with 91260 vertices and
94302 facets.
I understand your point of what you call a lazy union. I have tried before
to produce one polyhedron with thousand spheres with such surprising
results. The way you have conceived your multiple sweep is similar to the
way I have been stitching my surface-bounded models. However, I usually does
not use this union inside polyhedron.
What it is weird to me (besides many other things, for sure) is that CGAL
accepts uncritically any polyhedron even with self-interceptions without a
warning. Only when we do a boolean operation it complains. Try this:
X = 100;
Y = 100;
// generate object array
dat2union = [for(x=[0:17:X], y=[0:17:Y]) sweep_(TF(x, y, Cyl()))];
Now the cylinders overlap but you will be able to render it without any
warning. And generate an STL file. Corrupted, of course.
Finally, I am surprised that you have embraced the new C-like for and got a
neat non-recursive version of what I call an accumulated sum function:
function acc_sum(l) =
[for(i=0, sum=0; i<len(l); sum=sum+l[i], i=i+1) sum];
</quote>
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20134.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
What it is weird to me (besides many other things, for sure) is that CGAL
accepts uncritically any polyhedron even with a self-interceptions without
a warning. Only when we do a boolean operation it complains.
Modern versions of OpenSCAD only involve CGAL when you do boolean ops. That
is why CGAL doesn't complain. It hasn't see it yet. When you do F6 and get
the simple output:
Top level object is a 3D object:
Facets: 6
CGAL has not been used at all. When it is you get:
Top level object is a 3D object:
Simple: yes
Vertices: 8
Halfedges: 24
Edges: 12
Halffacets: 12
Facets: 6
Volumes: 2
On 17 January 2017 at 12:21, Ronaldo rcmpersiano@gmail.com wrote:
@Parkinbot.
I think I need a new computer: the render of your code with the cube took
almost 7min! But that is really fast for a model with 91260 vertices and
94302 facets.
I understand your point of what you call a lazy union. I have tried before
to produce one polyhedron with thousand spheres with such surprising
results. The way you have conceived your multiple sweep is similar to the
way I have been stitching my surface-bounded models. However, I usually
does
not use this union inside polyhedron.
What it is weird to me (besides many other things, for sure) is that CGAL
accepts uncritically any polyhedron even with self-interceptions without a
warning. Only when we do a boolean operation it complains. Try this:
X = 100;
Y = 100;
// generate object array
dat2union = [for(x=[0:17:X], y=[0:17:Y]) sweep_(TF(x, y, Cyl()))];
Now the cylinders overlap but you will be able to render it without any
warning. And generate an STL file. Corrupted, of course.
Finally, I am surprised that you have embraced the new C-like for and got a
neat non-recursive version of what I call an accumulated sum function:
function acc_sum(l) =
[for(i=0, sum=0; i<len(l); sum=sum+l[i], i=i+1) sum];
</quote>
--
View this message in context: http://forum.openscad.org/
rendering-for-paper-assembly-manual-tp20108p20134.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
Now I understand why you come up with this discussion in this thread. But I
think it is important enough to have its own.
Surely an import() function would have an huge impact on the ability to do
many now unthinkable tasks on user space. The many questions arising here
asking for some way to inquire model evidence that. It would open, for
instance, the possibility to crate organic models (forks included) by
applying subdivision methods to a triangulated model generated by boolean
operations.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20136.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
nophead wrote
Modern versions of OpenSCAD only involve CGAL when you do boolean ops.
That
is why CGAL doesn't complain. It hasn't see it yet. When you do F6 and get
the simple output:
Top level object is a 3D object:
Facets: 6
CGAL has not been used at all. When it is you get:
Top level object is a 3D object:
Simple: yes
Vertices: 8
Halfedges: 24
Edges: 12
Halffacets: 12
Facets: 6
Volumes: 2
Well, I am using version 2016.11.11 . And the F6 console output for that
code with the overlapping cylinder is:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 9
Geometry cache size in bytes: 10156352
CGAL Polyhedrons in cache: 3
CGAL cache size in bytes: 62744592
Total rendering time: 0 hours, 0 minutes, 1 seconds
Top level object is a 3D object:
Facets: 2232
Rendering finished.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20137.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Yes because CGAL hasn't been called as there are no boolean ops, just a
polyhedron.
When you add a cube to the original, non overlapping, cylinders you get the
slow CGAL union and the long form output. Without it you get the short form
output.
On 17 January 2017 at 12:54, Ronaldo rcmpersiano@gmail.com wrote:
nophead wrote
Modern versions of OpenSCAD only involve CGAL when you do boolean ops.
That
is why CGAL doesn't complain. It hasn't see it yet. When you do F6 and
get
the simple output:
Top level object is a 3D object:
Facets: 6
CGAL has not been used at all. When it is you get:
Top level object is a 3D object:
Simple: yes
Vertices: 8
Halfedges: 24
Edges: 12
Halffacets: 12
Facets: 6
Volumes: 2
Well, I am using version 2016.11.11 . And the F6 console output for that
code with the overlapping cylinder is:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 9
Geometry cache size in bytes: 10156352
CGAL Polyhedrons in cache: 3
CGAL cache size in bytes: 62744592
Total rendering time: 0 hours, 0 minutes, 1 seconds
Top level object is a 3D object:
Facets: 2232
Rendering finished.
--
View this message in context: http://forum.openscad.org/
rendering-for-paper-assembly-manual-tp20108p20137.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
Is this kind of detailed understanding of CGAL written down somewhere?
It could be useful to anyone who is trying to speed optimize.
Jon
On 1/17/2017 8:05 AM, nop head wrote:
Yes because CGAL hasn't been called as there are no boolean ops, just
a polyhedron.
When you add a cube to the original, non overlapping, cylinders you
get the slow CGAL union and the long form output. Without it you get
the short form output.
On 17 January 2017 at 12:54, Ronaldo <rcmpersiano@gmail.com
mailto:rcmpersiano@gmail.com> wrote:
nophead wrote
Modern versions of OpenSCAD only involve CGAL when you do
boolean ops.
That
is why CGAL doesn't complain. It hasn't see it yet. When you do
F6 and get
the simple output:
Top level object is a 3D object:
Facets: 6
CGAL has not been used at all. When it is you get:
Top level object is a 3D object:
Simple: yes
Vertices: 8
Halfedges: 24
Edges: 12
Halffacets: 12
Facets: 6
Volumes: 2
Well, I am using version 2016.11.11 . And the F6 console output
for that
code with the overlapping cylinder is:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 9
Geometry cache size in bytes: 10156352
CGAL Polyhedrons in cache: 3
CGAL cache size in bytes: 62744592
Total rendering time: 0 hours, 0 minutes, 1 seconds
Top level object is a 3D object:
Facets: 2232
Rendering finished.
--
View this message in context:
http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20137.html
<http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20137.html>
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
<http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
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 http://www.avg.com/email-signature
Version: 2016.0.7996 / Virus Database: 4749/13786 - Release Date: 01/17/17
nophead wrote
Yes because CGAL hasn't been called as there are no boolean ops, just a
polyhedron.
When you add a cube to the original, non overlapping, cylinders you get
the
slow CGAL union and the long form output. Without it you get the short
form
output.
I have tried the Parkinbot lazy union some few months ago
http://forum.openscad.org/STL-without-render-tc17503.html#a17543 with
good results. I modified that example to overlapping spheres (all in one
same polyhedron). The code is the following:
n = 20; // $fn
m = n/2;
N = 20; // number of spheres
radius = 10;
unitary_circle = [ for(i=[0:n]) [ cos(360i/n), sin(360i/n), 0 ] ];
// sphere
sphere_vertices = radius*[ for( j=[-m/2:m/2], p=unitary_circle )
cos(180j/m) * p + [0, 0, sin(180j/m)] ];
nvert = len(sphere_vertices);
// triangulated faces of the sphere
faces = concat(
[ for(i=[0:n-1])
[ 0, n+i+1, n+i+2 ] ] ,
[ for(j=[1:m-1], i=[0:n-1])
[ (n+1)j+i+1, (n+1)j+i, (n+1)(j+1)+i ] ] ,
[ for(j=[1:m-1], i=[0:n-1])
[ (n+1)j+i+1, (n+1)(j+1)+i, (n+1)(j+1)+i+1 ] ] ,
[ for(i=[0:n-1])
[ (n+1)(m-1)+i, (n+1)(m+1)-1, (n+1)*(m-1)+i+1] ] ) ;
// vertices of the union of N spheres
unispheres = [ for(k=[1:N], p=sphere_vertices) p+[17*k,0,0] ];
// facets of the union of N spheres
unifaces = [ for(k=[1:N], f=faces) [for(i=f) i+nvert*(k-1) ] ];
difference(){
polyhedron( points = unispheres, faces = unifaces);
cube(50);
}
//sphere(10); // a regular sphere
As you see, I have included a boolean operation subtracting a cube. Using
version 2016.11.11 I have got the following F6 console output:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 5
Geometry cache size in bytes: 63999056
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 4371632
Total rendering time: 0 hours, 0 minutes, 25 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 3569
Halfedges: 19968
Edges: 9984
Halffacets: 12902
Facets: 6451
Volumes: 19
Rendering finished.
It seems, according with what you said, that CGAL was really used. And it
doesn't give a single word of warning!
Worst than that, it produced an image. Enjoy it:
http://forum.openscad.org/file/n20140/CGALoutput.png
How do you explain that?
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20140.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
How do you explain that?
CGAL
On 17 January 2017 at 13:40, Ronaldo rcmpersiano@gmail.com wrote:
nophead wrote
Yes because CGAL hasn't been called as there are no boolean ops, just a
polyhedron.
When you add a cube to the original, non overlapping, cylinders you get
the
slow CGAL union and the long form output. Without it you get the short
form
output.
I have tried the Parkinbot lazy union some few months ago
http://forum.openscad.org/STL-without-render-tc17503.html#a17543 with
good results. I modified that example to overlapping spheres (all in one
same polyhedron). The code is the following:
n = 20; // $fn
m = n/2;
N = 20; // number of spheres
radius = 10;
unitary_circle = [ for(i=[0:n]) [ cos(360i/n), sin(360i/n), 0 ] ];
// sphere
sphere_vertices = radius*[ for( j=[-m/2:m/2], p=unitary_circle )
cos(180j/m) * p + [0, 0, sin(180j/m)] ];
nvert = len(sphere_vertices);
// triangulated faces of the sphere
faces = concat(
[ for(i=[0:n-1])
[ 0, n+i+1, n+i+2 ] ] ,
[ for(j=[1:m-1], i=[0:n-1])
[ (n+1)j+i+1, (n+1)j+i, (n+1)(j+1)+i ] ] ,
[ for(j=[1:m-1], i=[0:n-1])
[ (n+1)j+i+1, (n+1)(j+1)+i, (n+1)(j+1)+i+1 ] ] ,
[ for(i=[0:n-1])
[ (n+1)(m-1)+i, (n+1)(m+1)-1, (n+1)*(m-1)+i+1] ] )
;
// vertices of the union of N spheres
unispheres = [ for(k=[1:N], p=sphere_vertices) p+[17*k,0,0] ];
// facets of the union of N spheres
unifaces = [ for(k=[1:N], f=faces) [for(i=f) i+nvert*(k-1) ] ];
difference(){
polyhedron( points = unispheres, faces = unifaces);
cube(50);
}
//sphere(10); // a regular sphere
As you see, I have included a boolean operation subtracting a cube. Using
version 2016.11.11 I have got the following F6 console output:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 5
Geometry cache size in bytes: 63999056
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 4371632
Total rendering time: 0 hours, 0 minutes, 25 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 3569
Halfedges: 19968
Edges: 9984
Halffacets: 12902
Facets: 6451
Volumes: 19
Rendering finished.
It seems, according with what you said, that CGAL was really used. And it
doesn't give a single word of warning!
Worst than that, it produced an image. Enjoy it:
http://forum.openscad.org/file/n20140/CGALoutput.png
How do you explain that?
--
View this message in context: http://forum.openscad.org/
rendering-for-paper-assembly-manual-tp20108p20140.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
How do you explain that?
CGAL expects the inputs to be manifold but it doesn't report all non
manifold meshes, just some of them.
On 17 January 2017 at 13:44, nop head nop.head@gmail.com wrote:
How do you explain that?
CGAL
On 17 January 2017 at 13:40, Ronaldo rcmpersiano@gmail.com wrote:
nophead wrote
Yes because CGAL hasn't been called as there are no boolean ops, just a
polyhedron.
When you add a cube to the original, non overlapping, cylinders you get
the
slow CGAL union and the long form output. Without it you get the short
form
output.
I have tried the Parkinbot lazy union some few months ago
http://forum.openscad.org/STL-without-render-tc17503.html#a17543 with
good results. I modified that example to overlapping spheres (all in one
same polyhedron). The code is the following:
n = 20; // $fn
m = n/2;
N = 20; // number of spheres
radius = 10;
unitary_circle = [ for(i=[0:n]) [ cos(360i/n), sin(360i/n), 0 ] ];
// sphere
sphere_vertices = radius*[ for( j=[-m/2:m/2], p=unitary_circle )
cos(180j/m) * p + [0, 0, sin(180j/m)] ];
nvert = len(sphere_vertices);
// triangulated faces of the sphere
faces = concat(
[ for(i=[0:n-1])
[ 0, n+i+1, n+i+2 ] ] ,
[ for(j=[1:m-1], i=[0:n-1])
[ (n+1)j+i+1, (n+1)j+i, (n+1)(j+1)+i ] ] ,
[ for(j=[1:m-1], i=[0:n-1])
[ (n+1)j+i+1, (n+1)(j+1)+i, (n+1)(j+1)+i+1 ] ] ,
[ for(i=[0:n-1])
[ (n+1)(m-1)+i, (n+1)(m+1)-1, (n+1)*(m-1)+i+1] ]
) ;
// vertices of the union of N spheres
unispheres = [ for(k=[1:N], p=sphere_vertices) p+[17*k,0,0] ];
// facets of the union of N spheres
unifaces = [ for(k=[1:N], f=faces) [for(i=f) i+nvert*(k-1) ] ];
difference(){
polyhedron( points = unispheres, faces = unifaces);
cube(50);
}
//sphere(10); // a regular sphere
As you see, I have included a boolean operation subtracting a cube. Using
version 2016.11.11 I have got the following F6 console output:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 5
Geometry cache size in bytes: 63999056
CGAL Polyhedrons in cache: 1
CGAL cache size in bytes: 4371632
Total rendering time: 0 hours, 0 minutes, 25 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 3569
Halfedges: 19968
Edges: 9984
Halffacets: 12902
Facets: 6451
Volumes: 19
Rendering finished.
It seems, according with what you said, that CGAL was really used. And it
doesn't give a single word of warning!
Worst than that, it produced an image. Enjoy it:
http://forum.openscad.org/file/n20140/CGALoutput.png
How do you explain that?
--
View this message in context: http://forum.openscad.org/rend
ering-for-paper-assembly-manual-tp20108p20140.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
Is this kind of detailed understanding of CGAL written down somewhere?
I don't think so. I just cleaned if from following this mailing list.
Originally OpenSCAD did all the F6 work in CGAL but to speed it up the
easier bits have been done outside of it. All the 2D stuff and things like
linear_extrude. It produces issues because different number representations
are used in 2D, 3D inside CGAL and 3D outside CGAL.
On 17 January 2017 at 13:10, jon jon@jonbondy.com wrote:
Is this kind of detailed understanding of CGAL written down somewhere? It
could be useful to anyone who is trying to speed optimize.
Jon
On 1/17/2017 8:05 AM, nop head wrote:
Yes because CGAL hasn't been called as there are no boolean ops, just a
polyhedron.
When you add a cube to the original, non overlapping, cylinders you get
the slow CGAL union and the long form output. Without it you get the short
form output.
On 17 January 2017 at 12:54, Ronaldo rcmpersiano@gmail.com wrote:
nophead wrote
Modern versions of OpenSCAD only involve CGAL when you do boolean ops.
That
is why CGAL doesn't complain. It hasn't see it yet. When you do F6 and
get
the simple output:
Top level object is a 3D object:
Facets: 6
CGAL has not been used at all. When it is you get:
Top level object is a 3D object:
Simple: yes
Vertices: 8
Halfedges: 24
Edges: 12
Halffacets: 12
Facets: 6
Volumes: 2
Well, I am using version 2016.11.11 . And the F6 console output for that
code with the overlapping cylinder is:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 9
Geometry cache size in bytes: 10156352
CGAL Polyhedrons in cache: 3
CGAL cache size in bytes: 62744592
Total rendering time: 0 hours, 0 minutes, 1 seconds
Top level object is a 3D object:
Facets: 2232
Rendering finished.
--
View this message in context: http://forum.openscad.org/rend
ering-for-paper-assembly-manual-tp20108p20137.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
OpenSCAD mailing listDiscuss@lists.openscad.orghttp://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com/email-signature
Version: 2016.0.7996 / Virus Database: 4749/13786 - Release Date: 01/17/17
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
2017-01-17 11:46 GMT-02:00 nop head nop.head@gmail.com:
How do you explain that?
CGAL expects the inputs to be manifold but it doesn't report all non
manifold meshes, just some of them.
On 17 January 2017 at 13:44, nop head nop.head@gmail.com wrote:
How do you explain that?
CGAL
Cool.