rendering for paper assembly manual...

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

rendering for paper assembly manual...

pierrepoulpe
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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

tp3
> 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Parkinbot
In reply to this post by pierrepoulpe
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 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.

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?





Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

pierrepoulpe
In reply to this post by tp3
@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 :


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.
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

jon_bondy
In reply to this post by Parkinbot
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
> [hidden email]
> 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
>
>


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Parkinbot
In reply to this post by pierrepoulpe
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 ;-)
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Ronaldo
In reply to this post by Parkinbot
@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.
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Ronaldo
In reply to this post by pierrepoulpe
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?
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

William Adams-2
In reply to this post by Parkinbot
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:


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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

pierrepoulpe
In reply to this post by Ronaldo
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.

Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

pierrepoulpe
@William ....
beautiful... do you know the process to get to this result?

Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Parkinbot
In reply to this post by Ronaldo
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.


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.
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

William Adams-2
In reply to this post by pierrepoulpe
On Mon, Jan 16, 2017 at 10:28 AM, pierrepoulpe <[hidden email]> 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:


Hope this helps!

William



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Ronaldo
@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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Parkinbot
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Ronaldo
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. 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.
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Parkinbot
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:

$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
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

nophead
>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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Parkinbot
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 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.
Reply | Threaded
Open this post in threaded view
|

Re: rendering for paper assembly manual...

Ronaldo
In reply to this post by Parkinbot
@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:
<quote>
function acc_sum(l) =
    [for(i=0, sum=0; i<len(l); sum=sum+l[i], i=i+1) sum];
</quote>
12