J
jon
Sat, Jan 9, 2016 11:07 AM
I create modules for each part, list them at the bottom of the script,
and then use ! to create the geometry for the part that I wish to print.
On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL). This works up to the point where I
have a single part, or several parts, fail during printing /
derafting/assembly. It is an error-prone thing to manually isolate
each part, render as an STL, save it with the correct name, rinse and
repeat. Not a problem with a three-part assembly, but could be a
problem with file that generates two dozen variations on a theme.
I create modules for each part, list them at the bottom of the script,
and then use ! to create the geometry for the part that I wish to print.
On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
> I normally arrange the pieces in OpenSCAD for 3D printing (many
> discrete volumes as a single STL). This works up to the point where I
> have a single part, or several parts, fail during printing /
> derafting/assembly. It is an error-prone thing to manually isolate
> each part, render as an STL, save it with the correct name, rinse and
> repeat. Not a problem with a three-part assembly, but could be a
> problem with file that generates two dozen variations on a theme.
ER
Ezra Reynolds
Sat, Jan 9, 2016 12:26 PM
That could work well.
On 1/8/2016 10:24 PM, Mark Schafer wrote:
That could work well.
On 1/8/2016 10:24 PM, Mark Schafer wrote:
> would this be equivalent to allowing render() to have an export keyword ?
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
ER
Ezra Reynolds
Sat, Jan 9, 2016 12:38 PM
I do the same, many of my files have a list of
*!module1Name();
*!module2Name();
at the bottom so that I can easily turn pieces off and on.
However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);
}
}
I then have 100 individual volumes on a build plate which is NOT as
easy to toggle.
If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it easier
to get a specific replacement without reprinting all 100.
On 1/9/2016 6:07 AM, jon wrote:
I create modules for each part, list them at the bottom of the script,
and then use ! to create the geometry for the part that I wish to print.
On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL). This works up to the point where I
have a single part, or several parts, fail during printing /
derafting/assembly. It is an error-prone thing to manually isolate
each part, render as an STL, save it with the correct name, rinse and
repeat. Not a problem with a three-part assembly, but could be a
problem with file that generates two dozen variations on a theme.
I do the same, many of my files have a list of
*!module1Name();
*!module2Name();
at the bottom so that I can easily turn pieces off and on.
However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i*20, j*20, 0]) smallPartGenerator(i, j);
}
}
I then have 100 individual volumes on a build plate which is NOT as
easy to toggle.
If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it easier
to get a specific replacement without reprinting all 100.
On 1/9/2016 6:07 AM, jon wrote:
> I create modules for each part, list them at the bottom of the script,
> and then use ! to create the geometry for the part that I wish to print.
>
> On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
>> I normally arrange the pieces in OpenSCAD for 3D printing (many
>> discrete volumes as a single STL). This works up to the point where I
>> have a single part, or several parts, fail during printing /
>> derafting/assembly. It is an error-prone thing to manually isolate
>> each part, render as an STL, save it with the correct name, rinse and
>> repeat. Not a problem with a three-part assembly, but could be a
>> problem with file that generates two dozen variations on a theme.
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
J
jon
Sat, Jan 9, 2016 1:03 PM
I agree that this would be a useful improvement!
On 1/9/2016 7:38 AM, Ezra Reynolds wrote:
I do the same, many of my files have a list of
*!module1Name();
*!module2Name();
at the bottom so that I can easily turn pieces off and on.
However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);
}
}
I then have 100 individual volumes on a build plate which is NOT as
easy to toggle.
If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it easier
to get a specific replacement without reprinting all 100.
On 1/9/2016 6:07 AM, jon wrote:
I create modules for each part, list them at the bottom of the script,
and then use ! to create the geometry for the part that I wish to print.
On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL). This works up to the point where I
have a single part, or several parts, fail during printing /
derafting/assembly. It is an error-prone thing to manually isolate
each part, render as an STL, save it with the correct name, rinse and
repeat. Not a problem with a three-part assembly, but could be a
problem with file that generates two dozen variations on a theme.
I agree that this would be a useful improvement!
On 1/9/2016 7:38 AM, Ezra Reynolds wrote:
> I do the same, many of my files have a list of
>
> *!module1Name();
> *!module2Name();
>
> at the bottom so that I can easily turn pieces off and on.
>
> However, if using a generator:
> for (i=[0 : 10])
> {
> for (j=[0 : 10])
> {
> translate ([i*20, j*20, 0]) smallPartGenerator(i, j);
>
> }
> }
>
> I then have 100 individual volumes on a build plate which is NOT as
> easy to toggle.
>
> If we had an export command, then I could have an
> export("R"+str(i) + "C"+str(j) + ".STL");
> in the mix and get 100 STL files out of the deal; this makes it easier
> to get a specific replacement without reprinting all 100.
>
>
>
> On 1/9/2016 6:07 AM, jon wrote:
>> I create modules for each part, list them at the bottom of the script,
>> and then use ! to create the geometry for the part that I wish to print.
>>
>> On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
>>> I normally arrange the pieces in OpenSCAD for 3D printing (many
>>> discrete volumes as a single STL). This works up to the point where I
>>> have a single part, or several parts, fail during printing /
>>> derafting/assembly. It is an error-prone thing to manually isolate
>>> each part, render as an STL, save it with the correct name, rinse and
>>> repeat. Not a problem with a three-part assembly, but could be a
>>> problem with file that generates two dozen variations on a theme.
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> 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
> Version: 2016.0.7294 / Virus Database: 4489/11360 - Release Date:
> 01/09/16
>
>
NH
nop head
Sat, Jan 9, 2016 1:24 PM
Perhaps have export(file) treated the same as * for F5 and F6 but export
its subtree of geometry to the named file when a new Export "exports" menu
option is invoked. Doesn't that remove all the objections? It is just a
more convenient way of changing some *s at the bottom of the file, pressing
F6 and then invoking the Export menu. The code no longer has side effects,
the export is still an manual operation but can deliver a bunch of files.
The export doesn't appear in the CSG file but it could export a CSG file of
the things under it if the file type was CSG.
On 9 January 2016 at 13:03, jon jon@jonbondy.com wrote:
I agree that this would be a useful improvement!
On 1/9/2016 7:38 AM, Ezra Reynolds wrote:
I do the same, many of my files have a list of
*!module1Name();
*!module2Name();
at the bottom so that I can easily turn pieces off and on.
However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);
}
}
I then have 100 individual volumes on a build plate which is NOT as easy
to toggle.
If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it easier to
get a specific replacement without reprinting all 100.
On 1/9/2016 6:07 AM, jon wrote:
I create modules for each part, list them at the bottom of the script,
and then use ! to create the geometry for the part that I wish to print.
On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL). This works up to the point where I
have a single part, or several parts, fail during printing /
derafting/assembly. It is an error-prone thing to manually isolate
each part, render as an STL, save it with the correct name, rinse and
repeat. Not a problem with a three-part assembly, but could be a
problem with file that generates two dozen variations on a theme.
Perhaps have export(file) treated the same as * for F5 and F6 but export
its subtree of geometry to the named file when a new Export "exports" menu
option is invoked. Doesn't that remove all the objections? It is just a
more convenient way of changing some *s at the bottom of the file, pressing
F6 and then invoking the Export menu. The code no longer has side effects,
the export is still an manual operation but can deliver a bunch of files.
The export doesn't appear in the CSG file but it could export a CSG file of
the things under it if the file type was CSG.
On 9 January 2016 at 13:03, jon <jon@jonbondy.com> wrote:
> I agree that this would be a useful improvement!
>
>
> On 1/9/2016 7:38 AM, Ezra Reynolds wrote:
>
>> I do the same, many of my files have a list of
>>
>> *!module1Name();
>> *!module2Name();
>>
>> at the bottom so that I can easily turn pieces off and on.
>>
>> However, if using a generator:
>> for (i=[0 : 10])
>> {
>> for (j=[0 : 10])
>> {
>> translate ([i*20, j*20, 0]) smallPartGenerator(i, j);
>>
>> }
>> }
>>
>> I then have 100 individual volumes on a build plate which is NOT as easy
>> to toggle.
>>
>> If we had an export command, then I could have an
>> export("R"+str(i) + "C"+str(j) + ".STL");
>> in the mix and get 100 STL files out of the deal; this makes it easier to
>> get a specific replacement without reprinting all 100.
>>
>>
>>
>> On 1/9/2016 6:07 AM, jon wrote:
>>
>>> I create modules for each part, list them at the bottom of the script,
>>> and then use ! to create the geometry for the part that I wish to print.
>>>
>>> On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
>>>
>>>> I normally arrange the pieces in OpenSCAD for 3D printing (many
>>>> discrete volumes as a single STL). This works up to the point where I
>>>> have a single part, or several parts, fail during printing /
>>>> derafting/assembly. It is an error-prone thing to manually isolate
>>>> each part, render as an STL, save it with the correct name, rinse and
>>>> repeat. Not a problem with a three-part assembly, but could be a
>>>> problem with file that generates two dozen variations on a theme.
>>>>
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> 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
>> Version: 2016.0.7294 / Virus Database: 4489/11360 - Release Date: 01/09/16
>>
>>
>>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
YA
Yona Appletree
Sat, Jan 9, 2016 6:43 PM
Sounds pretty much exactly like what I'm looking for -- in addition to
being able to preview just one component from a drop-down menu post render.
nop head mailto:nop.head@gmail.com
January 9, 2016 at 05:24
Perhaps have export(file) treated the same as * for F5 and F6 but
export its subtree of geometry to the named file when a new Export
"exports" menu option is invoked. Doesn't that remove all the
objections? It is just a more convenient way of changing some *s at
the bottom of the file, pressing F6 and then invoking the Export menu.
The code no longer has side effects, the export is still an manual
operation but can deliver a bunch of files. The export doesn't appear
in the CSG file but it could export a CSG file of the things under it
if the file type was CSG.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
jon mailto:jon@jonbondy.com
January 9, 2016 at 05:03
I agree that this would be a useful improvement!
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Ezra Reynolds mailto:shadowwynd@gmail.com
January 9, 2016 at 04:38
I do the same, many of my files have a list of
*!module1Name();
*!module2Name();
at the bottom so that I can easily turn pieces off and on.
However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);
}
}
I then have 100 individual volumes on a build plate which is NOT as
easy to toggle.
If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it easier
to get a specific replacement without reprinting all 100.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
jon mailto:jon@jonbondy.com
January 9, 2016 at 03:07
I create modules for each part, list them at the bottom of the script,
and then use ! to create the geometry for the part that I wish to print.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Ezra Reynolds mailto:shadowwynd@gmail.com
January 8, 2016 at 18:59
I wouldn't use FreeCAD as a barometer of compatibility, as it doesn't
support hull() or offset() as of the most current version (hull is
split into its components, offset throws nasty errors).
I have created many designs that have multiple subassemblies. They
are all inter-related pieces of the same design (e.g. top, bottom,
middle, with matching screw-holes, standoffs, etc.) Since they share
variables, it is logical for them to to share a .SCAD file. Yes, I
know how to use a batch file or script to do all this, but I would say
it is more
I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL). This works up to the point where I
have a single part, or several parts, fail during printing /
derafting/assembly. It is an error-prone thing to manually isolate
each part, render as an STL, save it with the correct name, rinse and
repeat. Not a problem with a three-part assembly, but could be a
problem with file that generates two dozen variations on a theme.
For my needs, an export("part1.stl") {subtree} approach would work,
where the subtree is rendered to screen/cache (exactly like render()),
but is also exported to disk as the last step of the process.
For example:
export("top.stl") top();
translate ([20, 0, 0]) export("middle.stl") middle ();
translate ([-20, 0, 0]) export("bottom.stl") bottom();
F5 Preview - no difference, objects are rendered and shown
F6 Render - objects are rendered, displayed on screen. Export
subtrees are written to disk, allowing user to still save whole render
as .STL or .AMF or whatever. This guarantees I have a current (top,
middle, bottom) and not a top from two revisions ago.
Or maybe have a "Super F6" (shift+F6?) that handles the export()
commands or whatever other metadata functions we need. I like
doug.moen's suggestion about handling this as metadata; you could
implement as a post-process function.
From my vantage point, export is still "Object Description" and not
"general programming"; it is describing the shape of the sub object,
and how it stored on the disk.
One potential problem that hasn't been mentioned is that if export()
triggers a render+write RIGHT NOW that can lead to a race condition;
if I export "X.stl" and use "X.stl" in other parts of the same file -
does it use the previous "X.stl" or the just-rendered version....
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Sounds pretty much exactly like what I'm looking for -- in addition to
being able to preview just one component from a drop-down menu post render.
> nop head <mailto:nop.head@gmail.com>
> January 9, 2016 at 05:24
> Perhaps have export(file) treated the same as * for F5 and F6 but
> export its subtree of geometry to the named file when a new Export
> "exports" menu option is invoked. Doesn't that remove all the
> objections? It is just a more convenient way of changing some *s at
> the bottom of the file, pressing F6 and then invoking the Export menu.
> The code no longer has side effects, the export is still an manual
> operation but can deliver a bunch of files. The export doesn't appear
> in the CSG file but it could export a CSG file of the things under it
> if the file type was CSG.
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> jon <mailto:jon@jonbondy.com>
> January 9, 2016 at 05:03
> I agree that this would be a useful improvement!
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> Ezra Reynolds <mailto:shadowwynd@gmail.com>
> January 9, 2016 at 04:38
> I do the same, many of my files have a list of
>
> *!module1Name();
> *!module2Name();
>
> at the bottom so that I can easily turn pieces off and on.
>
> However, if using a generator:
> for (i=[0 : 10])
> {
> for (j=[0 : 10])
> {
> translate ([i*20, j*20, 0]) smallPartGenerator(i, j);
>
> }
> }
>
> I then have 100 individual volumes on a build plate which is NOT as
> easy to toggle.
>
> If we had an export command, then I could have an
> export("R"+str(i) + "C"+str(j) + ".STL");
> in the mix and get 100 STL files out of the deal; this makes it easier
> to get a specific replacement without reprinting all 100.
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> jon <mailto:jon@jonbondy.com>
> January 9, 2016 at 03:07
> I create modules for each part, list them at the bottom of the script,
> and then use ! to create the geometry for the part that I wish to print.
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> Ezra Reynolds <mailto:shadowwynd@gmail.com>
> January 8, 2016 at 18:59
> I wouldn't use FreeCAD as a barometer of compatibility, as it doesn't
> support hull() or offset() as of the most current version (hull is
> split into its components, offset throws nasty errors).
>
> I have created many designs that have multiple subassemblies. They
> are all inter-related pieces of the same design (e.g. top, bottom,
> middle, with matching screw-holes, standoffs, etc.) Since they share
> variables, it is logical for them to to share a .SCAD file. Yes, I
> know how to use a batch file or script to do all this, but I would say
> it is more
>
> I normally arrange the pieces in OpenSCAD for 3D printing (many
> discrete volumes as a single STL). This works up to the point where I
> have a single part, or several parts, fail during printing /
> derafting/assembly. It is an error-prone thing to manually isolate
> each part, render as an STL, save it with the correct name, rinse and
> repeat. Not a problem with a three-part assembly, but could be a
> problem with file that generates two dozen variations on a theme.
>
>
> For my needs, an export("part1.stl") {subtree} approach would work,
> where the subtree is rendered to screen/cache (exactly like render()),
> but is also exported to disk as the last step of the process.
>
> For example:
> export("top.stl") top();
> translate ([20, 0, 0]) export("middle.stl") middle ();
> translate ([-20, 0, 0]) export("bottom.stl") bottom();
>
> F5 Preview - no difference, objects are rendered and shown
>
> F6 Render - objects are rendered, displayed on screen. Export
> subtrees are written to disk, allowing user to still save whole render
> as .STL or .AMF or whatever. This guarantees I have a current (top,
> middle, bottom) and not a top from two revisions ago.
>
> Or maybe have a "Super F6" (shift+F6?) that handles the export()
> commands or whatever other metadata functions we need. I like
> doug.moen's suggestion about handling this as metadata; you could
> implement as a post-process function.
>
> From my vantage point, export is still "Object Description" and not
> "general programming"; it is describing the shape of the sub object,
> and how it stored on the disk.
>
> One potential problem that hasn't been mentioned is that if export()
> triggers a render+write RIGHT NOW that can lead to a race condition;
> if I export "X.stl" and use "X.stl" in other parts of the same file -
> does it use the previous "X.stl" or the just-rendered version....
>
>
>
>
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
TP
Torsten Paul
Sat, Jan 9, 2016 6:59 PM
On 01/09/2016 07:43 PM, Yona Appletree wrote:
nop head mailto:nop.head@gmail.com
January 9, 2016 at 05:24
Perhaps have export(file) treated the same as * for F5 and F6 but export its subtree of geometry to the named file when a new Export
"exports" menu option is invoked. Doesn't that remove all the objections? It is just a more convenient way of changing some *s at the
bottom of the file, pressing F6 and then invoking the Export menu. The code no longer has side effects, the export is still an manual
operation but can deliver a bunch of files. The export doesn't appear in the CSG file but it could export a CSG file of the things under
it if the file type was CSG.
Sounds pretty much exactly like what I'm looking for -- in addition to being able to preview just one component from a drop-down menu post
render.
Well, that's exactly what I'm talking about. Just with the additional
suggestion to use a different syntax that does not produce the confusion
of that export() "not being executed" when pressing F6 and allow more
flexibility to also handle DXF layers or AMF multi-volumes and such
things.
Having the separate syntax also means there's no need to mess with
the CSG files. We can simply export the data as it is.
Note that one rule is that exported CSG files can be read by OpenSCAD
again and are supposed to produce exactly the same model as the
original SCAD file. For 99.9% of files that works (problem is having
inf or NaN values) and is validated by the test suite.
ciao,
Torsten.
On 01/09/2016 07:43 PM, Yona Appletree wrote:
>>
>> nop head <mailto:nop.head@gmail.com>
>> January 9, 2016 at 05:24
>> Perhaps have export(file) treated the same as * for F5 and F6 but export its subtree of geometry to the named file when a new Export
>> "exports" menu option is invoked. Doesn't that remove all the objections? It is just a more convenient way of changing some *s at the
>> bottom of the file, pressing F6 and then invoking the Export menu. The code no longer has side effects, the export is still an manual
>> operation but can deliver a bunch of files. The export doesn't appear in the CSG file but it could export a CSG file of the things under
>> it if the file type was CSG.
>>
> Sounds pretty much exactly like what I'm looking for -- in addition to being able to preview just one component from a drop-down menu post
> render.
>
Well, that's exactly what I'm talking about. Just with the additional
suggestion to use a different syntax that does not produce the confusion
of that export() "not being executed" when pressing F6 and allow more
flexibility to also handle DXF layers or AMF multi-volumes and such
things.
Having the separate syntax also means there's no need to mess with
the CSG files. We can simply export the data as it is.
Note that one rule is that exported CSG files can be read by OpenSCAD
again and are supposed to produce exactly the same model as the
original SCAD file. For 99.9% of files that works (problem is having
inf or NaN values) and is validated by the test suite.
ciao,
Torsten.
GW
G. Wade Johnson
Sat, Jan 9, 2016 7:01 PM
I do the same, many of my files have a list of
*!module1Name();
*!module2Name();
I like that approach.
In many of my more complicated designs I have something like:
plate="combined";
if( plate == "part1" )
{
module1Name();
}
if( plate == "part2" )
{
module2Name();
}
if( plate == "combined" )
{
translate([-20,-20, 0]) module1Name();
translate([ 20, 20, 0]) module2Name();
}
This makes it easy to generate specific versions using openscad on the
command line. It works particularly well driven by make.
G. Wade
at the bottom so that I can easily turn pieces off and on.
However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);
}
}
I then have 100 individual volumes on a build plate which is NOT as
easy to toggle.
If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it
easier to get a specific replacement without reprinting all 100.
On 1/9/2016 6:07 AM, jon wrote:
I create modules for each part, list them at the bottom of the
script, and then use ! to create the geometry for the part that I
wish to print.
On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL). This works up to the point
where I have a single part, or several parts, fail during
printing / derafting/assembly. It is an error-prone thing to
manually isolate each part, render as an STL, save it with the
correct name, rinse and repeat. Not a problem with a three-part
assembly, but could be a problem with file that generates two
dozen variations on a theme.
--
You need at least two viewpoints to have perspective.
-- Rick Hoselton
On Sat, 09 Jan 2016 07:38:30 -0500
Ezra Reynolds <shadowwynd@gmail.com> wrote:
> I do the same, many of my files have a list of
>
> *!module1Name();
> *!module2Name();
I like that approach.
In many of my more complicated designs I have something like:
plate="combined";
if( plate == "part1" )
{
module1Name();
}
if( plate == "part2" )
{
module2Name();
}
if( plate == "combined" )
{
translate([-20,-20, 0]) module1Name();
translate([ 20, 20, 0]) module2Name();
}
This makes it easy to generate specific versions using openscad on the
command line. It works particularly well driven by make.
G. Wade
> at the bottom so that I can easily turn pieces off and on.
>
> However, if using a generator:
> for (i=[0 : 10])
> {
> for (j=[0 : 10])
> {
> translate ([i*20, j*20, 0]) smallPartGenerator(i, j);
>
> }
> }
>
> I then have 100 individual volumes on a build plate which is NOT as
> easy to toggle.
>
> If we had an export command, then I could have an
> export("R"+str(i) + "C"+str(j) + ".STL");
> in the mix and get 100 STL files out of the deal; this makes it
> easier to get a specific replacement without reprinting all 100.
>
>
>
> On 1/9/2016 6:07 AM, jon wrote:
> > I create modules for each part, list them at the bottom of the
> > script, and then use ! to create the geometry for the part that I
> > wish to print.
> >
> > On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
> >> I normally arrange the pieces in OpenSCAD for 3D printing (many
> >> discrete volumes as a single STL). This works up to the point
> >> where I have a single part, or several parts, fail during
> >> printing / derafting/assembly. It is an error-prone thing to
> >> manually isolate each part, render as an STL, save it with the
> >> correct name, rinse and repeat. Not a problem with a three-part
> >> assembly, but could be a problem with file that generates two
> >> dozen variations on a theme.
> >
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > 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
--
You need at least two viewpoints to have perspective.
-- Rick Hoselton
GF
Greg Frost
Sat, Jan 9, 2016 9:25 PM
What if instead of export(), you could just tag a part of the tree with a name. Then when you do export, there could be an option to export subtrees where you give a base name for the export and each tagged subtree is exported with a filename constructed by appending the subtree's name to the base name.
You would have to think about what to do if two things were tagged with the same name.
Greg Frost
I do the same, many of my files have a list of
*!module1Name();
*!module2Name();
I like that approach.
In many of my more complicated designs I have something like:
plate="combined";
if( plate == "part1" )
{
module1Name();
}
if( plate == "part2" )
{
module2Name();
}
if( plate == "combined" )
{
translate([-20,-20, 0]) module1Name();
translate([ 20, 20, 0]) module2Name();
}
This makes it easy to generate specific versions using openscad on the
command line. It works particularly well driven by make.
G. Wade
at the bottom so that I can easily turn pieces off and on.
However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);
}
}
I then have 100 individual volumes on a build plate which is NOT as
easy to toggle.
If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it
easier to get a specific replacement without reprinting all 100.
On 1/9/2016 6:07 AM, jon wrote:
I create modules for each part, list them at the bottom of the
script, and then use ! to create the geometry for the part that I
wish to print.
On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL). This works up to the point
where I have a single part, or several parts, fail during
printing / derafting/assembly. It is an error-prone thing to
manually isolate each part, render as an STL, save it with the
correct name, rinse and repeat. Not a problem with a three-part
assembly, but could be a problem with file that generates two
dozen variations on a theme.
What if instead of export(), you could just tag a part of the tree with a name. Then when you do export, there could be an option to export subtrees where you give a base name for the export and each tagged subtree is exported with a filename constructed by appending the subtree's name to the base name.
You would have to think about what to do if two things were tagged with the same name.
Greg Frost
> On 10 Jan 2016, at 5:31 am, "G. Wade Johnson" <gwadej@anomaly.org> wrote:
>
> On Sat, 09 Jan 2016 07:38:30 -0500
> Ezra Reynolds <shadowwynd@gmail.com> wrote:
>
>> I do the same, many of my files have a list of
>>
>> *!module1Name();
>> *!module2Name();
>
> I like that approach.
>
> In many of my more complicated designs I have something like:
>
> plate="combined";
> if( plate == "part1" )
> {
> module1Name();
> }
> if( plate == "part2" )
> {
> module2Name();
> }
> if( plate == "combined" )
> {
> translate([-20,-20, 0]) module1Name();
> translate([ 20, 20, 0]) module2Name();
> }
>
> This makes it easy to generate specific versions using openscad on the
> command line. It works particularly well driven by make.
>
> G. Wade
>
>> at the bottom so that I can easily turn pieces off and on.
>>
>> However, if using a generator:
>> for (i=[0 : 10])
>> {
>> for (j=[0 : 10])
>> {
>> translate ([i*20, j*20, 0]) smallPartGenerator(i, j);
>>
>> }
>> }
>>
>> I then have 100 individual volumes on a build plate which is NOT as
>> easy to toggle.
>>
>> If we had an export command, then I could have an
>> export("R"+str(i) + "C"+str(j) + ".STL");
>> in the mix and get 100 STL files out of the deal; this makes it
>> easier to get a specific replacement without reprinting all 100.
>>
>>
>>
>>> On 1/9/2016 6:07 AM, jon wrote:
>>> I create modules for each part, list them at the bottom of the
>>> script, and then use ! to create the geometry for the part that I
>>> wish to print.
>>>
>>>> On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
>>>> I normally arrange the pieces in OpenSCAD for 3D printing (many
>>>> discrete volumes as a single STL). This works up to the point
>>>> where I have a single part, or several parts, fail during
>>>> printing / derafting/assembly. It is an error-prone thing to
>>>> manually isolate each part, render as an STL, save it with the
>>>> correct name, rinse and repeat. Not a problem with a three-part
>>>> assembly, but could be a problem with file that generates two
>>>> dozen variations on a theme.
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> 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
>
>
> --
> You need at least two viewpoints to have perspective.
> -- Rick Hoselton
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
MV
Mihail Vasiliev
Sun, Jan 10, 2016 11:49 AM
Ok, let's try to create a short resume of the discussion.
-
The feature itself is expected by at least some (or even most of)
people, who posted their opinions here.
-
People are interested in having options to control, when export is
performing it's action - preview or render mode.
-
There are security and unpredicted behavior issues:
3a when exporting to arbitrary file.
3b when importing and exporting from/to the same file.
-
There is a separate, but extremely interesting idea on giving names/tags
to subtrees. I think it's worth separate discussion. Like having a
function, which fetches such name from subtree to be able to do something
like:
module mymod(){
name("My Super Module");
...
};
export(file=nameofchild()+".stl") mymod();
Or even place texts with module names on top of the modules themself (seems
fun, but not sure, whether it is needed by someone at all).
If I have missed something, correct me please.
So, I have a simple question to maintainers - if I address the issues 1-3,
will these patches be accepted (after technical review, cleanup, whatever)?
What I'm planing to do:
2. Add options to export()
onrender=true|false, default - true
onpreview=true|false, default - true
// At this point I want to add undiscussed option
show=true|false, default - true, to control, whether just-exported subtree
should be shown on screen.
3a. Limit export operations to current working directory. Limit characters,
allowed in filenames to some known-safe set.
3b. Store all export/import filenames in some common (global?) data
structure to prevent loops.
10 янв. 2016 г. 12:26 AM пользователь "Greg Frost" <
gregorybartonfrost@gmail.com> написал:
What if instead of export(), you could just tag a part of the tree with a
name. Then when you do export, there could be an option to export subtrees
where you give a base name for the export and each tagged subtree is
exported with a filename constructed by appending the subtree's name to the
base name.
You would have to think about what to do if two things were tagged with
the same name.
Greg Frost
I do the same, many of my files have a list of
*!module1Name();
*!module2Name();
I like that approach.
In many of my more complicated designs I have something like:
plate="combined";
if( plate == "part1" )
{
module1Name();
}
if( plate == "part2" )
{
module2Name();
}
if( plate == "combined" )
{
translate([-20,-20, 0]) module1Name();
translate([ 20, 20, 0]) module2Name();
}
This makes it easy to generate specific versions using openscad on the
command line. It works particularly well driven by make.
G. Wade
at the bottom so that I can easily turn pieces off and on.
However, if using a generator:
for (i=[0 : 10])
{
for (j=[0 : 10])
{
translate ([i20, j20, 0]) smallPartGenerator(i, j);
}
}
I then have 100 individual volumes on a build plate which is NOT as
easy to toggle.
If we had an export command, then I could have an
export("R"+str(i) + "C"+str(j) + ".STL");
in the mix and get 100 STL files out of the deal; this makes it
easier to get a specific replacement without reprinting all 100.
On 1/9/2016 6:07 AM, jon wrote:
I create modules for each part, list them at the bottom of the
script, and then use ! to create the geometry for the part that I
wish to print.
On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
I normally arrange the pieces in OpenSCAD for 3D printing (many
discrete volumes as a single STL). This works up to the point
where I have a single part, or several parts, fail during
printing / derafting/assembly. It is an error-prone thing to
manually isolate each part, render as an STL, save it with the
correct name, rinse and repeat. Not a problem with a three-part
assembly, but could be a problem with file that generates two
dozen variations on a theme.
Ok, let's try to create a short resume of the discussion.
1. The feature itself is expected by at least some (or even most of)
people, who posted their opinions here.
2. People are interested in having options to control, when export is
performing it's action - preview or render mode.
3. There are security and unpredicted behavior issues:
3a when exporting to arbitrary file.
3b when importing and exporting from/to the same file.
4. There is a separate, but extremely interesting idea on giving names/tags
to subtrees. I think it's worth separate discussion. Like having a
function, which fetches such name from subtree to be able to do something
like:
module mymod(){
name("My Super Module");
...
};
export(file=nameofchild()+".stl") mymod();
Or even place texts with module names on top of the modules themself (seems
fun, but not sure, whether it is needed by someone at all).
If I have missed something, correct me please.
So, I have a simple question to maintainers - if I address the issues 1-3,
will these patches be accepted (after technical review, cleanup, whatever)?
What I'm planing to do:
2. Add options to export()
onrender=true|false, default - true
onpreview=true|false, default - true
// At this point I want to add undiscussed option
show=true|false, default - true, to control, whether just-exported subtree
should be shown on screen.
3a. Limit export operations to current working directory. Limit characters,
allowed in filenames to some known-safe set.
3b. Store all export/import filenames in some common (global?) data
structure to prevent loops.
10 янв. 2016 г. 12:26 AM пользователь "Greg Frost" <
gregorybartonfrost@gmail.com> написал:
> What if instead of export(), you could just tag a part of the tree with a
> name. Then when you do export, there could be an option to export subtrees
> where you give a base name for the export and each tagged subtree is
> exported with a filename constructed by appending the subtree's name to the
> base name.
>
> You would have to think about what to do if two things were tagged with
> the same name.
>
> Greg Frost
>
> > On 10 Jan 2016, at 5:31 am, "G. Wade Johnson" <gwadej@anomaly.org>
> wrote:
> >
> > On Sat, 09 Jan 2016 07:38:30 -0500
> > Ezra Reynolds <shadowwynd@gmail.com> wrote:
> >
> >> I do the same, many of my files have a list of
> >>
> >> *!module1Name();
> >> *!module2Name();
> >
> > I like that approach.
> >
> > In many of my more complicated designs I have something like:
> >
> > plate="combined";
> > if( plate == "part1" )
> > {
> > module1Name();
> > }
> > if( plate == "part2" )
> > {
> > module2Name();
> > }
> > if( plate == "combined" )
> > {
> > translate([-20,-20, 0]) module1Name();
> > translate([ 20, 20, 0]) module2Name();
> > }
> >
> > This makes it easy to generate specific versions using openscad on the
> > command line. It works particularly well driven by make.
> >
> > G. Wade
> >
> >> at the bottom so that I can easily turn pieces off and on.
> >>
> >> However, if using a generator:
> >> for (i=[0 : 10])
> >> {
> >> for (j=[0 : 10])
> >> {
> >> translate ([i*20, j*20, 0]) smallPartGenerator(i, j);
> >>
> >> }
> >> }
> >>
> >> I then have 100 individual volumes on a build plate which is NOT as
> >> easy to toggle.
> >>
> >> If we had an export command, then I could have an
> >> export("R"+str(i) + "C"+str(j) + ".STL");
> >> in the mix and get 100 STL files out of the deal; this makes it
> >> easier to get a specific replacement without reprinting all 100.
> >>
> >>
> >>
> >>> On 1/9/2016 6:07 AM, jon wrote:
> >>> I create modules for each part, list them at the bottom of the
> >>> script, and then use ! to create the geometry for the part that I
> >>> wish to print.
> >>>
> >>>> On 1/8/2016 9:59 PM, Ezra Reynolds wrote:
> >>>> I normally arrange the pieces in OpenSCAD for 3D printing (many
> >>>> discrete volumes as a single STL). This works up to the point
> >>>> where I have a single part, or several parts, fail during
> >>>> printing / derafting/assembly. It is an error-prone thing to
> >>>> manually isolate each part, render as an STL, save it with the
> >>>> correct name, rinse and repeat. Not a problem with a three-part
> >>>> assembly, but could be a problem with file that generates two
> >>>> dozen variations on a theme.
> >>>
> >>>
> >>> _______________________________________________
> >>> OpenSCAD mailing list
> >>> 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
> >
> >
> > --
> > You need at least two viewpoints to have perspective.
> > -- Rick Hoselton
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > 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
>
