parameter mutual relations

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

parameter mutual relations

Felipe Sanches
In OpenSCAD we define contant values by evaluating expresions and
attributing to them the result of such expressions. Expressions can
naturally refer to the value of other contants that have been declared
previously.

Sometime I feel the need of a different approach. In my designs, I
must position objects in the scene by calculating their position
relative to the position of other objects. So I'd have one constant
for the height of one object and then a constant for the height of a
second object would be defined as the height of the first object plus
some offset value. Then a third object could have its height defined
by doing math with eighter the first object height or the second
object height (or both, of course).

Then when we need to change the position of an object, we must be
aware of the implication of such modification in the design. So, if I
change the firt object position, the second one will move accordingly.
But the opposite is not true. I can't change the second object and
expect the first one to move accordingly, keeping the same offset
distance. That would be cool, but that's not how openscad works.

I've been wondering about the possibility of OpenSCAD supporting some
alternative syntax for mutual mathematical relations between
constants. So that when you say something like A<=>B+x ("A value is x
greater than B value") you could simply say B=10; and it would result
in A=10+x while you could also say A=8; and as a result have B assume
the value of 8-x

I'd appreciate your thoughts on that.

Felipe Sanches
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: parameter mutual relations

Whosawhatsis
When I want to do something like this, I enclose both objects in a single translate() module, then further translate one or both to do the offset. If I want to move just one (relative to the other), I change the inner translate, and if I want to move them together, I modify the outer translate. You can also set a variable for the translation elsewhere, and include that term in two different translations, then change the variable if you want to move both.

Since there is no point-and-click manipulation, I see no reason you would need to add such an alternative way of controlling positioning, which would break the hierarchical structure of the language.

On Sunday, May 26, 2013 at 2:29 PM, Felipe Sanches wrote:

In OpenSCAD we define contant values by evaluating expresions and
attributing to them the result of such expressions. Expressions can
naturally refer to the value of other contants that have been declared
previously.

Sometime I feel the need of a different approach. In my designs, I
must position objects in the scene by calculating their position
relative to the position of other objects. So I'd have one constant
for the height of one object and then a constant for the height of a
second object would be defined as the height of the first object plus
some offset value. Then a third object could have its height defined
by doing math with eighter the first object height or the second
object height (or both, of course).

Then when we need to change the position of an object, we must be
aware of the implication of such modification in the design. So, if I
change the firt object position, the second one will move accordingly.
But the opposite is not true. I can't change the second object and
expect the first one to move accordingly, keeping the same offset
distance. That would be cool, but that's not how openscad works.

I've been wondering about the possibility of OpenSCAD supporting some
alternative syntax for mutual mathematical relations between
constants. So that when you say something like A<=>B+x ("A value is x
greater than B value") you could simply say B=10; and it would result
in A=10+x while you could also say A=8; and as a result have B assume
the value of 8-x

I'd appreciate your thoughts on that.

Felipe Sanches
_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: parameter mutual relations

Jesse Guardiani
In reply to this post by Felipe Sanches
I think you could write a library to do what you describe. It sounds interesting to me. It takes parametrized values a step further, making them algebraic limit equations.


On Sun, May 26, 2013 at 5:29 PM, Felipe Sanches <[hidden email]> wrote:
In OpenSCAD we define contant values by evaluating expresions and
attributing to them the result of such expressions. Expressions can
naturally refer to the value of other contants that have been declared
previously.

Sometime I feel the need of a different approach. In my designs, I
must position objects in the scene by calculating their position
relative to the position of other objects. So I'd have one constant
for the height of one object and then a constant for the height of a
second object would be defined as the height of the first object plus
some offset value. Then a third object could have its height defined
by doing math with eighter the first object height or the second
object height (or both, of course).

Then when we need to change the position of an object, we must be
aware of the implication of such modification in the design. So, if I
change the firt object position, the second one will move accordingly.
But the opposite is not true. I can't change the second object and
expect the first one to move accordingly, keeping the same offset
distance. That would be cool, but that's not how openscad works.

I've been wondering about the possibility of OpenSCAD supporting some
alternative syntax for mutual mathematical relations between
constants. So that when you say something like A<=>B+x ("A value is x
greater than B value") you could simply say B=10; and it would result
in A=10+x while you could also say A=8; and as a result have B assume
the value of 8-x

I'd appreciate your thoughts on that.

Felipe Sanches
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: parameter mutual relations

Felipe Sanches
In reply to this post by Whosawhatsis
On Sun, May 26, 2013 at 6:47 PM, whosawhatsis <[hidden email]> wrote:
> When I want to do something like this, I enclose both objects in a single
> translate() module, then further translate one or both to do the offset. If
> I want to move just one (relative to the other), I change the inner
> translate, and if I want to move them together, I modify the outer
> translate. You can also set a variable for the translation elsewhere, and
> include that term in two different translations, then change the variable if
> you want to move both.

Yes, I know we have ways to achieve the desired positioning result
without modifing the language. But certainly we can improve the
expressiveness of the language by having better positioning
constructs. By the way, this is not restricted to positioning issues.
It is actually a general problem about mutual mathematical relations
between constants that can be used for anything. Positioning is just
an easy/simple example. But these constants can be used for scaling of
objects, for dimensions of portions of an object, etc... It applies to
whatever the language constants can affect in the scene.

>
> Since there is no point-and-click manipulation, I see no reason you would
> need to add such an alternative way of controlling positioning, which would
> break the hierarchical structure of the language.

One does not need a point and click interface to benefit from a better
language construct that makes geometric ideas easier to describe.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: parameter mutual relations

Christopher Olah
I've researched possibilities in this direction extensively for
ImplicitCAD (implicitcad.org). This is basically logic programming for
programmatic CAD, which makes a lot of sense. The fact that
traditional CAD programs use geometric constraints, which is a weak
version of this, and they're super useful, is another indicator that
this is a promising direction.

If you only want to do affine equations, this is a pretty easy
problem. If you want to allow polynomials, it becomes Algebraic
Geometry (specifically Real Algebraic Geometry, which is much much
harder). You can solve these problems with Grobner Basis, but it's
asymptotic computational complexity is horribly nasty (worst case is
O(exp(exp(n)) where n is number of variables) and you don't get the
extension theorem in RAG, so if you're only interested in real
solutions and the solution space isn't finite, you're in a nasty
position.

I've got a good and fast solution working for a subset of this problem
using a combination of automated theorem proving techniques from
algebraic geometry and some numerical tricks for mech.ly (which is the
project I'm presently dedicated to) and may write a library for
ImplicitCAD as proof-of-concept.

Unless you're willing to do a ton of work, though, you should probably
use an existing computer algebra library, bind to that, and error when
it can't solve your problem.

Also, one big issue is that you usually don't have a single solution
to a problem like this, but a large class of solutions. Selecting one
in a programmatic CAD tool like OpenSCAD or ImplicitCAD is
problematic. Finding a solution to this is one of the things that made
me pivot into working on mech.ly.

Chris

On Sun, May 26, 2013 at 6:01 PM, Felipe Sanches <[hidden email]> wrote:

> On Sun, May 26, 2013 at 6:47 PM, whosawhatsis <[hidden email]> wrote:
>> When I want to do something like this, I enclose both objects in a single
>> translate() module, then further translate one or both to do the offset. If
>> I want to move just one (relative to the other), I change the inner
>> translate, and if I want to move them together, I modify the outer
>> translate. You can also set a variable for the translation elsewhere, and
>> include that term in two different translations, then change the variable if
>> you want to move both.
>
> Yes, I know we have ways to achieve the desired positioning result
> without modifing the language. But certainly we can improve the
> expressiveness of the language by having better positioning
> constructs. By the way, this is not restricted to positioning issues.
> It is actually a general problem about mutual mathematical relations
> between constants that can be used for anything. Positioning is just
> an easy/simple example. But these constants can be used for scaling of
> objects, for dimensions of portions of an object, etc... It applies to
> whatever the language constants can affect in the scene.
>
>>
>> Since there is no point-and-click manipulation, I see no reason you would
>> need to add such an alternative way of controlling positioning, which would
>> break the hierarchical structure of the language.
>
> One does not need a point and click interface to benefit from a better
> language construct that makes geometric ideas easier to describe.
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: parameter mutual relations

kintel
Administrator
On 2013-05-27, at 11:25 , Christopher Olah wrote:
>
> Also, one big issue is that you usually don't have a single solution
> to a problem like this, but a large class of solutions. Selecting one
> in a programmatic CAD tool like OpenSCAD or ImplicitCAD is
> problematic. Finding a solution to this is one of the things that made
> me pivot into working on mech.ly.
>
This sounds interesting!

What is mech.ly? The website is pretty cryptic.
Will this be proprietary software when it's finished, or is it Free Software developed in the hidden?

Cheers,

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: parameter mutual relations

Jesse Guardiani
Yeah, I couldn't glean any useful info from that picture either. I subscribed in the off chance it's useful, but from a marketing perspective, that page isn't collecting anything more than "people who are interested in strange CAD tools".


On Tue, May 28, 2013 at 9:19 PM, Marius Kintel <[hidden email]> wrote:
On 2013-05-27, at 11:25 , Christopher Olah wrote:
>
> Also, one big issue is that you usually don't have a single solution
> to a problem like this, but a large class of solutions. Selecting one
> in a programmatic CAD tool like OpenSCAD or ImplicitCAD is
> problematic. Finding a solution to this is one of the things that made
> me pivot into working on mech.ly.
>
This sounds interesting!

What is mech.ly? The website is pretty cryptic.
Will this be proprietary software when it's finished, or is it Free Software developed in the hidden?

Cheers,

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: parameter mutual relations

Christopher Olah
Hey Marius, Jesse,

Sorry, the mech.ly page is just a landing page we threw together in 10
minutes when we got the domain last week. I hadn't meant to link to
it. I guess there's some disadvantages of having the name of your
project be the domain! The picture is of an early prototype and
demonstrates our geometric constraint solver, running in a web
browser.

mehc.ly is Rob Gilson/D1plo1d (founder of MCAD) and my latest project.
It is in very early stages of development. We have some core technical
problems solved, but there's still a lot of work to be done before we
have something we want to publicize. For example, right now I'm
porting some of the really performance sensitive parts to hand crafted
ASM.js code in order to solve some performance issues.

We should have something public in a month or two.

We'd like for mech.ly to be open source, but we also want there to be
a business model that will allow us to fund extremely serious
full-time development of it. Our present plan is to be like github,
with the core project (for github, git, and for us, the CAD program)
being open source, but convenience infrastructure around it being
proprietary.

Honestly, we're mostly focused on technical stuff right now. There's a
huge amount to worry about there alone!

Chris

On Tue, May 28, 2013 at 9:42 PM, Jesse Guardiani <[hidden email]> wrote:

> Yeah, I couldn't glean any useful info from that picture either. I
> subscribed in the off chance it's useful, but from a marketing perspective,
> that page isn't collecting anything more than "people who are interested in
> strange CAD tools".
>
>
> On Tue, May 28, 2013 at 9:19 PM, Marius Kintel <[hidden email]> wrote:
>>
>> On 2013-05-27, at 11:25 , Christopher Olah wrote:
>> >
>> > Also, one big issue is that you usually don't have a single solution
>> > to a problem like this, but a large class of solutions. Selecting one
>> > in a programmatic CAD tool like OpenSCAD or ImplicitCAD is
>> > problematic. Finding a solution to this is one of the things that made
>> > me pivot into working on mech.ly.
>> >
>> This sounds interesting!
>>
>> What is mech.ly? The website is pretty cryptic.
>> Will this be proprietary software when it's finished, or is it Free
>> Software developed in the hidden?
>>
>> Cheers,
>>
>>  -Marius
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: parameter mutual relations

Peter Uithoven
Hi Chris,

Very interesting! Can't wait to see more. 
Two more questions. 
  • Is it 2D or 3D? 
  • I don't have a CAD background, but will this work a bit like FreeCAD's sketch mode in the Part Design workbench? 

Peter 


On Wed, May 29, 2013 at 7:32 PM, Christopher Olah <[hidden email]> wrote:
Hey Marius, Jesse,

Sorry, the mech.ly page is just a landing page we threw together in 10
minutes when we got the domain last week. I hadn't meant to link to
it. I guess there's some disadvantages of having the name of your
project be the domain! The picture is of an early prototype and
demonstrates our geometric constraint solver, running in a web
browser.

mehc.ly is Rob Gilson/D1plo1d (founder of MCAD) and my latest project.
It is in very early stages of development. We have some core technical
problems solved, but there's still a lot of work to be done before we
have something we want to publicize. For example, right now I'm
porting some of the really performance sensitive parts to hand crafted
ASM.js code in order to solve some performance issues.

We should have something public in a month or two.

We'd like for mech.ly to be open source, but we also want there to be
a business model that will allow us to fund extremely serious
full-time development of it. Our present plan is to be like github,
with the core project (for github, git, and for us, the CAD program)
being open source, but convenience infrastructure around it being
proprietary.

Honestly, we're mostly focused on technical stuff right now. There's a
huge amount to worry about there alone!

Chris

On Tue, May 28, 2013 at 9:42 PM, Jesse Guardiani <[hidden email]> wrote:
> Yeah, I couldn't glean any useful info from that picture either. I
> subscribed in the off chance it's useful, but from a marketing perspective,
> that page isn't collecting anything more than "people who are interested in
> strange CAD tools".
>
>
> On Tue, May 28, 2013 at 9:19 PM, Marius Kintel <[hidden email]> wrote:
>>
>> On 2013-05-27, at 11:25 , Christopher Olah wrote:
>> >
>> > Also, one big issue is that you usually don't have a single solution
>> > to a problem like this, but a large class of solutions. Selecting one
>> > in a programmatic CAD tool like OpenSCAD or ImplicitCAD is
>> > problematic. Finding a solution to this is one of the things that made
>> > me pivot into working on mech.ly.
>> >
>> This sounds interesting!
>>
>> What is mech.ly? The website is pretty cryptic.
>> Will this be proprietary software when it's finished, or is it Free
>> Software developed in the hidden?
>>
>> Cheers,
>>
>>  -Marius
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566