OpenSCAD

Node editing systems for 3D and drawing

Classic

List

Threaded

22 messages Options

boxcarmib

Re: Proposal for extensions to the OpenSCAD syntax

Here’s a very simplistic example of the kind of thing I’m talking about. I’ve created a library of a large number of building blocks of of objects… some are quite simple and others get quite complex… but let’s start with something simple like a tube:

// example A

module tubeA() {

difference() {

cylinder(d = 10, h = 25);

translate([0,0,-.01])

cylinder(d = 8, h = 25.1);

}

tubeA();

Now that’s okay, if I only want a tube, but if the tube is just a building block then I might easily want to combine it with a larger base...

module tube_standA() {

tubeA();

translate([0,0,5])

cube([20,20,10], center = true);

}

tube_standA();

The problem with that of course is that a straight union of my base with my tube is that it occludes the interior shaft of the tube… so I have to write extra code to bore out the base to accept the tube...

//////////

//example B

module tube_standB() {

difference() {

translate([0,0,5])

cube([20,20,10], center = true);

translate([0,0,-.01])

cylinder(d = 9.5, h = 25.1);

}

tubeA();

}

tube_standB();

//////////

This strikes me as inelegant, particularly if tube_standB is in and of itself a resusable part that I hope to use somewhere else in one or more of my designs. So at least the dot notation would allow me to create separate modules for union and differencing that would keep the tube definition “intact” and for me personally, make the flow and purpose of the code more straightforward.

// example C

module tubeC() {

module add() { // do the additive part of the geometry

cylinder(d = 10, h = 25);

}

module subtract() { // do the subtractive part of the geometry

translate([0,0,-.01])

cylinder(d = 8, h = 25.1);

}

difference() {

add();

subtract();

}

With the dot notation, then I can create a tube_stand routine that looks ‘cleaner’ to me

module tube_standC() {

difference() {

union() {

translate([0,0,5])

cube([20,20,10], center = true); // do the additive part of the stand

tube_standC.add(); // add it to the additive part of the tube

}

tube_standC.subtract(); // do the subtractive part of the tube which also subtracts it from the added base

}

Now as I say, this is a very simple example, and in my more complex routines I’m pretty sure the dot notation would go a long way to make the code more readable and understandable (to me at least).

I appreciate that my enthusiasm for the dot notation may just be a reflection of my own coding style and that I could be just a minority of one that would appreciate this extension to the syntax, and I guess it’s a little bit like the existing dot notation for array access. You can of course write:

value = myArray[1];

But if myArray is a point in 3D space I find it more helpful to use the existing dot notation and write:

value = myArray.y;

You mention, if I understand correctly that you tend to treat files as class containers and the modules within that file as the ‘methods’ of your file’s object. I tend to do that as well, but dot notation would aid in keeping module identifiers much shorter, e.g.

module myThingAddABitAtTheTopLeft() {}

module myThingSubtractABitInTheCenter() {}

module myThingMoveToTheFront() {}

As opposed to say:

module myThing() {

module add() {

module topLeft(){

}

module subtract() {

module atCenter();

}

module move() {

module front() {

}

And then calling:

myThing.add.topLeft();

myThing.move.front();

On Oct 28, 2019, at 11:11 AM, nop head <[hidden email]> wrote:

Why do you need to automatic select between drawing an object and making a hole for it? To me they are completely separate operations and I am quite happy to code two separate modules and call them from different places. E.g. I normally subtract the holes from a panel and then later on I add the object to the panel to make an assembly. If the panel is part of a 3D printed object then the hole subtraction is done in 3D but if it is a milled sheet then the the subtraction is done in 2D and extruded for the assembly view.

On Mon, 28 Oct 2019 at 18:05, Torsten Paul <[hidden email]> wrote:
On 28.10.19 09:51, nop head wrote:
> Why don't you simply define two modules foo_union()
> and foo_diff()?

That's of cause possible but means there's no way
to automatically select those.

> In conventional programming it is bonkers to have
> combine two completely different bits of code in one
> function and pass a global variable to decide which
> one is executed.

True, but if we can find a way to hide that extra
logic in a sensible way, that could make objects
easier to compose. People have asked for that all
the time.
The main question is probably if this kind of
relation can be expressed in a general, independent
from a specific design.

ciao,
Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

nophead

Re: Proposal for extensions to the OpenSCAD syntax

I never get that situation because all my objects are described by list of parameters. So I would just linear_extrude the difference between a square and a circle with tubes ID using a function to access that. If it was a more complicated inner shape I would expose it as a module.

You seem to be calling inner modules but what if they use parameters and local variables of the outer module? You haven't instantiated the module so they don't have any values.

In normal OO languages objects have instance variables and methods have both local variables and access to the instance variables. I use a list to hold my instance data.

There isn't really an equivalent with OpenSCAD modules. Are all the parameters and local variables, the instance variables of the object? It just doesn't make any sense to me.

On Mon, 28 Oct 2019 at 19:02, Hugo Jackson <[hidden email]> wrote:

Here’s a very simplistic example of the kind of thing I’m talking about. I’ve created a library of a large number of building blocks of of objects… some are quite simple and others get quite complex… but let’s start with something simple like a tube:

// example A

module tubeA() {
difference() {
cylinder(d = 10, h = 25);
translate([0,0,-.01])
cylinder(d = 8, h = 25.1);
}
}

tubeA();

Now that’s okay, if I only want a tube, but if the tube is just a building block then I might easily want to combine it with a larger base...

module tube_standA() {
tubeA();
translate([0,0,5])
cube([20,20,10], center = true);
}

tube_standA();

The problem with that of course is that a straight union of my base with my tube is that it occludes the interior shaft of the tube… so I have to write extra code to bore out the base to accept the tube...

//////////

//example B

module tube_standB() {
difference() {
translate([0,0,5])
cube([20,20,10], center = true);
translate([0,0,-.01])
cylinder(d = 9.5, h = 25.1);
}
tubeA();
}

tube_standB();

//////////

This strikes me as inelegant, particularly if tube_standB is in and of itself a resusable part that I hope to use somewhere else in one or more of my designs. So at least the dot notation would allow me to create separate modules for union and differencing that would keep the tube definition “intact” and for me personally, make the flow and purpose of the code more straightforward.

// example C

module tubeC() {

module add() { // do the additive part of the geometry
cylinder(d = 10, h = 25);
}

module subtract() { // do the subtractive part of the geometry
translate([0,0,-.01])
cylinder(d = 8, h = 25.1);
}

difference() {
add();
subtract();
}

}

With the dot notation, then I can create a tube_stand routine that looks ‘cleaner’ to me

module tube_standC() {
difference() {
union() {
translate([0,0,5])
cube([20,20,10], center = true); // do the additive part of the stand
tube_standC.add(); // add it to the additive part of the tube
}
tube_standC.subtract(); // do the subtractive part of the tube which also subtracts it from the added base
}
}

Now as I say, this is a very simple example, and in my more complex routines I’m pretty sure the dot notation would go a long way to make the code more readable and understandable (to me at least).

I appreciate that my enthusiasm for the dot notation may just be a reflection of my own coding style and that I could be just a minority of one that would appreciate this extension to the syntax, and I guess it’s a little bit like the existing dot notation for array access. You can of course write:

value = myArray[1];

But if myArray is a point in 3D space I find it more helpful to use the existing dot notation and write:

value = myArray.y;

You mention, if I understand correctly that you tend to treat files as class containers and the modules within that file as the ‘methods’ of your file’s object. I tend to do that as well, but dot notation would aid in keeping module identifiers much shorter, e.g.

module myThingAddABitAtTheTopLeft() {}
module myThingSubtractABitInTheCenter() {}
module myThingMoveToTheFront() {}

As opposed to say:

module myThing() {
module add() {
module topLeft(){
}
module subtract() {
module atCenter();
}
module move() {
module front() {
}
}
}

And then calling:

myThing.add.topLeft();

or

myThing.move.front();

On Oct 28, 2019, at 11:11 AM, nop head <[hidden email]> wrote:

Why do you need to automatic select between drawing an object and making a hole for it? To me they are completely separate operations and I am quite happy to code two separate modules and call them from different places. E.g. I normally subtract the holes from a panel and then later on I add the object to the panel to make an assembly. If the panel is part of a 3D printed object then the hole subtraction is done in 3D but if it is a milled sheet then the the subtraction is done in 2D and extruded for the assembly view.

On Mon, 28 Oct 2019 at 18:05, Torsten Paul <[hidden email]> wrote:
On 28.10.19 09:51, nop head wrote:
> Why don't you simply define two modules foo_union()
> and foo_diff()?

That's of cause possible but means there's no way
to automatically select those.

> In conventional programming it is bonkers to have
> combine two completely different bits of code in one
> function and pass a global variable to decide which
> one is executed.

True, but if we can find a way to hide that extra
logic in a sensible way, that could make objects
easier to compose. People have asked for that all
the time.
The main question is probably if this kind of
relation can be expressed in a general, independent
from a specific design.

ciao,
Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org