export() function.
On persistent cache - may be try using mmap-ed files? There is some mechanism
for it in boost
(http://www.boost.org/doc/libs/1_50_0/libs/iostreams/doc/classes/mapped_file.html),
but I have no experience with it.
On my original issue - what about reconsidering my patches and suggestions
on security enhancments?
--
View this message in context: http://forum.openscad.org/export-function-tp15428p15484.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Hi Mihail. Concerning your pull request for an export() command.
Torsten is a gatekeeper, I'm not. Torsten's response to your proposal was
more relevant and insightful than mine. The security problem is a side
issue, and the real problem is what Torsten said:
- OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue. - You can't add a procedural, side effect causing 'export()' command to
the language because it doesn't make any sense to export a shape to a file
while the script is being evaluated: this would mess up preview
performance. Once again, this is a side issue, like security. It's a
technical issue which underlies the fundamental design decision that
OpenSCAD is a declarative language (see point 1 above).
Torsten asked a number of questions about "when does this side effect
occur", which are quite relevant, and which you didn't answer.
Then Torsten proposed a design which is consistent with the OpenSCAD
philosophy. Instead of an "export" function which has the semantics of
"write this shape to a file right now", there is a syntax for adding
metadata to a node of the CSG tree, which has the semantics: this branch of
the CSG tree should be exported to a separate file, at export time. It
could have the same syntax as your proposal.
This metadata is not interpreted until some GUI command is invoked. No
files are exported during preview, render or animation, which is as it
should be. For example, the GUI "Export" command can notice that there are
multiple exported subtrees tagged in the CSG tree. It could, for example,
ask you to specify a root directory, then write all of the exported files
relative to this directory. It should also be specified how to invoke
multiple export from the CLI.
Notice how the security problem goes away when the feature is properly
designed. We are no longer invisibly exporting files without the user's
knowledge, in the case of a downloaded SCAD file. Export only happens
explicitly.
This design addresses the goal of exporting multiple files from a single
*.scad file, but it doesn't address jpmendes' problem, because his goal is
for OpenSCAD to run faster, and he wants to achieve this by persistent
caching of specified subtrees. So we've proposed an extension to the
render() operator to solve his problem.
On 4 January 2016 at 16:31, Mihail Vasiliev mickvav@gmail.com wrote:
On persistent cache - may be try using mmap-ed files? There is some
mechanism
for it in boost
(
http://www.boost.org/doc/libs/1_50_0/libs/iostreams/doc/classes/mapped_file.html
),
but I have no experience with it.
On my original issue - what about reconsidering my patches and suggestions
on security enhancments?
--
View this message in context:
http://forum.openscad.org/export-function-tp15428p15484.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
Hi, Doug, Torsten.
I'll try to answer Torsten's questions first.
- How is the difference between preview and render mode handled with
export()?
The very exact way another side-effecting operation - "echo" does.
It does it's dirty job on "instantiate" call to corresponding AbstractNode.
- Will that always force the mesh generation and export the
file on F5?
It's action is triggered at the same times as echo's.
As for now, it actually calls instantiateChildren on it's children nodes.
(I don't know, whether this function it use caches internally. I can dig
it, if it's necessary.)
Than it applies freshly-created GeometryEvaluator on the first of these
children and exports resulted geometry in supplied file, determining it's
type by it's name.
- How will that interact with animation?
Yes, I regenerates file on each frame, and can be used to create series of
exported files of each time step.
e.g. the code:
export(file=str("gg",$t,".stl")) rotate([$t*50,0,0]) cube([10,10,10]);
generates several stl files with different names, as expected.
Now on Doug's questions:
- OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue.
And why the way to output for this geometry is obligated to be declared in
command line, not in the language itself?
- You can't add a procedural, side effect causing 'export()' command to
the language because it doesn't make any sense to export a shape to a file
while the script is being evaluated: this would mess up preview
performance. Once again, this is a side issue, like security. It's a
technical issue which underlies the fundamental design decision that
OpenSCAD is a declarative language (see point 1 above).
This technocal issue can be addressed by adding some extra argument to
export to make it skip it's operation in preview mode, for example. I can
do it, as well as security restrictions, regression tests and so on, if the
community is interested in the feature itself.
2016-01-05 2:09 GMT+03:00 doug moen doug@moens.org:
Hi Mihail. Concerning your pull request for an export() command.
Torsten is a gatekeeper, I'm not. Torsten's response to your proposal was
more relevant and insightful than mine. The security problem is a side
issue, and the real problem is what Torsten said:
1. OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue.
2. You can't add a procedural, side effect causing 'export()' command
to the language because it doesn't make any sense to export a shape to a
file while the script is being evaluated: this would mess up preview
performance. Once again, this is a side issue, like security. It's a
technical issue which underlies the fundamental design decision that
OpenSCAD is a declarative language (see point 1 above).
Torsten asked a number of questions about "when does this side effect
occur", which are quite relevant, and which you didn't answer.
Then Torsten proposed a design which is consistent with the OpenSCAD
philosophy. Instead of an "export" function which has the semantics of
"write this shape to a file right now", there is a syntax for adding
metadata to a node of the CSG tree, which has the semantics: this branch of
the CSG tree should be exported to a separate file, at export time. It
could have the same syntax as your proposal.
This metadata is not interpreted until some GUI command is invoked. No
files are exported during preview, render or animation, which is as it
should be. For example, the GUI "Export" command can notice that there are
multiple exported subtrees tagged in the CSG tree. It could, for example,
ask you to specify a root directory, then write all of the exported files
relative to this directory. It should also be specified how to invoke
multiple export from the CLI.
Notice how the security problem goes away when the feature is properly
designed. We are no longer invisibly exporting files without the user's
knowledge, in the case of a downloaded SCAD file. Export only happens
explicitly.
This design addresses the goal of exporting multiple files from a single
*.scad file, but it doesn't address jpmendes' problem, because his goal is
for OpenSCAD to run faster, and he wants to achieve this by persistent
caching of specified subtrees. So we've proposed an extension to the
render() operator to solve his problem.
On 4 January 2016 at 16:31, Mihail Vasiliev mickvav@gmail.com wrote:
On persistent cache - may be try using mmap-ed files? There is some
mechanism
for it in boost
(
http://www.boost.org/doc/libs/1_50_0/libs/iostreams/doc/classes/mapped_file.html
),
but I have no experience with it.
On my original issue - what about reconsidering my patches and suggestions
on security enhancments?
--
View this message in context:
http://forum.openscad.org/export-function-tp15428p15484.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
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
- How is the difference between preview and render mode handled with
export()?
The very exact way another side-effecting operation - "echo" does.
It does it's dirty job on "instantiate" call to corresponding AbstractNode.
So it would try to generate the full mesh (aka. F6) for this part
of the model for each preview and export the file. I don't think
this is a good way of handling it. See below for more details...
- How will that interact with animation?
Yes, I regenerates file on each frame, and can be used to create series
of exported files of each time step. e.g. the code:
export(file=str("gg",$t,".stl")) rotate([$t*50,0,0]) cube([10,10,10]);
Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.
- OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue.
And why the way to output for this geometry is obligated to be declared
in command line, not in the language itself?
I would not say it's impossible to use some language feature to declare
what to export. The main issue is the immediate execution which the
code is compiled.
Trying to find the analogy to C++ here, we only have the compilation
step where you do "gcc -o program.exe file.c" and the analog part would
be "openscad -o model.stl file.scad".
So mapping the immediate execution of export() to gcc would be like
exporting another file while the compiler is running via #export file.out
or something similar.
Actually running as program does not really happen with OpenSCAD models,
as they are essentially a data structure that is evaluated by different
things.
Those things can be:
- F5 preview renderer in OpenSCAD GUI
- F6 mesh calculation in OpenSCAD GUI or command line
- various exports to different formats in OpenSCAD GUI or command line
- import into other programs, namely FreeCAD
Most notably here is the last point which highlights the interpretation
of SCAD (or it's simplified form CSG) files as data. What would FreeCAD
do with an export() node when reading the file?
It's true that echo() is also fitting into that problem area, it mainly
has the argument that there would be almost no debugging possibility
without it.
I think having some capabilities to markup/annotate parts of a model
to tell the OpenSCAD GUI what to do when interpreting the data could
cover both issues: a) leaving the scad script as a data description
while still b) allowing the user to export multiple parts at once.
All this without interfering with other programs that might want to
import the file or making the preview slow due to forced mesh generation.
Also annotations allow more control about export details, as for
instance the DXF export would benefit from defining model parts
as different layer while still exporting into a single file.
Maybe we can work together moving into that direction? The actual
feature for exporting multiple files / multiple layer would be
awesome to have and surely welcomed by a number of people.
ciao,
Torsten.
The animate feature doesn't create an output file for each frame unless
you select the "dump images" option. There's currently no option to export
each frame as stl. If we added such a feature, only then would it make
sense to export tagged subtrees as stl for each frame.
On Friday, 8 January 2016, Torsten Paul Torsten.Paul@gmx.de wrote:
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
- How is the difference between preview and render mode handled with
export()?
The very exact way another side-effecting operation - "echo" does.
It does it's dirty job on "instantiate" call to corresponding
AbstractNode.
So it would try to generate the full mesh (aka. F6) for this part
of the model for each preview and export the file. I don't think
this is a good way of handling it. See below for more details...
- How will that interact with animation?
Yes, I regenerates file on each frame, and can be used to create series
of exported files of each time step. e.g. the code:
export(file=str("gg",$t,".stl")) rotate([$t*50,0,0]) cube([10,10,10]);
Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.
- OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue.
And why the way to output for this geometry is obligated to be declared
in command line, not in the language itself?
I would not say it's impossible to use some language feature to declare
what to export. The main issue is the immediate execution which the
code is compiled.
Trying to find the analogy to C++ here, we only have the compilation
step where you do "gcc -o program.exe file.c" and the analog part would
be "openscad -o model.stl file.scad".
So mapping the immediate execution of export() to gcc would be like
exporting another file while the compiler is running via #export file.out
or something similar.
Actually running as program does not really happen with OpenSCAD models,
as they are essentially a data structure that is evaluated by different
things.
Those things can be:
- F5 preview renderer in OpenSCAD GUI
- F6 mesh calculation in OpenSCAD GUI or command line
- various exports to different formats in OpenSCAD GUI or command line
- import into other programs, namely FreeCAD
Most notably here is the last point which highlights the interpretation
of SCAD (or it's simplified form CSG) files as data. What would FreeCAD
do with an export() node when reading the file?
It's true that echo() is also fitting into that problem area, it mainly
has the argument that there would be almost no debugging possibility
without it.
I think having some capabilities to markup/annotate parts of a model
to tell the OpenSCAD GUI what to do when interpreting the data could
cover both issues: a) leaving the scad script as a data description
while still b) allowing the user to export multiple parts at once.
All this without interfering with other programs that might want to
import the file or making the preview slow due to forced mesh generation.
Also annotations allow more control about export details, as for
instance the DXF export would benefit from defining model parts
as different layer while still exporting into a single file.
Maybe we can work together moving into that direction? The actual
feature for exporting multiple files / multiple layer would be
awesome to have and surely welcomed by a number of people.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org javascript:;
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
May be it's better to leave this decision to end user, whether to use
export keyword or not?
On compatibility with other software-I'm not sure, how FreeCAD parses
unknown predicates, but if it behaves like OpenSCAD - just ignores
corresponding subtree, everythings should be fine - it will just show the
same - nothing.
8 янв. 2016 г. 9:58 PM пользователь "doug moen" doug@moens.org написал:
The animate feature doesn't create an output file for each frame unless
you select the "dump images" option. There's currently no option to export
each frame as stl. If we added such a feature, only then would it make
sense to export tagged subtrees as stl for each frame.
On Friday, 8 January 2016, Torsten Paul Torsten.Paul@gmx.de wrote:
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
- How is the difference between preview and render mode handled with
export()?
The very exact way another side-effecting operation - "echo" does.
It does it's dirty job on "instantiate" call to corresponding
AbstractNode.
So it would try to generate the full mesh (aka. F6) for this part
of the model for each preview and export the file. I don't think
this is a good way of handling it. See below for more details...
- How will that interact with animation?
Yes, I regenerates file on each frame, and can be used to create series
of exported files of each time step. e.g. the code:
export(file=str("gg",$t,".stl")) rotate([$t*50,0,0]) cube([10,10,10]);
Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.
- OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue.
And why the way to output for this geometry is obligated to be declared
in command line, not in the language itself?
I would not say it's impossible to use some language feature to declare
what to export. The main issue is the immediate execution which the
code is compiled.
Trying to find the analogy to C++ here, we only have the compilation
step where you do "gcc -o program.exe file.c" and the analog part would
be "openscad -o model.stl file.scad".
So mapping the immediate execution of export() to gcc would be like
exporting another file while the compiler is running via #export file.out
or something similar.
Actually running as program does not really happen with OpenSCAD models,
as they are essentially a data structure that is evaluated by different
things.
Those things can be:
- F5 preview renderer in OpenSCAD GUI
- F6 mesh calculation in OpenSCAD GUI or command line
- various exports to different formats in OpenSCAD GUI or command line
- import into other programs, namely FreeCAD
Most notably here is the last point which highlights the interpretation
of SCAD (or it's simplified form CSG) files as data. What would FreeCAD
do with an export() node when reading the file?
It's true that echo() is also fitting into that problem area, it mainly
has the argument that there would be almost no debugging possibility
without it.
I think having some capabilities to markup/annotate parts of a model
to tell the OpenSCAD GUI what to do when interpreting the data could
cover both issues: a) leaving the scad script as a data description
while still b) allowing the user to export multiple parts at once.
All this without interfering with other programs that might want to
import the file or making the preview slow due to forced mesh generation.
Also annotations allow more control about export details, as for
instance the DXF export would benefit from defining model parts
as different layer while still exporting into a single file.
Maybe we can work together moving into that direction? The actual
feature for exporting multiple files / multiple layer would be
awesome to have and surely welcomed by a number of people.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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....
On 1/8/2016 6:22 PM, Mihail Vasiliev wrote:
May be it's better to leave this decision to end user, whether to use
export keyword or not?
On compatibility with other software-I'm not sure, how FreeCAD parses
unknown predicates, but if it behaves like OpenSCAD - just ignores
corresponding subtree, everythings should be fine - it will just show
the same - nothing.
8 янв. 2016 г. 9:58 PM пользователь "doug moen" <doug@moens.org
mailto:doug@moens.org> написал:
The animate feature doesn't create an output file for each frame
*unless* you select the "dump images" option. There's currently no
option to export each frame as stl. *If* we added such a feature,
only then would it make sense to export tagged subtrees as stl for
each frame.
On Friday, 8 January 2016, Torsten Paul <Torsten.Paul@gmx.de
<mailto:Torsten.Paul@gmx.de>> wrote:
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
- How is the difference between preview and render mode
handled with
export()?
The very exact way another side-effecting operation - "echo"
does.
It does it's dirty job on "instantiate" call to corresponding
AbstractNode.
So it would try to generate the full mesh (aka. F6) for this part
of the model for each preview and export the file. I don't think
this is a good way of handling it. See below for more details...
- How will that interact with animation?
Yes, I regenerates file on each frame, and can be used to
create series
of exported files of each time step. e.g. the code:
export(file=str("gg",$t,".stl")) rotate([$t*50,0,0])
cube([10,10,10]);
Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.
- OpenSCAD is not a procedural programming language. It is a
purely
declarative language for describing geometry. This is the
primary issue.
And why the way to output for this geometry is obligated to
be declared
in command line, not in the language itself?
I would not say it's impossible to use some language feature to
declare
what to export. The main issue is the immediate execution which the
code is compiled.
Trying to find the analogy to C++ here, we _only_ have the
compilation
step where you do "gcc -o program.exe file.c" and the analog
part would
be "openscad -o model.stl file.scad".
So mapping the immediate execution of export() to gcc would be like
exporting another file while the compiler is running via #export
file.out
or something similar.
Actually running as program does not really happen with OpenSCAD
models,
as they are essentially a data structure that is evaluated by
different
things.
Those things can be:
* F5 preview renderer in OpenSCAD GUI
* F6 mesh calculation in OpenSCAD GUI or command line
* various exports to different formats in OpenSCAD GUI or
command line
* import into other programs, namely FreeCAD
Most notably here is the last point which highlights the
interpretation
of SCAD (or it's simplified form CSG) files as data. What would
FreeCAD
do with an export() node when reading the file?
It's true that echo() is also fitting into that problem area, it
mainly
has the argument that there would be almost no debugging possibility
without it.
I think having some capabilities to markup/annotate parts of a model
to tell the OpenSCAD GUI what to do when interpreting the data could
cover both issues: a) leaving the scad script as a data description
while still b) allowing the user to export multiple parts at once.
All this without interfering with other programs that might want to
import the file or making the preview slow due to forced mesh
generation.
Also annotations allow more control about export details, as for
instance the DXF export would benefit from defining model parts
as different layer while still exporting into a single file.
Maybe we can work together moving into that direction? The actual
feature for exporting multiple files / multiple layer would be
awesome to have and surely welcomed by a number of people.
ciao,
Torsten.
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto: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
I have very much the same workflow, and really like the idea of being
able to tag a subtree as being a logically separate, named, object.
This would allow more than just exporting groups of objects at once
(which as mentioned would be much better than rendering each part
separately and manually entering filenames). It would be really neat if
the preview window had, for instance, a dropdown where you could either
view the entire generated tree or view each of the tagged subtrees on
their own. Effectively and after-the-fact application of the re-root (!)
operator.
In this same vein, having an export option that would automatically
create a new folder for the specific export instance that is timestamped
or versioned would be very awesome. Then, the current, many-step
workflow for rendering, examining, and exporting a new version of a
multipart model would be a click or two.
~ Yona
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
Mihail Vasiliev mailto:mickvav@gmail.com
January 8, 2016 at 15:22
May be it's better to leave this decision to end user, whether to use
export keyword or not?
On compatibility with other software-I'm not sure, how FreeCAD parses
unknown predicates, but if it behaves like OpenSCAD - just ignores
corresponding subtree, everythings should be fine - it will just show
the same - nothing.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
doug moen mailto:doug@moens.org
January 8, 2016 at 10:57
The animate feature doesn't create an output file for each frame
unless you select the "dump images" option. There's currently no
option to export each frame as stl. If we added such a feature, only
then would it make sense to export tagged subtrees as stl for each frame.
On Friday, 8 January 2016, Torsten Paul <Torsten.Paul@gmx.de
mailto:Torsten.Paul@gmx.de> wrote:
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Torsten Paul mailto:Torsten.Paul@gmx.de
January 8, 2016 at 09:42
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
- How is the difference between preview and render mode handled with
export()?
The very exact way another side-effecting operation - "echo" does.
It does it's dirty job on "instantiate" call to corresponding AbstractNode.
So it would try to generate the full mesh (aka. F6) for this part
of the model for each preview and export the file. I don't think
this is a good way of handling it. See below for more details...
- How will that interact with animation?
Yes, I regenerates file on each frame, and can be used to create series
of exported files of each time step. e.g. the code:
export(file=str("gg",$t,".stl")) rotate([$t*50,0,0]) cube([10,10,10]);
Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.
- OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue.
And why the way to output for this geometry is obligated to be declared
in command line, not in the language itself?
I would not say it's impossible to use some language feature to declare
what to export. The main issue is the immediate execution which the
code is compiled.
Trying to find the analogy to C++ here, we only have the compilation
step where you do "gcc -o program.exe file.c" and the analog part would
be "openscad -o model.stl file.scad".
So mapping the immediate execution of export() to gcc would be like
exporting another file while the compiler is running via #export file.out
or something similar.
Actually running as program does not really happen with OpenSCAD models,
as they are essentially a data structure that is evaluated by different
things.
Those things can be:
- F5 preview renderer in OpenSCAD GUI
- F6 mesh calculation in OpenSCAD GUI or command line
- various exports to different formats in OpenSCAD GUI or command line
- import into other programs, namely FreeCAD
Most notably here is the last point which highlights the interpretation
of SCAD (or it's simplified form CSG) files as data. What would FreeCAD
do with an export() node when reading the file?
It's true that echo() is also fitting into that problem area, it mainly
has the argument that there would be almost no debugging possibility
without it.
I think having some capabilities to markup/annotate parts of a model
to tell the OpenSCAD GUI what to do when interpreting the data could
cover both issues: a) leaving the scad script as a data description
while still b) allowing the user to export multiple parts at once.
All this without interfering with other programs that might want to
import the file or making the preview slow due to forced mesh generation.
Also annotations allow more control about export details, as for
instance the DXF export would benefit from defining model parts
as different layer while still exporting into a single file.
Maybe we can work together moving into that direction? The actual
feature for exporting multiple files / multiple layer would be
awesome to have and surely welcomed by a number of people.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Mihail Vasiliev mailto:mickvav@gmail.com
January 6, 2016 at 11:57
Hi, Doug, Torsten.
I'll try to answer Torsten's questions first.
- How is the difference between preview and render mode handled with
export()?
The very exact way another side-effecting operation - "echo" does.
It does it's dirty job on "instantiate" call to corresponding
AbstractNode.
- Will that always force the mesh generation and export the
file on F5?
It's action is triggered at the same times as echo's.
As for now, it actually calls instantiateChildren on it's children
nodes. (I don't know, whether this function it use caches internally.
I can dig it, if it's necessary.)
Than it applies freshly-created GeometryEvaluator on the first of
these children and exports resulted geometry in supplied file,
determining it's type by it's name.
3. How will that interact with animation?
Yes, I regenerates file on each frame, and can be used to create
series of exported files of each time step.
e.g. the code:
export(file=str("gg",$t,".stl")) rotate([$t*50,0,0]) cube([10,10,10]);
generates several stl files with different names, as expected.
Now on Doug's questions:
- OpenSCAD is not a procedural programming language. It is a purely
declarative language for describing geometry. This is the primary issue.
And why the way to output for this geometry is obligated to be
declared in command line, not in the language itself?
- You can't add a procedural, side effect causing 'export()' command
to the language because it doesn't make any sense to export a shape to
a file while the script is being evaluated: this would mess up preview
performance. Once again, this is a side issue, like security. It's a
technical issue which underlies the fundamental design decision that
OpenSCAD is a declarative language (see point 1 above).
This technocal issue can be addressed by adding some extra argument to
export to make it skip it's operation in preview mode, for example. I
can do it, as well as security restrictions, regression tests and so
on, if the community is interested in the feature itself.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
would this be equivalent to allowing render() to have an export keyword ?
We have had this discussion before
http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-td8613.html
, re multi-material support.
Newly minted Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/export-function-tp15428p15583.html
Sent from the OpenSCAD mailing list archive at Nabble.com.