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