I guess it depends on what part of Round-Anything you're using, but if
you're using polyRound then you have the point list, so you can
compute the bounding box, and really polyRound seems like the heart of
RoundAnything.  And similarly, any gear library is building a
polyhedron, so it has the point list and hence knows the bounds of its
output.  In BOSL2, for example, the gear library can return the
coordinate points of the gear, from which you can easily extract the
bounds.  Why do you need to know the size of the gears?  If it's so
you can position other objects in the model then you don't really need
the size, you just need to be able to position objects relative to
each other, which is a different requirement.

On Sun, Jan 16, 2022 at 10:46 AM Leonard Martin Struttmann
lenstruttmann@gmail.com wrote:

So, what you see in the OpenSCAD viewing window is a 2D representation of a
3D image.  As such, you are really just looking at a bunch of 2D shapes
that you can place your mouse pointer on top of.  Clicking would select
that surface represented by the shape under the mouse pointer.

You can't select points in space this way, but you can select shapes as you
see them in the viewing window.  Select two shapes and the software can
then start to calculate distances.  Things can still be tricky if the
shapes are not coplanar, but those shapes could either produce an "invalid"
distance, or a range of min/max distances.  Much more tricky, but just as
easy from the user perspective, would allow a vertex to be selected by
selecting all of the shapes that connect to it.  The SW could then deduce
the vertex as the only point common to all the selected shapes.  This only
works if the shapes perfectly bound each other, of course.

Alternatively, having a way to display the precise coordinates of a shape
selected as described above would also be huge leap and shouldn't be all
that difficult to code.  Some operator calculations would be needed to
measure distances, but I could live with that.

I synthesize objects from scratch.  Some are to be 3D printed, but some are
destined for conversion to step format for use in a PCB layout
application.  In all cases, I am generally confronted with a conundrum: How
can I confirm that I got the dimensions correct?  I have been getting
better at making my models extensible using coded constants (I don't like
to call them variables as they can only be set once... a variable can VARY,
but I digest...) but it can still be difficult to keep everything straight
in a complex model.  Exporting to another tool is certainly possible, but
it is time consuming both from the steps needed to export/import and from
the aspect of having to learn how to use a different software package and
keep that skill from spoiling.  If I'm going to do all that, I should just
learn how to use the other CAD tool and not use OpenSCAD.

Being able to measure coordinates and shape extents would be really useful,
and shouldn't break the bank regarding coding resources.  Just my opinion,
of course.

On Sun, Jan 16, 2022 at 9:59 AM nop head nop.head@gmail.com wrote:

I think that at render time every object obtains a local origin. If that
local origin were then programmatically accessible, eg as a named
coordinate if the user supplies a nane, then interface macros could compute
a distance or locate crosshairs there. It would be left to the user to
pepper his code with "beacons"

Edmund

On Sunday, January 16, 2022, nop head nop.head@gmail.com wrote:

I mean at render every object obtains a local origin whose absolute coords
are then known -at render.

On Sunday, January 16, 2022, edmund ronald edmundronald@gmail.com wrote:

The OpenSCAD code is executed before any geometry is created or calculated,
so it can't have expressions equal to geometric points unless bits of
geometry are rendered while the script is evaluated. Like in the PR that
returns info from a render() block.

On Sun, 16 Jan 2022 at 16:31, edmund ronald edmundronald@gmail.com wrote:

On 16.01.22 09:32, edmund ronald wrote:

Ok, let me make that abundantly clear with an official
statement so we can stop with the guessing.

A measurement tool would be very welcome. There's a $305 bounty
on that topic and I'm happy to double that from the OpenSCAD
funds if that would help to encourage someone to contribute
an initial implementation.

ciao,
Torsten.

On 1/16/2022 12:32 AM, edmund ronald wrote:

So I just spent some time looking at the rendering functions and reading
up on OpenGL.

OpenSCAD per se has no idea which faces are in front of each other. 
Pretty much, it throws a bunch of faces at OpenGL, and OpenGL figures
out how to display them.  I'm not sure, but I don't think OpenSCAD even
knows where the faces end up on the screen, though that part's pretty
easy.  The hard part is figuring out which vertexes are visible.

OpenGL does not seem to have have mechanisms for selecting points. 
(This
https://stackoverflow.com/questions/7238518/how-to-drag-the-line-segment-by-selecting-the-vertex
article suggests that it used to have one, but that there are better
strategies and so it got removed.)

Here's a description of how to do it:

There are several better ways to do selection (that's why selection
mode has been removed from OpenGL after all). If it's just single
vertices in specific geometry (like a selection rubberband) you're
after, then you should perform the whole transformation of those
points into normalized device coordinates yourself, sort them into
some screen space spatial subdivision structure (2d Kd tree,
quadtree, etc.) so that you can determine the point clicked on in
/O(log n)/ time – in contrast to the O(n) you'd have with selection
mode, in which you have to "draw" the whole rubberband, so that all
points are tested.

Clearly there are people who know how to do this.  I'm not one of them,
though based on that description and reading up on k-d trees I might be
able to figure it out.

But it's not a matter of just adding some quick vertex selection mechanisms.

On 1/16/2022 8:28 AM, FF Systems wrote:

What bank?

There are no employees who can simply be assigned to do this work.

There are only volunteers, who work on things that interest them or
that will help them, or that they think are important to the community.

So far, nobody has volunteered to do this work.

(And yes, there's a bounty.  A couple of hundred dollars will buy you
several nice dinners... or a couple of hours of programmer time.  This
is not a couple-of-hour effort.  I can't speak for anybody else, but my
time is already full; a few hundred - or even a few thousand - dollars
wouldn't influence my decision on whether to spend tens or perhaps even
hundreds of hours of my free time.)

On 1/16/2022 7:47 AM, dpa wrote:

To a certain extent this can be done in the OpenSCAD program. 
Positioning the crosshairs is a pain in the neck, but doable.

Here's a sample program.  It will place two crosshairs, and draw a
dimension line between them.  You can control the location of the
crosshairs from the Customizer.

p1 = [0,0,0];
p2 = [100,100,100];

module crosshair(r, t=1) {
    cube([r*2,t,t], center=true);
    cube([t,r*2,t], center=true);
    cube([t,t,r*2], center=true);
}

translate(p1) color("red") crosshair(100);
translate(p2) color("red") crosshair(100);
color("red") dim3(p1, p2);

// Given an [x,y,z], transform to a
// [rho, theta, phi].
// Note that in mathematical spherical coordinates,
// phi is measured down from vertical.  This is as
// opposed to geographic coordinates, where latitude
// is measured up from the equator.

function topolar3(p) = [
    norm(p),
    atan2(p.y, p.x),
    atan2(norm([p.x,p.y]), p.z)
];

module dim3(a, b, rot=0, h=10, d=1) {
    r = d/2;
    p = topolar3(b-a);
    label = str(round(p[0]));
    cone_r = r*2;
    cone_h = r*4;
    translate(a) rotate([0,p[2],p[1]]) {
        translate([0,0,cone_h]) cylinder(h=p[0]-cone_h*2,r=r);
        translate([0,0,p[0]-cone_h]) cylinder(h=cone_h, r1=cone_r, r2=0);
        cylinder(h=cone_h, r1=0, r2=cone_r);
        rotate([0,-90,0])
            rotate([rot,0,0])
            linear_extrude(height=r*2, center=true)
            translate([p[0]/2,r*1.2,0])
            text(label, size=h, halign="center", valign="bottom");
    }
}

On 1/16/2022 8:31 AM, edmund ronald wrote:

Yes.

Unfortunately, OpenSCAD's design is such that that's very difficult. 
And there are interesting cases where it's just difficult, period.

• OpenSCAD has no programmatic access to the geometry.  It doesn't
  know, itself, where everything is until after the program has
  finished executing.[1][2]
• OpenSCAD modules are black holes.  No information can come out of
  them.  There are no global variables that can be written, and
  there's no way for them to return values.[3][4]
• There are constructs where it's difficult to even identify the
  points.  Consider, for instance, the intersection of two spheres. 
  If you want to measure the distance across the resulting disk-oid,
  what are the points that you would use?[5]

[1] There's a project in the works to provide some programmatic access;
ref PR #3956 https://github.com/openscad/openscad/pull/3956.  But
except for simple cases like bounding boxes, it would still be hard to
identify particular points.

[2] It is possible for a program to track its transformations; ref
this
https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates-for-objects-td30377.html
thread.

[3] They can echo() values that could be collected by an external
process and post-processed.

[4] In combination with tracking transformations, you can build very ...
stilted ... models where one point is a descendant of the other, and
then have both point values accessible.

[5]  In some orientations, the bounding box will tell you.  Now consider
a less trivial example where the bounding box isn't the right answer. 
Start with the cases where the intersection circle is not aligned with
the axes.  Continue with cases where you want to look at multiple points
of intersection.