IIRC this has been done in user code by redefining translate, rotate, etc
to use multmatrix and maintaining an inverse transform in a $variable.

On Fri, 27 Aug 2021 at 21:22, Bob Ewart jinnicky@bobsown.net wrote:

On 8/27/2021 1:22 PM, Bob Ewart wrote:

You might think so.  And it could.  But no, it doesn't.

Turning the example into a concrete one:

translate([1,2,3]) {
    rotate([4,5,6]) {
        translate([7,8,9]) {
            cube();
        }
    }
}

the result of executing the OpenSCAD program is this CSG tree:

multmatrix([[1, 0, 0, 1], [0, 1, 0, 2], [0, 0, 1, 3], [0, 0, 0, 1]]) {
  multmatrix([[0.990737, -0.0982275, 0.0937587, 0], [0.104131, 0.992735, -0.0602863, 0], [-0.0871557, 0.069491, 0.993768, 0], [0, 0, 0, 1]]) {
    multmatrix([[1, 0, 0, 7], [0, 1, 0, 8], [0, 0, 1, 9], [0, 0, 0, 1]]) {
      cube(size = [1, 1, 1], center = false);
    }
  }
}

It is a later stage, after the execution is done, after the program has
any control, that actually does the geometric work.

As nophead says, it's possible to do something equivalent in the
OpenSCAD program, by carrying redefining the various transformations and
using $ variables to pass down the accumulated transformation.

Here's a thread that discusses some experiments in doing that:
https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates-for-objects-td30377.html

Perhaps it would be a worthwhile project to make that capability
available using the built-in transforms.

norm(p1-p2) will give you the distance between two points.  But:  even
with the $-variable trickery above, the "physics" of the OpenSCAD
universe constrain what you can do.  OpenSCAD modules are black holes;
you cannot get information out of them.  Thus, if you have

... some sequence of transforms ... {
    A();
}
... some other sequence of transforms ... {
    B();
}

although A() could maybe know where it is, and B() could maybe know
where it is, nothing can know where both A() and B() are, because
there is no way to get the information out of the stack of transforms. 
(Except via echo() or text(), but the information is not then available
to the OpenSCAD program.)

Yes, with some appropriate use of atan2(), but with the same physics
limitations.

On Friday 27 August 2021 22:18:03 Jordan Brown wrote:

I know I'd sure like to have the ruler thats located at 0,0,0 in the
display, made portable so its available to lay across a part to find out
how big it is. That would be handier than the turn button on the
outhouse door at a family reunion. I'm also aware thats one very tall
order to do in 3d space. But the need is there.

Cheers, Gene Heskett

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/gene

Many people have written rulers.  You can probably easily find a few with
google.  Also there's one in BOSL2:

include<BOSL2/std.scad>
cylinder(h=10,r=7.5,$fn=25);
ruler(10);

Of course, this ruler is part of your model, not something you can lay down
over your mode as you view it.

To the original poster I'd ask why you want to measure a distance.  What
are you planning to do with the result?  There may be some simple way to
achieve your end goal that doesn't require measuring.

On Sat, Aug 28, 2021 at 2:32 AM Gene Heskett gheskett@shentel.net wrote:

I am working on a little sign in two parts, the sign itself and a
support bracket.  I want to make sure that the connectors are the same
distance apart and that the are far enough apart to fit over a bracket
holding my monitor.

--
Bob

Truth is stranger than fiction because fiction has to make sense.

On 8/28/21 7:41 AM, Adrian Mariano wrote:

Hey, I'd like that, too ....

But,

Executive summary : The point or elegance of OpenSCAD is that you define
exactly where you want each part to go. Why measure it? (Answer: to verify
your code)

Longer version: There have also been requests that you can "nudge" a part
interactively with the mouse. I'd like that, too, but again - that's not
the point of the declarative language and only exact numbers. If you want
to design with drag-n-drop use tinkercad.com or blender etc. Yes, I too,
sometimes am too lazy, or do not have the required
trigonometric/mathematical skill. So I fudge it. I keep entering a new
fudge value until it fits. Of course I never know if it actually fits, it
just looks good on screen (zoom in zoom in ,...). For my average 3D printer
that's often good enough. Hint: Use the animation feature, then you get a
refresh as you type.

Of course, if I do proper design, ie. think about what I want to do,
modularize my OpenSCAD program, use wiki for a "math refresher course" and
so on, then I do not need to measure my output.

Actually I do. I have this seperate visualizer tool for STL files (3D Tool
Free), and there I can get the 3D distance and angle between any two
points, edges, surface and what not. As it is NOT part of OpenSCAD it
also checks for other bugs that might be. Verifying my design before
committing to plastic, so to speak.

Remember that you can write a module that only does a transform - see
"children()". I've also used a module/function combination in a sub
assembly whose only purpose is to return a number (a distance f.ex) that
needs to be repeated in another part of the model. Which brings me back to
the executive summary.

Msquare

On Fri, 27 Aug 2021 at 22:22, Bob Ewart jinnicky@bobsown.net wrote:

Hi Bob, mine and your last email crossed in time. This was sort of what I
was hinting at. You define the critical distance in a separate module or
file which you use in both part designs.

You create a module with the common parts (the shape of a screw hole?)
and/or a function which returns the critical distance. Then in your two
parts you call that module/function. (modules return a shape or transform a
child shape; functions are just mathematical one-line functions)

You can have both parts in the same file, where you just comment out a line
or other which determines which part to render this time - or - you have a
common file, and in your two shape files you use "include <filename>".
Either way you are certain you have used the same distance.

And the point is - you don't measure the distance created in one module and
then recode it in the other part - you code the distance, once.

On Sat, 28 Aug 2021 at 15:14, Bob Ewart jinnicky@bobsown.net wrote:

On Saturday 28 August 2021 09:15:26 Michael Möller wrote:

I don't think my machine has the horsepower to do that in real time. And
printers seem to have a mind of their own, I have some parts that are
supposed to be 5.98mm tall, and I watched it finish as 5.99mm on the
printers own display, but when mic'd, it is 6.51mm tall. Needs lots of
sanding to fix that...

Cheers, Gene Heskett

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/gene

If your printer is printing 5.98mm parts to be 6.51mm tall it's seriously
out of calibration...

On Sat, Aug 28, 2021, 7:31 AM Gene Heskett gheskett@shentel.net wrote: