How to find the current x, y, z location
I still want to know what the original poster was actually trying to do with
a specific code example. I think without that it's difficult to really say
what the best solution is.
Why, if you have a series of transformations, would you not just put
whatever second thing you need inside that same code. What is the reason
for wanting to do something later inside a series of transformations you did
before? That is the obvious question I have.
--
Sent from: http://forum.openscad.org/
On 3/2/2019 7:49 AM, jamcultur wrote:
OpenSCAD obviously knows the current [x, y, z]
[ Speaking from an external observer's point of view, without knowledge
of the internals... others, feel free to correct me.]
First, note that "current position" isn't the complete picture - there's
also rotation, scale, and skew.
I don't think it does know the current position..
It doesn't execute a program in a conventional sense, producing geometry
as a direct result of the execution.
Rather, it executes a program[*] that produces a tree of
transformations, operations, and objects, and a subsequent step applies
those transformations and operations to those objects to produce the
final absolute geometry.
Turn on Design/"Display CSG Tree" to see the results of the execution.
Note that the generated geometry still has each of the transformation
steps; there are no absolute coordinates.
[*] Even that isn't quite right. Note that there are almost no
unbounded loops and there are no conventional variables. In a lot
of ways it's more like a macro processor than a language
interpreter. Everything is done at "compile" time and there is no
"run time".
Even if it was a conventional language that directly generated the final
geometry, I don't know if it always would know the current
transformation relative to the absolute coordinate system.
The most straightforward way to do it would be to have a transformation
function call its children and then apply its transformation to them,
returning a transformed object. In such a design, each function would
have no idea what coordinate system it was embedded in; you would only
know absolute coordinates when you get back to the top of the call stack.
It might be equivalent to "left associate" the transformations,
building up a "current transformation", applying that to the primitive
objects, and then doing all of the boolean operations in the absolute
coordinate system. I don't think that can work for operations like
offset, projection, and extrusion, but maybe I just haven't warped my
brain enough.
Yes indeed. I never need to do this. To put the object at the origin I
simply don't put it under some transformations. If I want to transform
other objects to the same place I create a module that transforms its
children and apply it wherever wanted.
I don't need to ask where something is because I have placed it relative to
other objects in the design and then my machines make it. I sometimes add
echos of sizes that hare calculated to make sure they will fit on my
printers.
On Sun, 3 Mar 2019 at 21:03, adrianv avm4@cornell.edu wrote:
I still want to know what the original poster was actually trying to do
with
a specific code example. I think without that it's difficult to really say
what the best solution is.
Why, if you have a series of transformations, would you not just put
whatever second thing you need inside that same code. What is the reason
for wanting to do something later inside a series of transformations you
did
before? That is the obvious question I have.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
This ties back to the prior threads on libraries and learning OpenSCAD.
I think both of you have the best (and correct) strategy for approaching
this. Unfortunately we don't have a lot of documentation about how to
use OpenSCAD "well" so that a beginner learns to tackle things this way
from the start.
Whether you believe in libraries or not, coming up with resources to
share this type of knowledge would be valuable. I'm not really sure how
to teach it (let alone sure if I have a very good handle on many such
techniques) but it'd be great to see the community discuss these types
of practices so we can get them documented.
On 3/3/19 3:12 PM, nop head wrote:
Yes indeed. I never need to do this. To put the object at the origin I
simply don't put it under some transformations. If I want to transform
other objects to the same place I create a module that transforms its
children and apply it wherever wanted.
I don't need to ask where something is because I have placed it
relative to other objects in the design and then my machines make it.
I sometimes add echos of sizes that hare calculated to make sure they
will fit on my printers.
On Sun, 3 Mar 2019 at 21:03, adrianv <avm4@cornell.edu
mailto:avm4@cornell.edu> wrote:
I still want to know what the original poster was actually trying
to do with
a specific code example. I think without that it's difficult to
really say
what the best solution is.
Why, if you have a series of transformations, would you not just put
whatever second thing you need inside that same code. What is
the reason
for wanting to do something later inside a series of
transformations you did
before? That is the obvious question I have.
JordanBrown wrote
And even then, you can only tell it where something is relative to its
own transformations... you can't specify an absolute location.
That is, you can't say
sequence( ) of( ) transformations() {
translate_back_to_origin( ) {
object( );
}
}
The only way to do that would be to know the sequence of transformations
and unwind them.
Hmm, why would one like to write this? You can simple write
object( );
--
Sent from: http://forum.openscad.org/
One reason to what to know the global coordinates would be for labeling. I
posted questions about this recently and got good feedback.
For example, if I want to produce a printable schematic or design document
for translating the on-screen object into a real-world object through
traditional machining techniques, I need to know real world coordinates.
So if a particular edge or point is the result of multiple transformations,
it is difficult to determine that location for labeling.
A great solution would be to have built-in transformation functions of
vectors. But short of that, there are libraries that can do the same, so
that it can be determined manually.
Kevin
On Sun, Mar 3, 2019 at 1:13 PM nop head nop.head@gmail.com wrote:
Yes indeed. I never need to do this. To put the object at the origin I
simply don't put it under some transformations. If I want to transform
other objects to the same place I create a module that transforms its
children and apply it wherever wanted.
I don't need to ask where something is because I have placed it relative
to other objects in the design and then my machines make it. I sometimes
add echos of sizes that hare calculated to make sure they will fit on my
printers.
On Sun, 3 Mar 2019 at 21:03, adrianv avm4@cornell.edu wrote:
I still want to know what the original poster was actually trying to do
with
a specific code example. I think without that it's difficult to really say
what the best solution is.
Why, if you have a series of transformations, would you not just put
whatever second thing you need inside that same code. What is the reason
for wanting to do something later inside a series of transformations you
did
before? That is the obvious question I have.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I should start by stating that I don’t really know what I’m talking about, so I’ve already got an excuse if my question is stupid.
As I understand it, the primary impediment of access to things like current x,y,z location and getting a list of the current points in an object is because the CGAL CSG library API that OpenSCAD is built open doesn’t provide that kind of access. On the other hand, I note that OpenJSCAD has implemented their own CSG library in javascript, which, as I understand it, does provide access to the information.
Would that be the way to provide OpenSCAD with that kind of functionality?
I’m certainly aware that it’s easy to wave one's hand and say “let’s just get a whole bunch of contributors who have lots of free time to create this library for absolutely no compensation”, so I’m not saying that, I’m just wondering if that would be possible path forward and if it’s ever been considered as a possible roadmap for future work. I appreciate that any CSG functionality may not be as robust as CGAL, but on the other hand there’s already situations in which I’m piecing together point lists for simple geometric constructions for polygon() and polyhedron() that get overly complex rather quickly. I was thinking that some built-in CSG for union(), difference() and intersection() might provide the functionality that many people would want, even if it collapsed under sophisticated or overly complex constructions.
On Mar 4, 2019, at 8:40 AM, Kevin Toppenberg kdtop3@gmail.com wrote:
One reason to what to know the global coordinates would be for labeling. I posted questions about this recently and got good feedback.
For example, if I want to produce a printable schematic or design document for translating the on-screen object into a real-world object through traditional machining techniques, I need to know real world coordinates. So if a particular edge or point is the result of multiple transformations, it is difficult to determine that location for labeling.
A great solution would be to have built-in transformation functions of vectors. But short of that, there are libraries that can do the same, so that it can be determined manually.
Kevin
On Sun, Mar 3, 2019 at 1:13 PM nop head <nop.head@gmail.com mailto:nop.head@gmail.com> wrote:
Yes indeed. I never need to do this. To put the object at the origin I simply don't put it under some transformations. If I want to transform other objects to the same place I create a module that transforms its children and apply it wherever wanted.
I don't need to ask where something is because I have placed it relative to other objects in the design and then my machines make it. I sometimes add echos of sizes that hare calculated to make sure they will fit on my printers.
On Sun, 3 Mar 2019 at 21:03, adrianv <avm4@cornell.edu mailto:avm4@cornell.edu> wrote:
I still want to know what the original poster was actually trying to do with
a specific code example. I think without that it's difficult to really say
what the best solution is.
Why, if you have a series of transformations, would you not just put
whatever second thing you need inside that same code. What is the reason
for wanting to do something later inside a series of transformations you did
before? That is the obvious question I have.
--
Sent from: http://forum.openscad.org/ http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
There is no problem accessing CGAL data but I think it is only the stack of
transformation matrices that would be needed and they are outside of CGAL
as they are also needed for preview.
And as I previously pointed out OpenSCAD evaluates all the expressions and
then generates geometry. So the transformation matrices are not generated
at the point you could use them in an expression.
Since the user always places geometry in theory one can always work out
where it is but that may require a working knowledge of trigonometry and
matrix maths.
On Mon, 4 Mar 2019 at 18:00, Hugo Jackson hugo@apres.net wrote:
I should start by stating that I don’t really know what I’m talking about,
so I’ve already got an excuse if my question is stupid.
As I understand it, the primary impediment of access to things like
current x,y,z location and getting a list of the current points in an
object is because the CGAL CSG library API that OpenSCAD is built open
doesn’t provide that kind of access. On the other hand, I note that
OpenJSCAD has implemented their own CSG library in javascript, which, as I
understand it, does provide access to the information.
Would that be the way to provide OpenSCAD with that kind of functionality?
I’m certainly aware that it’s easy to wave one's hand and say “let’s just
get a whole bunch of contributors who have lots of free time to create this
library for absolutely no compensation”, so I’m not saying that, I’m just
wondering if that would be possible path forward and if it’s ever been
considered as a possible roadmap for future work. I appreciate that any CSG
functionality may not be as robust as CGAL, but on the other hand there’s
already situations in which I’m piecing together point lists for simple
geometric constructions for polygon() and polyhedron() that get overly
complex rather quickly. I was thinking that some built-in CSG for union(),
difference() and intersection() might provide the functionality that many
people would want, even if it collapsed under sophisticated or overly
complex constructions.
On Mar 4, 2019, at 8:40 AM, Kevin Toppenberg kdtop3@gmail.com wrote:
One reason to what to know the global coordinates would be for labeling.
I posted questions about this recently and got good feedback.
For example, if I want to produce a printable schematic or design document
for translating the on-screen object into a real-world object through
traditional machining techniques, I need to know real world coordinates.
So if a particular edge or point is the result of multiple transformations,
it is difficult to determine that location for labeling.
A great solution would be to have built-in transformation functions of
vectors. But short of that, there are libraries that can do the same, so
that it can be determined manually.
Kevin
On Sun, Mar 3, 2019 at 1:13 PM nop head nop.head@gmail.com wrote:
Yes indeed. I never need to do this. To put the object at the origin I
simply don't put it under some transformations. If I want to transform
other objects to the same place I create a module that transforms its
children and apply it wherever wanted.
I don't need to ask where something is because I have placed it relative
to other objects in the design and then my machines make it. I sometimes
add echos of sizes that hare calculated to make sure they will fit on my
printers.
On Sun, 3 Mar 2019 at 21:03, adrianv avm4@cornell.edu wrote:
I still want to know what the original poster was actually trying to do
with
a specific code example. I think without that it's difficult to really
say
what the best solution is.
Why, if you have a series of transformations, would you not just put
whatever second thing you need inside that same code. What is the
reason
for wanting to do something later inside a series of transformations you
did
before? That is the obvious question I have.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Thanks for the reply… I’m less ignorant than I was yesterday. :)
On Mar 4, 2019, at 10:28 AM, nop head nop.head@gmail.com wrote:
There is no problem accessing CGAL data but I think it is only the stack of transformation matrices that would be needed and they are outside of CGAL as they are also needed for preview.
And as I previously pointed out OpenSCAD evaluates all the expressions and then generates geometry. So the transformation matrices are not generated at the point you could use them in an expression.
Since the user always places geometry in theory one can always work out where it is but that may require a working knowledge of trigonometry and matrix maths.
On Mon, 4 Mar 2019 at 18:00, Hugo Jackson <hugo@apres.net mailto:hugo@apres.net> wrote:
I should start by stating that I don’t really know what I’m talking about, so I’ve already got an excuse if my question is stupid.
As I understand it, the primary impediment of access to things like current x,y,z location and getting a list of the current points in an object is because the CGAL CSG library API that OpenSCAD is built open doesn’t provide that kind of access. On the other hand, I note that OpenJSCAD has implemented their own CSG library in javascript, which, as I understand it, does provide access to the information.
Would that be the way to provide OpenSCAD with that kind of functionality?
I’m certainly aware that it’s easy to wave one's hand and say “let’s just get a whole bunch of contributors who have lots of free time to create this library for absolutely no compensation”, so I’m not saying that, I’m just wondering if that would be possible path forward and if it’s ever been considered as a possible roadmap for future work. I appreciate that any CSG functionality may not be as robust as CGAL, but on the other hand there’s already situations in which I’m piecing together point lists for simple geometric constructions for polygon() and polyhedron() that get overly complex rather quickly. I was thinking that some built-in CSG for union(), difference() and intersection() might provide the functionality that many people would want, even if it collapsed under sophisticated or overly complex constructions.
On Mar 4, 2019, at 8:40 AM, Kevin Toppenberg <kdtop3@gmail.com mailto:kdtop3@gmail.com> wrote:
One reason to what to know the global coordinates would be for labeling. I posted questions about this recently and got good feedback.
For example, if I want to produce a printable schematic or design document for translating the on-screen object into a real-world object through traditional machining techniques, I need to know real world coordinates. So if a particular edge or point is the result of multiple transformations, it is difficult to determine that location for labeling.
A great solution would be to have built-in transformation functions of vectors. But short of that, there are libraries that can do the same, so that it can be determined manually.
Kevin
On Sun, Mar 3, 2019 at 1:13 PM nop head <nop.head@gmail.com mailto:nop.head@gmail.com> wrote:
Yes indeed. I never need to do this. To put the object at the origin I simply don't put it under some transformations. If I want to transform other objects to the same place I create a module that transforms its children and apply it wherever wanted.
I don't need to ask where something is because I have placed it relative to other objects in the design and then my machines make it. I sometimes add echos of sizes that hare calculated to make sure they will fit on my printers.
On Sun, 3 Mar 2019 at 21:03, adrianv <avm4@cornell.edu mailto:avm4@cornell.edu> wrote:
I still want to know what the original poster was actually trying to do with
a specific code example. I think without that it's difficult to really say
what the best solution is.
Why, if you have a series of transformations, would you not just put
whatever second thing you need inside that same code. What is the reason
for wanting to do something later inside a series of transformations you did
before? That is the obvious question I have.
--
Sent from: http://forum.openscad.org/ http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 3/4/2019 1:51 AM, Parkinbot wrote:
JordanBrown wrote
And even then, you can only tell it where something is relative to its
own transformations... you can't specify an absolute location.
That is, you can't say
sequence( ) of( ) transformations() {
translate_back_to_origin( ) {
object( );
}
}
The only way to do that would be to know the sequence of transformations
and unwind them.
Hmm, why would one like to write this? You can simple write
object( );
It was a thought experiment, not a real-world example. The point was
that not only is it impossible to retrieve the absolute position from
inside a series of transformations, but it is also impossible to
specify an absolute position for whatever reason.
Perhaps object() is buried in a module with other stuff that is
intended to be relative to the transformations.