Empathy List Archives

MK

Marius Kintel

Thu, Jan 14, 2016 4:55 AM

Hi all,

I’m a bit late to the discussion, but I’d like to make some observations and suggestions based on the contributions so far:

Syntax aside, it sounds to me like the red thread in this discussion is the ability to “tag” nodes or sub-trees in an OpenSCAD design with certain information, which can later be used to perform operations after we’ve successfully built what we usually call a CSG tree (a tree of CSG operators on concrete geometries).

Operations discussed here include: Various forms of rendering (incl. color/material selection and rendering modifiers), export to various file formats, text output/echo for BOM purposes, annotations for export purposes (incl. layer specification), select/ignore modifiers, persistent caching.

What if we implemented general purpose annotation functionality for attaching a name=value dictionary (or smth. similar) to any OpenSCAD CSG tree node? Various built-in functions (as mentioned above) could then use these annotations while traversing the tree, by querying pre-defined annotations.
By making it general purpose, we could theoretically, at a later stage, add some sort of API to query these annotations to allow other software (or plugins) to extend the functionality of OpenSCAD.

To implement this within the current syntax, we could (as suggested earlier) implement modules serving only tagging purposes.
One example would be (to use an example from the previous email from Doug): component(“name”) someSubTree();
This has the benefit of keeping the user-facing syntax simple.
A more general approach could be annotation(component=“name”) someSubTree();
The 'component(“name”)’ syntax could simply be a shortcut for the full annotation syntax. OpenSCAD2 would also allow us to attach any plain old data structure to a node, or even programmatically define annotations.

For this to be successful, we should not create group nodes for such annotations, but accumulate them into a dict attached to the child node.
One interesting note: If we do this properly, we could probably rewrite both color() and the 4 modifier characters to the new annotation scheme.

There might be namespace clashes. One earlier suggestion (by Torsten I believe) was to use a special character “@“ for annotation shortcuts.
Torsten also pointed out that this could be generalized further into annotating module definitions for customization, documentation and auto-complete purposes.

ok, this was a bit longer than anticipated.
I also apologize in advance for being late for the next discussion. Too many emails…

-Marius

Hi all, I’m a bit late to the discussion, but I’d like to make some observations and suggestions based on the contributions so far: Syntax aside, it sounds to me like the red thread in this discussion is the ability to “tag” nodes or sub-trees in an OpenSCAD design with certain information, which can later be used to perform operations _after_ we’ve successfully built what we usually call a CSG tree (a tree of CSG operators on concrete geometries). Operations discussed here include: Various forms of rendering (incl. color/material selection and rendering modifiers), export to various file formats, text output/echo for BOM purposes, annotations for export purposes (incl. layer specification), select/ignore modifiers, persistent caching. What if we implemented general purpose annotation functionality for attaching a name=value dictionary (or smth. similar) to any OpenSCAD CSG tree node? Various built-in functions (as mentioned above) could then use these annotations while traversing the tree, by querying pre-defined annotations. By making it general purpose, we could theoretically, at a later stage, add some sort of API to query these annotations to allow other software (or plugins) to extend the functionality of OpenSCAD. To implement this within the current syntax, we could (as suggested earlier) implement modules serving only tagging purposes. One example would be (to use an example from the previous email from Doug): component(“name”) someSubTree(); This has the benefit of keeping the user-facing syntax simple. A more general approach could be annotation(component=“name”) someSubTree(); The 'component(“name”)’ syntax could simply be a shortcut for the full annotation syntax. OpenSCAD2 would also allow us to attach any plain old data structure to a node, or even programmatically define annotations. For this to be successful, we should not create group nodes for such annotations, but accumulate them into a dict attached to the child node. One interesting note: If we do this properly, we could probably rewrite both color() and the 4 modifier characters to the new annotation scheme. There might be namespace clashes. One earlier suggestion (by Torsten I believe) was to use a special character “@“ for annotation shortcuts. Torsten also pointed out that this could be generalized further into annotating module definitions for customization, documentation and auto-complete purposes. ok, this was a bit longer than anticipated. I also apologize in advance for being late for the next discussion. Too many emails… -Marius

NH

nop head

Thu, Jan 14, 2016 8:36 AM

Annotations would be nice but the problem is I don't want to export the
model I see in F5. In that model my printed parts are not oriented for
printing and may not have additional support structures added. This is why
I want an export function that doesn't render its children during F5 and
F6. During the export operation invoked from a menu I only want the
children of export statements rendered, not my main model, which is an
assembly view. So it's a bit more than just annotation.

Currently I achieve exactly what I want with echo and Python but other
people what to have it native to OpenScad.

On 14 January 2016 at 04:55, Marius Kintel marius@kintel.net wrote:

Hi all,

I’m a bit late to the discussion, but I’d like to make some observations
and suggestions based on the contributions so far:

Syntax aside, it sounds to me like the red thread in this discussion is
the ability to “tag” nodes or sub-trees in an OpenSCAD design with certain
information, which can later be used to perform operations after we’ve
successfully built what we usually call a CSG tree (a tree of CSG operators
on concrete geometries).

Operations discussed here include: Various forms of rendering (incl.
color/material selection and rendering modifiers), export to various file
formats, text output/echo for BOM purposes, annotations for export purposes
(incl. layer specification), select/ignore modifiers, persistent caching.

What if we implemented general purpose annotation functionality for
attaching a name=value dictionary (or smth. similar) to any OpenSCAD CSG
tree node? Various built-in functions (as mentioned above) could then use
these annotations while traversing the tree, by querying pre-defined
annotations.
By making it general purpose, we could theoretically, at a later stage,
add some sort of API to query these annotations to allow other software (or
plugins) to extend the functionality of OpenSCAD.

To implement this within the current syntax, we could (as suggested
earlier) implement modules serving only tagging purposes.
One example would be (to use an example from the previous email from
Doug): component(“name”) someSubTree();
This has the benefit of keeping the user-facing syntax simple.
A more general approach could be annotation(component=“name”)
someSubTree();
The 'component(“name”)’ syntax could simply be a shortcut for the full
annotation syntax. OpenSCAD2 would also allow us to attach any plain old
data structure to a node, or even programmatically define annotations.

For this to be successful, we should not create group nodes for such
annotations, but accumulate them into a dict attached to the child node.
One interesting note: If we do this properly, we could probably rewrite
both color() and the 4 modifier characters to the new annotation scheme.

There might be namespace clashes. One earlier suggestion (by Torsten I
believe) was to use a special character “@“ for annotation shortcuts.
Torsten also pointed out that this could be generalized further into
annotating module definitions for customization, documentation and
auto-complete purposes.

ok, this was a bit longer than anticipated.
I also apologize in advance for being late for the next discussion. Too
many emails…

-Marius

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Annotations would be nice but the problem is I don't want to export the model I see in F5. In that model my printed parts are not oriented for printing and may not have additional support structures added. This is why I want an export function that doesn't render its children during F5 and F6. During the export operation invoked from a menu I only want the children of export statements rendered, not my main model, which is an assembly view. So it's a bit more than just annotation. Currently I achieve exactly what I want with echo and Python but other people what to have it native to OpenScad. On 14 January 2016 at 04:55, Marius Kintel <marius@kintel.net> wrote: > Hi all, > > I’m a bit late to the discussion, but I’d like to make some observations > and suggestions based on the contributions so far: > > Syntax aside, it sounds to me like the red thread in this discussion is > the ability to “tag” nodes or sub-trees in an OpenSCAD design with certain > information, which can later be used to perform operations _after_ we’ve > successfully built what we usually call a CSG tree (a tree of CSG operators > on concrete geometries). > > Operations discussed here include: Various forms of rendering (incl. > color/material selection and rendering modifiers), export to various file > formats, text output/echo for BOM purposes, annotations for export purposes > (incl. layer specification), select/ignore modifiers, persistent caching. > > What if we implemented general purpose annotation functionality for > attaching a name=value dictionary (or smth. similar) to any OpenSCAD CSG > tree node? Various built-in functions (as mentioned above) could then use > these annotations while traversing the tree, by querying pre-defined > annotations. > By making it general purpose, we could theoretically, at a later stage, > add some sort of API to query these annotations to allow other software (or > plugins) to extend the functionality of OpenSCAD. > > To implement this within the current syntax, we could (as suggested > earlier) implement modules serving only tagging purposes. > One example would be (to use an example from the previous email from > Doug): component(“name”) someSubTree(); > This has the benefit of keeping the user-facing syntax simple. > A more general approach could be annotation(component=“name”) > someSubTree(); > The 'component(“name”)’ syntax could simply be a shortcut for the full > annotation syntax. OpenSCAD2 would also allow us to attach any plain old > data structure to a node, or even programmatically define annotations. > > For this to be successful, we should not create group nodes for such > annotations, but accumulate them into a dict attached to the child node. > One interesting note: If we do this properly, we could probably rewrite > both color() and the 4 modifier characters to the new annotation scheme. > > There might be namespace clashes. One earlier suggestion (by Torsten I > believe) was to use a special character “@“ for annotation shortcuts. > Torsten also pointed out that this could be generalized further into > annotating module definitions for customization, documentation and > auto-complete purposes. > > ok, this was a bit longer than anticipated. > I also apologize in advance for being late for the next discussion. Too > many emails… > > -Marius > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

MV

Mihail Vasiliev

Thu, Jan 14, 2016 9:05 AM

From my point of view, it's just an orthogonal ideas - annotation of

logical parts of actual model and defining viewports for their presentation
to user. If I model a house and annotate it's part as a "roof", I want to
be able to define a views "3D from the front", "3D oxonometric", "2D cut
through rooftop". And see the annotated parts labeled by their annotations.

And it's Ok to have several windows as representations of these views on
F5/F6, and have them in files on (something else, say, F7, not sure if it
is used already). Although, if someone needs, say, 100 cuts in 2D, these
cuts should have an option to disable GUI preview case. For more general
approach option to disable exporting in file for a view should also be
implemented.

2016-01-14 11:36 GMT+03:00 nop head nop.head@gmail.com: