procedurally generating polyhedra and non-uniform scaling

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

procedurally generating polyhedra and non-uniform scaling

Whosawhatsis
I'm trying to generate some more organic shapes, and I've thought of two ways that I should be able to do it, neither of which seems to be possible.

The first one I thought of was a non-uniform scaling module. What I'm thinking of is something that could take a child element and stretch it unevenly. This could, for instance, take a cylinder and turn it into a cone or section of a cone, or a cylinder with its ends not parallel to its sides. I know all of these examples are possible with booleans and/or with the use of r1 and r2, but what I'm trying to do requires applying these procedures with shapes more complicated than a simple cylinder. This could take the form of a scale function that accepts multiple vectors, each representing a point about which to perform translation, and these point would form a gradient of transformation that would be applied to the points between and beyond them. The multimatrix module may make some of this possible, but I couldn't figure out how to get it to do anything that couldn't be done by combining the other transformation functions.

I would settle for a method of addressing and applying transformations to a subset of the points that make up a polyhedron, which would make it possible for me to implement this myself. This could take the form of a selection function, defining a cube or a cylinder or other polyhedron and returning the points located within it (or simply allowing them to be transformed independently of the unselected points in the same polyhedron).

The other option I thought of was procedurally generated polyhedra. This would require the ability to define points and facets using iterators, conditionals and subroutines (I found a brief reference to someone else wanting this in the archives from a couple of months ago). This would most likely require changing the method of defining a polyhedron so that points and facets would be child elements, rather than arguments.

It would also be useful to be able to build an object and assign it to a variable, rather than building directly to the rendering space. This could be used, for instance, to create a module that renders multiple copies of its children in a loop.

If any of this is possible now, and I just haven't figured it out, I would appreciate it if anyone could point me in the right direction. I know this is starting to sound like I should be using a mesh editor, but I need the mathematical precision and procedural generation that OpenSCAD makes possible.
Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

Owen Taylor
On Thu, Aug 26, 2010 at 4:18 PM, Whosawhatsis <[hidden email]> wrote:

> The other option I thought of was procedurally generated polyhedra. This would require the ability to define points and facets using iterators, conditionals and subroutines (I found a brief reference to someone else wanting this in the archives from a couple of months ago). This would most likely require changing the method of defining a polyhedron so that points and facets would be child elements, rather than arguments.

I have a pretty small patch I've been working on that provides
something that's both better than this and way worse - the way it
works is that:

 script(file="myscript.py", arg1=42, arg2=27);

Runs an external program myscript.py as:

 myscript.py arg1=42 arg2=27 $fs=12 $fa=1 $fn=0

And then captures the output of myscript.py and interprets it as a
OpenSCAD script. So, to create procedurally generated polyhedron, you
just write a python script (or a script in any other language. Or a C
program. Or whatever...) that parses the arguments and outputs a
'polyehedron() { ... }' statement. With a bit of standard glue code in
a Python module and using numpy for vector/matrix math it's pretty
nice to use and really extends what you can easily do.

I'm not completely happy with the interface yet - it seems like I
always want to wrap the above as:

 module myscript(arg1, arg2) {
    script(file="myscript.py", arg1=arg1, arg2=arg2);
 }

So, maybe it would be better as:

 external_module myscript(file="myscript.py");

Or something like that. I'll see if I can post my current patch later
this evening in case anybody is interested.

- Owen

Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

Whosawhatsis
Yeah, I suppose for the time being, an external script to generate the SCAD file is the best way to accomplish what I'm trying to do.

On Aug 26, 2010, at 2:40 PM, Owen Taylor wrote:

> On Thu, Aug 26, 2010 at 4:18 PM, Whosawhatsis <[hidden email]> wrote:
>
>> The other option I thought of was procedurally generated polyhedra. This would require the ability to define points and facets using iterators, conditionals and subroutines (I found a brief reference to someone else wanting this in the archives from a couple of months ago). This would most likely require changing the method of defining a polyhedron so that points and facets would be child elements, rather than arguments.
>
> I have a pretty small patch I've been working on that provides
> something that's both better than this and way worse - the way it
> works is that:
>
> script(file="myscript.py", arg1=42, arg2=27);
>
> Runs an external program myscript.py as:
>
> myscript.py arg1=42 arg2=27 $fs=12 $fa=1 $fn=0
>
> And then captures the output of myscript.py and interprets it as a
> OpenSCAD script. So, to create procedurally generated polyhedron, you
> just write a python script (or a script in any other language. Or a C
> program. Or whatever...) that parses the arguments and outputs a
> 'polyehedron() { ... }' statement. With a bit of standard glue code in
> a Python module and using numpy for vector/matrix math it's pretty
> nice to use and really extends what you can easily do.
>
> I'm not completely happy with the interface yet - it seems like I
> always want to wrap the above as:
>
> module myscript(arg1, arg2) {
>    script(file="myscript.py", arg1=arg1, arg2=arg2);
> }
>
> So, maybe it would be better as:
>
> external_module myscript(file="myscript.py");
>
> Or something like that. I'll see if I can post my current patch later
> this evening in case anybody is interested.
>
> - Owen
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

Owen Taylor
My experience is that being able to invoke a script from within my
openSCAD file and pass in parameters is prettty different from writing
python programs to generate SCAD files and then including them
normally - instead of constantly switching back and forth between
Python and SCAD, and trying to keep everything in sync, once I had
done the upfront work I just had a "screw thread" or "icosahedron"
primitive that I could use.

Of course, if you don't already have a language or two in your pocket,
it's pretty unfriendly compared to having built-in facilities in
OpenSCAD!

- Owen

On Thu, Aug 26, 2010 at 5:47 PM, Whosawhatsis <[hidden email]> wrote:

> Yeah, I suppose for the time being, an external script to generate the SCAD file is the best way to accomplish what I'm trying to do.
>
> On Aug 26, 2010, at 2:40 PM, Owen Taylor wrote:
>
>> On Thu, Aug 26, 2010 at 4:18 PM, Whosawhatsis <[hidden email]> wrote:
>>
>>> The other option I thought of was procedurally generated polyhedra. This would require the ability to define points and facets using iterators, conditionals and subroutines (I found a brief reference to someone else wanting this in the archives from a couple of months ago). This would most likely require changing the method of defining a polyhedron so that points and facets would be child elements, rather than arguments.
>>
>> I have a pretty small patch I've been working on that provides
>> something that's both better than this and way worse - the way it
>> works is that:
>>
>> script(file="myscript.py", arg1=42, arg2=27);
>>
>> Runs an external program myscript.py as:
>>
>> myscript.py arg1=42 arg2=27 $fs=12 $fa=1 $fn=0
>>
>> And then captures the output of myscript.py and interprets it as a
>> OpenSCAD script. So, to create procedurally generated polyhedron, you
>> just write a python script (or a script in any other language. Or a C
>> program. Or whatever...) that parses the arguments and outputs a
>> 'polyehedron() { ... }' statement. With a bit of standard glue code in
>> a Python module and using numpy for vector/matrix math it's pretty
>> nice to use and really extends what you can easily do.
>>
>> I'm not completely happy with the interface yet - it seems like I
>> always want to wrap the above as:
>>
>> module myscript(arg1, arg2) {
>>    script(file="myscript.py", arg1=arg1, arg2=arg2);
>> }
>>
>> So, maybe it would be better as:
>>
>> external_module myscript(file="myscript.py");
>>
>> Or something like that. I'll see if I can post my current patch later
>> this evening in case anybody is interested.
>>
>> - Owen
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

Whosawhatsis
Why did you need a script for a screw thread? I made a beautiful one using linear_extrude using the twist parameter.

On Aug 26, 2010, at 2:56 PM, Owen Taylor wrote:

> My experience is that being able to invoke a script from within my
> openSCAD file and pass in parameters is prettty different from writing
> python programs to generate SCAD files and then including them
> normally - instead of constantly switching back and forth between
> Python and SCAD, and trying to keep everything in sync, once I had
> done the upfront work I just had a "screw thread" or "icosahedron"
> primitive that I could use.
>
> Of course, if you don't already have a language or two in your pocket,
> it's pretty unfriendly compared to having built-in facilities in
> OpenSCAD!
>
> - Owen
>
> On Thu, Aug 26, 2010 at 5:47 PM, Whosawhatsis <[hidden email]> wrote:
>> Yeah, I suppose for the time being, an external script to generate the SCAD file is the best way to accomplish what I'm trying to do.
>>
>> On Aug 26, 2010, at 2:40 PM, Owen Taylor wrote:
>>
>>> On Thu, Aug 26, 2010 at 4:18 PM, Whosawhatsis <[hidden email]> wrote:
>>>
>>>> The other option I thought of was procedurally generated polyhedra. This would require the ability to define points and facets using iterators, conditionals and subroutines (I found a brief reference to someone else wanting this in the archives from a couple of months ago). This would most likely require changing the method of defining a polyhedron so that points and facets would be child elements, rather than arguments.
>>>
>>> I have a pretty small patch I've been working on that provides
>>> something that's both better than this and way worse - the way it
>>> works is that:
>>>
>>> script(file="myscript.py", arg1=42, arg2=27);
>>>
>>> Runs an external program myscript.py as:
>>>
>>> myscript.py arg1=42 arg2=27 $fs=12 $fa=1 $fn=0
>>>
>>> And then captures the output of myscript.py and interprets it as a
>>> OpenSCAD script. So, to create procedurally generated polyhedron, you
>>> just write a python script (or a script in any other language. Or a C
>>> program. Or whatever...) that parses the arguments and outputs a
>>> 'polyehedron() { ... }' statement. With a bit of standard glue code in
>>> a Python module and using numpy for vector/matrix math it's pretty
>>> nice to use and really extends what you can easily do.
>>>
>>> I'm not completely happy with the interface yet - it seems like I
>>> always want to wrap the above as:
>>>
>>> module myscript(arg1, arg2) {
>>>    script(file="myscript.py", arg1=arg1, arg2=arg2);
>>> }
>>>
>>> So, maybe it would be better as:
>>>
>>> external_module myscript(file="myscript.py");
>>>
>>> Or something like that. I'll see if I can post my current patch later
>>> this evening in case anybody is interested.
>>>
>>> - Owen
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> [hidden email]
>>> http://rocklinux.net/mailman/listinfo/openscad
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

Owen Taylor
Since a screw thread has that symmetry, yes, it's possible to create
screw threads with linear_extrude and twist. Every slice through the
screw will look the same. (I'm not sure what exactly the manual means
by "Unfortunately, it can not be used to produce a helix for screw
threads as the 2D outline must be normal to the axis of rotation.")

But then you have to figure out what the slice looks like to extrude
to get a desired result. Not too hard if you want to get something
that is vaguely screwlike. But say you wanted to make a model of a
#6-32 screw? Or maybe you just wanted to make a screw that looks like
a normal screw with the 60 degree angle between the faces and cut off
on the inside and outside. That's very hard for me to think about, and
harder if I want to get exact parameters. And harder still if I want
to change the parameters on the fly as I adjust the model.

It was much easier for me to write code to generate a polyhedron
directly from the standard parameters that define a screw by rotating
a vertical outer profile around the central axis. I guess that's
probably what the manual means :-)

- Owen

On Thu, Aug 26, 2010 at 6:00 PM, Whosawhatsis <[hidden email]> wrote:

> Why did you need a script for a screw thread? I made a beautiful one using linear_extrude using the twist parameter.
>
> On Aug 26, 2010, at 2:56 PM, Owen Taylor wrote:
>
>> My experience is that being able to invoke a script from within my
>> openSCAD file and pass in parameters is prettty different from writing
>> python programs to generate SCAD files and then including them
>> normally - instead of constantly switching back and forth between
>> Python and SCAD, and trying to keep everything in sync, once I had
>> done the upfront work I just had a "screw thread" or "icosahedron"
>> primitive that I could use.
>>
>> Of course, if you don't already have a language or two in your pocket,
>> it's pretty unfriendly compared to having built-in facilities in
>> OpenSCAD!
>>
>> - Owen
>>
>> On Thu, Aug 26, 2010 at 5:47 PM, Whosawhatsis <[hidden email]> wrote:
>>> Yeah, I suppose for the time being, an external script to generate the SCAD file is the best way to accomplish what I'm trying to do.
>>>
>>> On Aug 26, 2010, at 2:40 PM, Owen Taylor wrote:
>>>
>>>> On Thu, Aug 26, 2010 at 4:18 PM, Whosawhatsis <[hidden email]> wrote:
>>>>
>>>>> The other option I thought of was procedurally generated polyhedra. This would require the ability to define points and facets using iterators, conditionals and subroutines (I found a brief reference to someone else wanting this in the archives from a couple of months ago). This would most likely require changing the method of defining a polyhedron so that points and facets would be child elements, rather than arguments.
>>>>
>>>> I have a pretty small patch I've been working on that provides
>>>> something that's both better than this and way worse - the way it
>>>> works is that:
>>>>
>>>> script(file="myscript.py", arg1=42, arg2=27);
>>>>
>>>> Runs an external program myscript.py as:
>>>>
>>>> myscript.py arg1=42 arg2=27 $fs=12 $fa=1 $fn=0
>>>>
>>>> And then captures the output of myscript.py and interprets it as a
>>>> OpenSCAD script. So, to create procedurally generated polyhedron, you
>>>> just write a python script (or a script in any other language. Or a C
>>>> program. Or whatever...) that parses the arguments and outputs a
>>>> 'polyehedron() { ... }' statement. With a bit of standard glue code in
>>>> a Python module and using numpy for vector/matrix math it's pretty
>>>> nice to use and really extends what you can easily do.
>>>>
>>>> I'm not completely happy with the interface yet - it seems like I
>>>> always want to wrap the above as:
>>>>
>>>> module myscript(arg1, arg2) {
>>>>    script(file="myscript.py", arg1=arg1, arg2=arg2);
>>>> }
>>>>
>>>> So, maybe it would be better as:
>>>>
>>>> external_module myscript(file="myscript.py");
>>>>
>>>> Or something like that. I'll see if I can post my current patch later
>>>> this evening in case anybody is interested.
>>>>
>>>> - Owen
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> [hidden email]
>>>> http://rocklinux.net/mailman/listinfo/openscad
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> [hidden email]
>>> http://rocklinux.net/mailman/listinfo/openscad
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

Owen Taylor
On Thu, Aug 26, 2010 at 6:31 PM, Owen Taylor <[hidden email]> wrote:
> But then you have to figure out what the slice looks like to extrude
> to get a desired result. Not too hard if you want to get something
> that is vaguely screwlike. But say you wanted to make a model of a
> #6-32 screw? Or maybe you just wanted to make a screw that looks like
> a normal screw with the 60 degree angle between the faces and cut off
> on the inside and outside. That's very hard for me to think about, and
> harder if I want to get exact parameters. And harder still if I want
> to change the parameters on the fly as I adjust the model.

As I was driving home, I realized there is nothing very mysterious
about the shape of the slice. It's just a polar plot of the vertical
profile. But even if it's easy to compute, I'd still want to do it in
code, rather than drawing a DXF file by hand.

- Owen

(Sorry for the noise)

Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

Whosawhatsis
In reply to this post by Whosawhatsis
Another feature that might be useful for building shapes that cannot be made using booleans and primitives would be a morph extrusion. What I'm thinking of is an extrusion function that extrudes the first child using the second as a morph target (and it could continue to morph the second into the third, and so on). For example, you could have a square at the origin and a circle above it, and the function would connect the points on the square to the points on the circle, making a rectangle (two triangles) connecting each side of the square to the nearest facet of the circle, then filling in the empty spaces with triangles from the unused facets to the appropriate corner of the square until a manifold solid is created.

On Aug 26, 2010, at 1:18 PM, Whosawhatsis wrote:

> I'm trying to generate some more organic shapes, and I've thought of two ways that I should be able to do it, neither of which seems to be possible.
>
> The first one I thought of was a non-uniform scaling module. What I'm thinking of is something that could take a child element and stretch it unevenly. This could, for instance, take a cylinder and turn it into a cone or section of a cone, or a cylinder with its ends not parallel to its sides. I know all of these examples are possible with booleans and/or with the use of r1 and r2, but what I'm trying to do requires applying these procedures with shapes more complicated than a simple cylinder. This could take the form of a scale function that accepts multiple vectors, each representing a point about which to perform translation, and these point would form a gradient of transformation that would be applied to the points between and beyond them. The multimatrix module may make some of this possible, but I couldn't figure out how to get it to do anything that couldn't be done by combining the other transformation functions.
>
> I would settle for a method of addressing and applying transformations to a subset of the points that make up a polyhedron, which would make it possible for me to implement this myself. This could take the form of a selection function, defining a cube or a cylinder or other polyhedron and returning the points located within it (or simply allowing them to be transformed independently of the unselected points in the same polyhedron).
>
> The other option I thought of was procedurally generated polyhedra. This would require the ability to define points and facets using iterators, conditionals and subroutines (I found a brief reference to someone else wanting this in the archives from a couple of months ago). This would most likely require changing the method of defining a polyhedron so that points and facets would be child elements, rather than arguments.
>
> It would also be useful to be able to build an object and assign it to a variable, rather than building directly to the rendering space. This could be used, for instance, to create a module that renders multiple copies of its children in a loop.
>
> If any of this is possible now, and I just haven't figured it out, I would appreciate it if anyone could point me in the right direction. I know this is starting to sound like I should be using a mesh editor, but I need the mathematical precision and procedural generation that OpenSCAD makes possible.


Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

M.Rule
youd have to define some method of interpolation between corrections.
this is arbitrary.

On Fri, Aug 27, 2010 at 8:56 AM, Whosawhatsis <[hidden email]> wrote:

> Another feature that might be useful for building shapes that cannot be made using booleans and primitives would be a morph extrusion. What I'm thinking of is an extrusion function that extrudes the first child using the second as a morph target (and it could continue to morph the second into the third, and so on). For example, you could have a square at the origin and a circle above it, and the function would connect the points on the square to the points on the circle, making a rectangle (two triangles) connecting each side of the square to the nearest facet of the circle, then filling in the empty spaces with triangles from the unused facets to the appropriate corner of the square until a manifold solid is created.
>
> On Aug 26, 2010, at 1:18 PM, Whosawhatsis wrote:
>
>> I'm trying to generate some more organic shapes, and I've thought of two ways that I should be able to do it, neither of which seems to be possible.
>>
>> The first one I thought of was a non-uniform scaling module. What I'm thinking of is something that could take a child element and stretch it unevenly. This could, for instance, take a cylinder and turn it into a cone or section of a cone, or a cylinder with its ends not parallel to its sides. I know all of these examples are possible with booleans and/or with the use of r1 and r2, but what I'm trying to do requires applying these procedures with shapes more complicated than a simple cylinder. This could take the form of a scale function that accepts multiple vectors, each representing a point about which to perform translation, and these point would form a gradient of transformation that would be applied to the points between and beyond them. The multimatrix module may make some of this possible, but I couldn't figure out how to get it to do anything that couldn't be done by combining the other transformation functions.
>>
>> I would settle for a method of addressing and applying transformations to a subset of the points that make up a polyhedron, which would make it possible for me to implement this myself. This could take the form of a selection function, defining a cube or a cylinder or other polyhedron and returning the points located within it (or simply allowing them to be transformed independently of the unselected points in the same polyhedron).
>>
>> The other option I thought of was procedurally generated polyhedra. This would require the ability to define points and facets using iterators, conditionals and subroutines (I found a brief reference to someone else wanting this in the archives from a couple of months ago). This would most likely require changing the method of defining a polyhedron so that points and facets would be child elements, rather than arguments.
>>
>> It would also be useful to be able to build an object and assign it to a variable, rather than building directly to the rendering space. This could be used, for instance, to create a module that renders multiple copies of its children in a loop.
>>
>> If any of this is possible now, and I just haven't figured it out, I would appreciate it if anyone could point me in the right direction. I know this is starting to sound like I should be using a mesh editor, but I need the mathematical precision and procedural generation that OpenSCAD makes possible.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|

Re: procedurally generating polyhedra and non-uniform scaling

Steven Dick
In reply to this post by Whosawhatsis


On Fri, Aug 27, 2010 at 8:56 AM, Whosawhatsis <[hidden email]> wrote:
Another feature that might be useful for building shapes that cannot be made using booleans and primitives would be a morph extrusion.


Some commercial cad programs call this a variational sweep.

This, along with 2d splines and surface splines would go a long way towards making OpenSCAD capable of doing some of the things commercial cad programs can do.