On Sun, 10 Jan 2016 14:49:15 +0300
Mihail Vasiliev mickvav@gmail.com wrote:

I'm surprised we need an export() given that you really need render() to
force the right behaviour.  render(export="xx") might be saner but that
is a minor point.

Or neither or both. However that's nothing to do with export(). It's a
matter of having a variable saying which mode you are in. That is
immediately way more powerful and cleaner.

Even better but a separate issue might also be having a "view" variable
that two fn keys inc/dec so that you can flip between views as programmed.

Any file can be a security issue. Even writing just files ending ".stl"
into the current directory can be used to overwrite existing stuff, while
not overwriting has its own set of usability problems.

There is no simple known safe set (eg "AUX" in windows) but you can get
close. Another alternative is to strip any pathname elements out and
place all the render components in a subdirectory based upon the name of
the original

ie

foo.scad

produces
components-foo/*.stl

(you'll notice this is basically what for example Firefox does saving web
pages)

Alan

I don't think export should ever do anything in preview or render except
cause it children to be ignored. Making what it does optional does not
solve any of the objections raised about side effects, security and race
conditions. It should only export on a menu action and then show the files
names it has generated and the directory they will go into like a normal
export file dialog. The only complication is there are multiple files
rather than one.

There is no need for new syntax for meta data tagging. You can always
explicitly put what you want exported under the export statement.

On 10 January 2016 at 11:49, Mihail Vasiliev mickvav@gmail.com wrote:

On 01/10/2016 01:13 PM, nop head wrote:

Ok, we also have https://github.com/openscad/openscad/issues/1044
which asks for a way to control the layers that will be exported
to DXF. And there's a number of other similar requests already. How
would you do that with multiple file exports? Put all the various
possible inputs as parameters into one single export() which is then
called sometimes with parameterset A (for dxf layers) and sometimes
for parameterset B (for defining a file export)? This would also
mean the export() calls would need to be nested as the layers belong
into a single file.

With just tagging the subtrees, it leaves the interpretation to
the actual export function which could even show that information
to the user and allow changing it.

Note1: The syntax is just the Java one, lots of other languages
have adopted this feature with a different syntax, we would be
free to choose.

Note2: The prototype implementing this is already there and it's
actually not very complicated. The complex part is as always the
GUI. I also like to point out how this prototype is for a completely
different feature (https://github.com/openscad/openscad/issues/722)
and that would also be covered using the same syntax, maybe at
other places in the code, like the module definition instead of
the module instantiation.

module something(s) {
square(s * 10);
}

module part(r) {
@DxfLayer("layer1")
rotate(r) something(10);

@DxfLayer("layer2")
rotate(r) something(20);

}

@Export(name = "part1")
part1(0);

@Export(name = "part2")
part1(45);

Basically this simply attaches a set of key/value pairs to the
nodes which then can be interpreted when traversing the models
node tree.

Slic3r supports annotations in AMF files, to define some
properties for slicing a model. Even that could be handled
like @AMFMetaData(name = "slic3r.extruder", value = 1) and
would be silently ignore for STL export which does not have
any means to store this information.

ciao,
Torsten.

I think being able to put multiple layers in a DXF or multiple materials in
an AMF is completely orthogonal functionality to being able to export
multiple files using the export menu. They can both be implemented
separately and will simple work together when you export a tree that makes
a multi component file.

I.e. If you export a DXF then it is exactly the same as removing a * or
adding a !, doing F6 (or F5 if it is a png) and using the export menu. My
proposed export simply automates what you can already with *,! and the
export menu but is tedious. I don't see why designing a multi-material
system needs to hold up this simple function.

My preferred way of doing multi-materials would be to attach attributes
exactly the same way color does, rather than borrowing more syntax from
other languages. Keep it looking like C as much as possible. I wouldn't
have chosen C myself as I prefer Python syntax but as it started out almost
pure C syntax I think it should stay that way.

On 10 January 2016 at 16:25, Torsten Paul Torsten.Paul@gmx.de wrote:

On 01/10/2016 05:47 PM, nop head wrote:

Interesting, even Python has similar features for functions.
http://python-future.org/func_annotations.html

And when looking at python decorators, the syntax almost matches
the Java syntax, I've used as example:
http://thecodeship.com/patterns/guide-to-python-function-decorators/
Although those are serving a bit different purpose, I think.

As I said, the specific syntax is just a prototype so far. It
does not really matter. Unfortunately C does not have annotations
so we can't borrow that syntax. But you could also argue that SCAD
looks like C# and we could try to use that syntax.

I think the key word here is attach. And that's precisely what
color() right now does not do. It creates a new tree node, so
if you traverse the node tree, there's a separate color node.
This actually makes things more complicated internally.

ciao,
Torsten.

I think your last point is implementation details, which should not really
dictate language syntax.  From the outside I don't see any logical
difference between color and material and isn't everything a tree node in
openscad? It is however a big subject when you consider what happens with
respect to CGS ops (that isn't even right for colours yet). I don't think
it should hold up this or have any bearing on it.

I would prefer to keep the syntax as small as possible and not grabbed from
other, far more complicated, languages. Otherwise you might as well write
in those languages and generate scad files, as many people do.

module mydx() {
layer("outlines") { // note I have no idea what DXF layers names look
like.
...
}
layer("engrave") {
...
}
}

export("my.xdf) mydxf();

module myamf() {
material("PLA") {.....};
material("TEP") {.....};
}

export("my.amf") myamf();

Why does it need to be more complicated?

On 10 January 2016 at 17:23, Torsten Paul Torsten.Paul@gmx.de wrote:

On 01/10/2016 06:46 PM, nop head wrote:

In some respects, yes, that's true. But there's one thing that
does make it relevant. When using "normal" builtin modules to
define meta-data, we will capture all those names. Part of that
might be fixable if there's ever an implementation for namespaces,
but that's a bigger project in itself.
I've seen quite some cases where trying to unify everything into
the same logic resulted in problems.

Yes, color() is obviously existing as node already as there is
currently no other means. It certainly could be an annotation too.
I'm not really convinced that because we currently only have
hammers^H^H^H^H^H^H^Hnodes we need to shape every new problem
into nails^H^H^H^H^Hnodes if there are other options too.

Well, actually that's not totally true that we only have nodes.
In fact the ! # and % modifiers already behave like an annotation
for the module they are written before. This explains why this is
a parse error:

! { cube(); sphere(); }

And if we are talking about how hugely complicated things look
with annotations, let me, just for illustration purposes, use _
instead of that scary @ and reformat a bit

module part(r) {
_layer("layer1") rotate(r) something(10);
_layer("layer2") rotate(r) something(20);
}

_export(name = "part1") part1(0);
_export(name = "part2") part1(45);

Hmm, I really don't see how that's more complicated. Although
export is probably a bad name anyway. Something like Volume
would probably be ok, or even better something that applies
nicely to both 3D and 2D objects. (That's basically the HTML
discussion: Do logical instead of presentational description
and leave the interpretation to the processor/browser).

In essence, I think the only real difference between using a
module and something special whatever it's called is that it
introduces a different global namespace that does not collide
with the other existing ones and is not evaluated in the
script itself but in the renderer/exporter/external-tool.

ciao,
Torsten.

Well, interpretation of any language feature is always up to the tool,
which reads this language. E.g. if it's web app, it can open a frame/new
window/whatever with such exported view.

Hmm, may be it should be called view() instead of export()?
11 янв. 2016 г. 6:43 AM пользователь "Torsten Paul" Torsten.Paul@gmx.de
написал:

Mihail Vasiliev wrote

Wikpedia - AMF

"An AMF file can also specify the material and the color of each volume"
call it a volume()

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-tp15428p15645.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I agree with Nop Head that we can and should keep the syntax simple., The
namespace management issue that Torsten brought up is really orthogonal to
this discussion, and can be solved in a different way.

There are several different use cases being discussed. Multi-part models,
as described by Ezra, are really a different problem than multiple
materials. We've discussed multi-material semantics in a different thread,
and we want to extend the semantics of the CSG operators to behave sensibly
when the argument shapes consist of multiple materials. That issue doesn't
arise for multi-part models.

AMF is relevant to multi-part models. The AMF file format can separately
describe each component of a multi-part model. And slic3r has support for
reading and writing multi-part models, as single AMF files. Ezra describes
the situation where you try to print a multi-part model: some of the parts
print successfully, some of them fail. Then you want to reprint only those
components that failed. Slic3r supports this workflow using multi-part AMF
files (in Expert mode).

I think OpenSCAD should provide a simple, high level syntax for tagging the
different parts of a multi-part model. The details of how that is
represented in the file system should depend on what export option you are
using. There's one option to export a multi-part model as a collection of
STL files, and there's another option to export it as a single AMF file. (A
third option is to export the entire assembly as a single STL file.)
Instead of export("filename"), we could have component("partname"). This
way, the model stays abstract, and the details of which file format you are
exporting to are kept out of the model.

Doug.

On 10 January 2016 at 12:46, nop head nop.head@gmail.com wrote: