export() function.

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

export() function.

Mihail Vasiliev
Hello, everyone.
I've just created a pull request for export() function - lt was strange for me that a language has import() and doesn't have an export() operation, although it's available from GUI. So, I've extended export.cc module to make it support calls for export(file="test.dxf") ....;

Example:

export(file="testcube.dxf") projection(cut=true)
       translate([0,0,-1])
           cube([2,2,2]);

There is a pull request on github on this topic -

https://github.com/openscad/openscad/pull/1534
Reply | Threaded
Open this post in threaded view
|

Re: export() function.

jpmendes
This post was updated on .
Hello,

I asked for such a functionality in a previous thread.
Now only a "function" to check for the existence of a file is missing.
Please note that the code I presented then did not intend to be exact, it was only to express an idea.

http://href="http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html"


And the idea was the capability of some automation from within the code to achieve a fluid view and manipulation of complex multi-part objects. Explaining briefly: rendering a multi-part complex object can make us loose many minutes if not hours every time we start an editing session. When we start assembling a multi-part object it happens frequently that some modules are not at the right positions or that we forgot some details, so we need to look to the object from several angles to understand better what to do. If not rendered the set is almost impossible to move or rotate on the view-port, the time lag is enormous.
My solution would be: the modules that are important for the assembly would verify for a previously exported .stl file with the same name of the module. If the file exist then that part is imported, else the code would be compiled and exported as an .stl file. Since the code bellow is already possible,

module ABC() {
  import("ABC.stl");
}
 ABC();

The only thing missing  after having the export functionality working would be a function returning a flag signaling the existence of a file.

I know it is possible to have a fluid view  done from outside the script, even to have a second instance of OpenSCAD open with all stls imported, but it's not practical. It implies that the code is distributed into several files and somehow the feel of unity of the object weakens.
Now with the OpenSCAD lexer presented by runsun (thank you runsun) for the SinWrite editor, we have already the facility to better navigate in a more "complex" code  and we do not need to separate the code into several files if we are not planning for code reuse, for that I would build a library.

I read this comment by doug.moen a few hours ago.

"An export command with a file name argument permits a malicious OpenSCAD script to clobber any file in the file system for which it has write permissions. OpenSCAD is intentionally designed so that it isn't a general purpose language like Python, and it doesn't suffer from this kind of security issue."

What if limiting the file name parameter to a couple of known pacific extensions?
 
As I said in thread above I'm not a software guy nor an OpenSCAD expert and I'm not a native english speaker either, so please understand that.

Happy new year

jpmendes




tp3
Reply | Threaded
Open this post in threaded view
|

Re: export() function.

tp3
On 01/03/2016 07:26 PM, jpmendes wrote:
> My solution would be: the modules that are important for the assembly would
> verify for a previously exported .stl file with the same name of the module.
> If the file exist then that part is imported, else the code would be
> compiled and exported as an .stl file. Since the code bellow is already
> possible,
>
A persistent cache (I think there's already an issue on github for that)
could solve this specific issue too and in a way that does not need much
user interaction.

Having scad code to check for files and then automatically use those will
cause lots of headaches with outdated files that need to be updated
manually. If you open the the scad file in two instances of OpenSCAD,
funny things will happen and there might also be cross-platform issues.

How is the difference between preview and render mode handled with
export()? Will that always force the mesh generation and export the
file on F5? How will that interact with animation?

In essence, my totally personal opinion is that OpenSCAD itself should
focus on the model description part and not try to become a general
programming language. There's a huge amount of improvements possible
for making the model generation easier and more powerful.

Note that my view of model description includes (not yet available)
markup to define such things a multiple objects from one script that
could be exported in one step. But that would be a feature of the
GUI, not the description language.

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
|

export() function.

doug.moen
In reply to this post by jpmendes
In https://github.com/openscad/openscad/issues/1437 clothbot and I propose to add a persistent caching option to 'render'. This can address both jpmendes and Mihail's problem.

If we add export *and* a function for testing file existence, then openscad starts to become a scripting language for automating file management workflow. The security problem becomes worse because now you can determine what operating system is running, by testing for the existence of system files, and now you know which files to clobber using 'export', for maximum damage.

On Sunday, 3 January 2016, jpmendes <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jpmendes54@gmail.com&#39;);" target="_blank">jpmendes54@...> wrote:
Hello,

I asked for such a functionality in a previous thread.
Now only a "function" to check for the existence of a file is missing.
Please note that the code I presented then did not intend to be exact, it
was only to express an idea.

And the idea was the capability of some automation from within the code to
achieve a fluid view and manipulation of complex multi-part objects.
Explaining briefly: rendering a multi-part complex object can make us loose
many minutes if not hours every time we start an editing session. When we
start assembling a multi-part object it happens frequently that some modules
are not at the right positions or that we forgot some details, so we need to
look to the object from several angles to understand better what to do. If
not rendered the set is almost impossible to move or rotate on the
view-port, the time lag is enormous.
My solution would be: the modules that are important for the assembly would
verify for a previously exported .stl file with the same name of the module.
If the file exist then that part is imported, else the code would be
compiled and exported as an .stl file. Since the code bellow is already
possible,

module ABC() {
  import("ABC.stl");
}
 ABC();

The only thing missing  after having the export functionality working would
be a function returning a flag signaling the existence of a file.

I know it is possible to have a fluid view  done from outside the script,
even to have a second instance of OpenSCAD open with all stls imported, but
it's not practical. It implies that the code is distributed into several
files and somehow the feel of unity of the object weakens.
Now with the OpenSCAD lexer presented by runsun (thank you runsun) for the
SinWrite editor, we have already the facility to better navigate in a more
"complex" code  and we do not need to separate the code into several files
if we are not planning for code reuse, for that I would build a library.

I read this comment by doug.moen a few hours ago.

"An export command with a file name argument permits a malicious OpenSCAD
script to clobber any file in the file system for which it has write
permissions. OpenSCAD is intentionally designed so that it isn't a general
purpose language like Python, and it doesn't suffer from this kind of
security issue."

What if limiting the file name parameter to a couple of known pacific
extensions?

As I said in thread above I'm not a software guy nor an OpenSCAD expert and
I'm not a native english speaker either, so please understand that.

Happy new year

jpmendes
<http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html#a14995>



--
View this message in context: http://forum.openscad.org/export-function-tp15428p15437.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: export() function.

nophead
Yes persistent caching gets my vote as there are no changes to the language, it just gets faster.

To export multiple objects from my files I simply call them something_stl(). I have a python script that finds them and invokes the command line to export them. That would also get much faster with a persistent cache.

On 3 January 2016 at 20:26, doug moen <[hidden email]> wrote:
In https://github.com/openscad/openscad/issues/1437 clothbot and I propose to add a persistent caching option to 'render'. This can address both jpmendes and Mihail's problem.

If we add export *and* a function for testing file existence, then openscad starts to become a scripting language for automating file management workflow. The security problem becomes worse because now you can determine what operating system is running, by testing for the existence of system files, and now you know which files to clobber using 'export', for maximum damage.

On Sunday, 3 January 2016, jpmendes <[hidden email]> wrote:
Hello,

I asked for such a functionality in a previous thread.
Now only a "function" to check for the existence of a file is missing.
Please note that the code I presented then did not intend to be exact, it
was only to express an idea.

And the idea was the capability of some automation from within the code to
achieve a fluid view and manipulation of complex multi-part objects.
Explaining briefly: rendering a multi-part complex object can make us loose
many minutes if not hours every time we start an editing session. When we
start assembling a multi-part object it happens frequently that some modules
are not at the right positions or that we forgot some details, so we need to
look to the object from several angles to understand better what to do. If
not rendered the set is almost impossible to move or rotate on the
view-port, the time lag is enormous.
My solution would be: the modules that are important for the assembly would
verify for a previously exported .stl file with the same name of the module.
If the file exist then that part is imported, else the code would be
compiled and exported as an .stl file. Since the code bellow is already
possible,

module ABC() {
  import("ABC.stl");
}
 ABC();

The only thing missing  after having the export functionality working would
be a function returning a flag signaling the existence of a file.

I know it is possible to have a fluid view  done from outside the script,
even to have a second instance of OpenSCAD open with all stls imported, but
it's not practical. It implies that the code is distributed into several
files and somehow the feel of unity of the object weakens.
Now with the OpenSCAD lexer presented by runsun (thank you runsun) for the
SinWrite editor, we have already the facility to better navigate in a more
"complex" code  and we do not need to separate the code into several files
if we are not planning for code reuse, for that I would build a library.

I read this comment by doug.moen a few hours ago.

"An export command with a file name argument permits a malicious OpenSCAD
script to clobber any file in the file system for which it has write
permissions. OpenSCAD is intentionally designed so that it isn't a general
purpose language like Python, and it doesn't suffer from this kind of
security issue."

What if limiting the file name parameter to a couple of known pacific
extensions?

As I said in thread above I'm not a software guy nor an OpenSCAD expert and
I'm not a native english speaker either, so please understand that.

Happy new year

jpmendes
<http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html#a14995>



--
View this message in context: http://forum.openscad.org/export-function-tp15428p15437.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



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

Re: export() function.

Mihail Vasiliev

May be it's safe enought to permit only files with names, derived from original script name.

3 янв. 2016 г. 11:40 PM пользователь "nop head" <[hidden email]> написал:
Yes persistent caching gets my vote as there are no changes to the language, it just gets faster.

To export multiple objects from my files I simply call them something_stl(). I have a python script that finds them and invokes the command line to export them. That would also get much faster with a persistent cache.

On 3 January 2016 at 20:26, doug moen <[hidden email]> wrote:
In https://github.com/openscad/openscad/issues/1437 clothbot and I propose to add a persistent caching option to 'render'. This can address both jpmendes and Mihail's problem.

If we add export *and* a function for testing file existence, then openscad starts to become a scripting language for automating file management workflow. The security problem becomes worse because now you can determine what operating system is running, by testing for the existence of system files, and now you know which files to clobber using 'export', for maximum damage.

On Sunday, 3 January 2016, jpmendes <[hidden email]> wrote:
Hello,

I asked for such a functionality in a previous thread.
Now only a "function" to check for the existence of a file is missing.
Please note that the code I presented then did not intend to be exact, it
was only to express an idea.

And the idea was the capability of some automation from within the code to
achieve a fluid view and manipulation of complex multi-part objects.
Explaining briefly: rendering a multi-part complex object can make us loose
many minutes if not hours every time we start an editing session. When we
start assembling a multi-part object it happens frequently that some modules
are not at the right positions or that we forgot some details, so we need to
look to the object from several angles to understand better what to do. If
not rendered the set is almost impossible to move or rotate on the
view-port, the time lag is enormous.
My solution would be: the modules that are important for the assembly would
verify for a previously exported .stl file with the same name of the module.
If the file exist then that part is imported, else the code would be
compiled and exported as an .stl file. Since the code bellow is already
possible,

module ABC() {
  import("ABC.stl");
}
 ABC();

The only thing missing  after having the export functionality working would
be a function returning a flag signaling the existence of a file.

I know it is possible to have a fluid view  done from outside the script,
even to have a second instance of OpenSCAD open with all stls imported, but
it's not practical. It implies that the code is distributed into several
files and somehow the feel of unity of the object weakens.
Now with the OpenSCAD lexer presented by runsun (thank you runsun) for the
SinWrite editor, we have already the facility to better navigate in a more
"complex" code  and we do not need to separate the code into several files
if we are not planning for code reuse, for that I would build a library.

I read this comment by doug.moen a few hours ago.

"An export command with a file name argument permits a malicious OpenSCAD
script to clobber any file in the file system for which it has write
permissions. OpenSCAD is intentionally designed so that it isn't a general
purpose language like Python, and it doesn't suffer from this kind of
security issue."

What if limiting the file name parameter to a couple of known pacific
extensions?

As I said in thread above I'm not a software guy nor an OpenSCAD expert and
I'm not a native english speaker either, so please understand that.

Happy new year

jpmendes
<http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html#a14995>



--
View this message in context: http://forum.openscad.org/export-function-tp15428p15437.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



_______________________________________________
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: export() function.

jpmendes
In reply to this post by doug.moen
Hello,

For me persistent cache is welcome as I seldom make complex multi-part objects. For the guys tackling
several projects a  time it can be very hard disk consuming.
However with the limitation of the names and extensions of the exports, and placing the exported files inside the project directory, I cannot figure out where could be risk for malware propagation.
For the guys not wanting to use the export functionality the language would not be different.

And what if we had a GUI more like an IDE with a project tree, where the files could be added from other project dirs and made available locally, and all (except calls to libraries) would be kept under the project directory?  

jpmendes
Reply | Threaded
Open this post in threaded view
|

Re: export() function.

Alan Cox
On Sun, 3 Jan 2016 14:59:13 -0700 (MST)
jpmendes <[hidden email]> wrote:

> Hello,
>
> For me persistent cache is welcome as I seldom make complex multi-part
> objects. For the guys tackling
> several projects a  time it can be very hard disk consuming.

Its usually going to be smaller and easier to manage than having loads of
saved export files you have to keep remembering to clean up by hand. It's
a model that works well and has a very simple interface ("Size ?"). All
the web browsers use it for example.

Alan

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

Re: export() function.

jpmendes
I pray for the persistent cache location to be user defined. Please!!!

jpmendes
tp3
Reply | Threaded
Open this post in threaded view
|

Re: export() function.

tp3
On 01/04/2016 01:30 AM, jpmendes wrote:
> I pray for the persistent cache location to be user defined. Please!!!
>
One option would be the use of memcached, in that case OpenSCAD would
not specify a path for the actual storage.

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: export() function.

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

Re: export() function.

doug.moen
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 <[hidden email]> 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
[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: export() function.

Mihail Vasiliev
Hi, Doug, Torsten.

I'll try to answer Torsten's questions first.

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

2. 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:

1. 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?

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

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 <[hidden email]>:
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 <[hidden email]> 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
[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



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

Re: export() function.

tp3
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
> 1. 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...

> 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]);
>
Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.

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

Re: export() function.

doug.moen
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 <[hidden email]> wrote:
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
> 1. 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...

> 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]);
>
Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.

> 1. 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
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Discuss@lists.openscad.org&#39;)">Discuss@...
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: export() function.

Mihail Vasiliev

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" <[hidden email]> написал:
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 <[hidden email]> wrote:
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
> 1. 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...

> 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]);
>
Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.

> 1. 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
[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


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

Re: export() function.

shadowwynd
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" <[hidden email]
> <mailto:[hidden email]>> написал:
>
>     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 <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
>          > 1. 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...
>
>          > 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]);
>          >
>         Ok, that might be useful in some rare cases, but it looks a bit like
>         misusing the animation feature.
>
>          > 1. 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
>         [hidden email]
>         http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
>
>     _______________________________________________
>     OpenSCAD mailing list
>     [hidden email] <mailto:[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
>

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

Re: export() function.

Hypher
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

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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.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 <[hidden email]> wrote:
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
January 8, 2016 at 09:42
On 01/06/2016 08:57 PM, Mihail Vasiliev wrote:
1. 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...

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]);

Ok, that might be useful in some rare cases, but it looks a bit like
misusing the animation feature.

1. 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
January 6, 2016 at 11:57
Hi, Doug, Torsten.

I'll try to answer Torsten's questions first.

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

2. 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:

1. 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?

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

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
[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: export() function.

Neon22
would this be equivalent to allowing render() to have an export keyword ?


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

Re: export() function.

MichaelAtOz
Administrator
We have had this discussion before, re multi-material support.
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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!
123