dimensioning in openscad
This is another topic I think needs a lot of attention.
The dimensional details of the 3d model made should be easy to communicate.
I have written a few functions in python which can do this.
openscad file attached, just to show what it is capable of
you need the file dependencies2.scad in the same folder to view this
[image: Screenshot 2025-06-25 at 9.20.05 PM.png]
I hope this works.
On 25/06/2025 17:00, Sanjeev Prabhakar via Discuss wrote:
This is another topic I think needs a lot of attention.
The dimensional details of the 3d model made should be easy to
communicate.
I hope this works.
works for me, but no idea how to get it to dimension my stuff...
On Wed, Jun 25, 2025 at 06:14:24PM +0100, Raymond West via Discuss wrote:
On 25/06/2025 17:00, Sanjeev Prabhakar via Discuss wrote:
This is another topic I think needs a lot of attention.
The dimensional details of the 3d model made should be easy to
communicate.
I hope this works.
works for me, but no idea how to get it to dimension my stuff...
In Eagle, I can create an object that shows the dimension from point A
to point B at location C.
Openscad could add an object that behaves similar to that dimension
thing in eagle and like the axes in openscad: visible in preview, not
part of the final object. It would be the responsibility of the user
to locate C so that it can be seen.
This would draw a doublesided arrow parallel to AB through C. And then a line
from A, perpendicular to AB to that arrow, with one of the ends of the arrow
ending at the intersection. The same for B.
This would allow people to annotate their designs with readable dimensions.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
The hard part of drawing dimension lines is specifying both endpoints,
without manually calculating their final positions.
translate([100,0,0]) sphere();
rotate(27) translate([50,0,0]) sphere();
I want a dimension line between the centers of the two spheres. How
would I even say that? Drawing a dimension line from one point to
another is easy. The problem is figuring out where the two points are.
And then you get to tricky cases.
intersection() {
sphere(50);
translate([90,0,0]) sphere(50);
}
That makes a sort of a disk-like shape. I want a dimension line from
the top to the bottom.
I'm sure that I could use trig to figure out where the top and bottom
are, and then draw the line, but in general you can't even find the
points until you render the figure - and even if you could render the
figure first you need a way to say which points you're interested in.
In many cases what makes this hard is that OpenSCAD operations are
largely "black holes"; information goes in, but no information comes out.
I have a sort of dim idea layered atop PR#4478's geometry objects and
render() function. Perhaps there could be a way that you could drop a
named marker in a model, and then the location of that marker, as
transformed, would be made available as part of the returned render
data, or as the result of a function processing the geometry data. That
doesn't directly help with deriving locations that are based on the
results of boolean operations (like the intersection case above), but
the render() function will return the minima and maxima, and those may
help when you know the general shape that you're producing.
One might think that the named-marker idea could be usable more
directly, something like
translate([100,0,0]) {
marker("A");
sphere();
}
rotate(27) translate([50,0,0]) {
marker("B");
sphere();
}
dimension(getmarker("A"), getmarker("B"));
... but that runs afoul of OpenSCAD's general design principle that
there is no order to module execution among peers; OpenSCAD is free to
execute those two spheres and the dimension line in any order, including
in parallel.
It is possible to do some of this stuff today. It's just not fun.
I did some of it in a demo that I described at
https://lists.openscad.org/empathy/thread/IUPFIPEISP2XYU3SRVFWG54TLGSXMWOT
Cutting to the chase, here's the animation that resulted:
https://lists.openscad.org/empathy/attachment/248501
But that technique, although it's an interesting toy, isn't general
enough. It can only "communicate" between ancestor and descendant; only
the descendant can draw a dimension line to a point on the ancestor.
There's no way to do anything between cousins, because there's no way to
communicate up one family tree and down another.
I tried the first 2 cases you mentioned:
python code is as below and results
openSCAD files are also attached (I don't know if this mail goes through
due to its size)
case1:
s1=translate([100,0,0],sphere(5))
s2=rot('z27', translate([50,0,0],sphere(5)))
find the centers of sphere s1 and s2
c1=center_circle3d(cpo(s1)[0])
c2=center_circle3d(cpo(s2)[0])
dimensioning
txt1=dim_linear([c1,c2],0)
with open('trial.scad','w+') as f:
f.write(f'''
include<dependencies2.scad>
%{swp(s1)}
%{swp(s2)}
{txt1}
''')
[image: Screenshot 2025-06-26 at 7.08.28 AM.png]
Case2:
s1=sphere(50);
s2=translate([90,0,0], sphere(50))
find the intersection points
ips=ip_sol2sol(s1,axis_rot_o([0,1,0],s2,90))
sort the points in lexicographic sequence from bottom to top
ips1=lexico(ips,[2,0,1])
pick the first and the last points
p0,p1=ips1[0],ips1[-1]
dimensioning
txt1=dim_linear([p0,p1])
with open('trial.scad','w+') as f:
f.write(f'''
include<dependencies2.scad>
%{swp(s1)}
%{swp(s2)}
color("blue")points({ips},.5);
{txt1}
''')
[image: Screenshot 2025-06-26 at 7.07.42 AM.png]
The prerequisite is the drawing should be made with points list and not
with openscad primitives.
On Thu, 26 Jun 2025 at 05:28, Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
The hard part of drawing dimension lines is specifying both endpoints,
without manually calculating their final positions.
translate([100,0,0]) sphere();
rotate(27) translate([50,0,0]) sphere();
I want a dimension line between the centers of the two spheres. How would
I even say that? Drawing a dimension line from one point to another is
easy. The problem is figuring out where the two points are.
And then you get to tricky cases.
intersection() {
sphere(50);
translate([90,0,0]) sphere(50);
}
That makes a sort of a disk-like shape. I want a dimension line from the
top to the bottom.
I'm sure that I could use trig to figure out where the top and bottom
are, and then draw the line, but in general you can't even find the
points until you render the figure - and even if you could render the
figure first you need a way to say which points you're interested in.
In many cases what makes this hard is that OpenSCAD operations are largely
"black holes"; information goes in, but no information comes out.
I have a sort of dim idea layered atop PR#4478's geometry objects and
render() function. Perhaps there could be a way that you could drop a
named marker in a model, and then the location of that marker, as
transformed, would be made available as part of the returned render data,
or as the result of a function processing the geometry data. That doesn't
directly help with deriving locations that are based on the results of
boolean operations (like the intersection case above), but the render()
function will return the minima and maxima, and those may help when you
know the general shape that you're producing.
One might think that the named-marker idea could be usable more directly,
something like
translate([100,0,0]) {
marker("A");
sphere();
}
rotate(27) translate([50,0,0]) {
marker("B");
sphere();
}
dimension(getmarker("A"), getmarker("B"));
... but that runs afoul of OpenSCAD's general design principle that there
is no order to module execution among peers; OpenSCAD is free to execute
those two spheres and the dimension line in any order, including in
parallel.
It is possible to do some of this stuff today. It's just not fun.
I did some of it in a demo that I described at
https://lists.openscad.org/empathy/thread/IUPFIPEISP2XYU3SRVFWG54TLGSXMWOT
Cutting to the chase, here's the animation that resulted:
https://lists.openscad.org/empathy/attachment/248501
But that technique, although it's an interesting toy, isn't general
enough. It can only "communicate" between ancestor and descendant; only
the descendant can draw a dimension line to a point on the ancestor.
There's no way to do anything between cousins, because there's no way to
communicate up one family tree and down another.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 6/25/2025 6:46 PM, Sanjeev Prabhakar wrote:
The prerequisite is the drawing should be made with points list and
not with openscad primitives.
Right. Which is a pretty serious limitation.
And of course my first example isn't all that hard to unwind, but it's
a near-trivial example. Consider that the two subassemblies may be
much, much more complex, with the target point buried deeply in
transformations and among other pieces.
If I'm feeling interested enough, I'll see about isolating some
real-model case where I've wanted to do measurements. Generally they've
not been cases where unwinding the transformations is easy, because the
whole reason that I want to do measurements is to double check that I've
done the transformations correctly. They've been cases where A is
attached to B, B is attached to C, and C is attached to D, and A is also
attached to X, Y, and Z, and I want to confirm that the distance between
D and Z is correct.
To be clear: many of the cases are not insolvable, if you use a totally
different design than OpenSCAD. There are reasonable language /
model-design systems where you can be deep inside subassembly A, derive
a world coordinate, write it into a global variable, do the same from
subassembly B, and, then connect the two. But OpenSCAD isn't such a
system, because of the "black hole" nature of its modules.
BOSL2 has a feature that maybe does something like what you're talking
about.
https://github.com/BelfrySCAD/BOSL2/wiki/attachments.scad#function-desc_dist
On Thu, Jun 26, 2025 at 5:12 AM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 6/25/2025 6:46 PM, Sanjeev Prabhakar wrote:
The prerequisite is the drawing should be made with points list and not
with openscad primitives.
Right. Which is a pretty serious limitation.
And of course my first example isn't all that hard to unwind, but it's a
near-trivial example. Consider that the two subassemblies may be much,
much more complex, with the target point buried deeply in transformations
and among other pieces.
If I'm feeling interested enough, I'll see about isolating some real-model
case where I've wanted to do measurements. Generally they've not been
cases where unwinding the transformations is easy, because the whole reason
that I want to do measurements is to double check that I've done the
transformations correctly. They've been cases where A is attached to B, B
is attached to C, and C is attached to D, and A is also attached to X, Y,
and Z, and I want to confirm that the distance between D and Z is correct.
To be clear: many of the cases are not insolvable, if you use a totally
different design than OpenSCAD. There are reasonable language /
model-design systems where you can be deep inside subassembly A, derive a
world coordinate, write it into a global variable, do the same from
subassembly B, and, then connect the two. But OpenSCAD isn't such a
system, because of the "black hole" nature of its modules.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
If someone has the capability to draw models with a list of points, it
should be possible to dimension it most likely.
There could be a few cases which would be difficult as there is no
extensive experimentation on these functions.
But if this dimensioning capability can be achieved it would be a big asset
to the openscad community.
It's not so difficult to build models with points list. What is probably
required is to explain the design methodology to people.
Now the limitations.....
A lot of text and examples could to be created, but the problem is who has
the time to read extensive documentation and most of the time this becomes
scary for a common user and puts them off.
So, I wonder how do you make a 3d modeling software like this successful.
The answer maybe to be to keep it absolutely simple for everyone without
much fancy stuff.
The other thing is usability for professional work like making patterns and
dies for moulding / casting etc.
Openscad is far far off right now with it's current language system, which
i understand is appealing to beginners but little complication and the
hands are up.
It is not a complaint but a statement of fact.
My personal learning after writing all these codes for creating models has
been that it has helped me a lot in visualising things. This probably would
not have happened, had I not pursued this path.
Also I feel confident that I can learn GUI based modeling softwares very
quickly (if I wish to learn).
Thanks
On Thu, 26 Jun, 2025, 2:42 pm Jordan Brown, openscad@jordan.maileater.net
wrote:
On 6/25/2025 6:46 PM, Sanjeev Prabhakar wrote:
The prerequisite is the drawing should be made with points list and not
with openscad primitives.
Right. Which is a pretty serious limitation.
And of course my first example isn't all that hard to unwind, but it's a
near-trivial example. Consider that the two subassemblies may be much,
much more complex, with the target point buried deeply in transformations
and among other pieces.
If I'm feeling interested enough, I'll see about isolating some real-model
case where I've wanted to do measurements. Generally they've not been
cases where unwinding the transformations is easy, because the whole reason
that I want to do measurements is to double check that I've done the
transformations correctly. They've been cases where A is attached to B, B
is attached to C, and C is attached to D, and A is also attached to X, Y,
and Z, and I want to confirm that the distance between D and Z is correct.
To be clear: many of the cases are not insolvable, if you use a totally
different design than OpenSCAD. There are reasonable language /
model-design systems where you can be deep inside subassembly A, derive a
world coordinate, write it into a global variable, do the same from
subassembly B, and, then connect the two. But OpenSCAD isn't such a
system, because of the "black hole" nature of its modules.
On 6/26/2025 3:22 AM, Adrian Mariano via Discuss wrote:
BOSL2 has a feature that maybe does something like what you're talking
about.
https://github.com/BelfrySCAD/BOSL2/wiki/attachments.scad#function-desc_dist
[ I know that you know everything I'm saying below; this is for others. ]
I'm not surprised; I think we've talked about similar things.
But that "communication" is still only from ancestor to descendant, like
the demo that I did a few years ago. That is, it allows a child
(however many layers deep) to calculate distance, et cetera, from a
parent's point. It does not allow a parent to calculate the
relationship to a child's point, nor does it allow any component to
calculate relationships between "cousins".
I'm not saying it isn't useful, but there's a lot of important cases
that it can't cover.
If you have a model structured like so:
M
/ \
A X
/ \
B Y
/ \
C Z
then this technique cannot tell you anything about the relationship
between C and Z.
(Now, come to think of it, in one case where I needed this the model was
symmetric; A and X, B and Y, and C and Z were all mirrors of each
other. That would, in that case, allow at least some measurements from
M to C to be used to derive measurements from M to Z and thus C to Z.
But that trick wouldn't apply to an asymmetric model.)
Jordan, you're not wrong but also you're not right. The reason is that
BOSL2 provides restore().
Yes, in OpenSCAD fundamentally you can only pass information down the
tree. But because of restore() the geometric tree does not have to match
the syntactic tree. Note that below the two yellow cuboids() are for
practical purposes both at the top level, and the pink and green cuboids
are practically speaking, not in a child-ancestor relationship, and yet I
can still get the coordinates of points on the cube, draw a connecting
line, compute its distance, and so on.
include <BOSL2/std.scad>
cuboid(10)
align(TOP,BACK+RIGHT)
color_this("pink") cuboid(3) let(pink=parent())
restore()
right(20)
cuboid(10,anchor=TOP+FWD)
color_this("green")align(TOP,LEFT) cuboid(3) let(green=parent())
color_this("red")
stroke([desc_point(green,anchor=TOP),
desc_point(pink,anchor=RIGHT)],dots=true,width=0.5);
[image: image.png]
On Thu, Jun 26, 2025 at 12:33 PM Jordan Brown openscad@jordan.maileater.net
wrote:
On 6/26/2025 3:22 AM, Adrian Mariano via Discuss wrote:
BOSL2 has a feature that maybe does something like what you're talking
about.
https://github.com/BelfrySCAD/BOSL2/wiki/attachments.scad#function-desc_dist
[ I know that you know everything I'm saying below; this is for others. ]
I'm not surprised; I think we've talked about similar things.
But that "communication" is still only from ancestor to descendant, like
the demo that I did a few years ago. That is, it allows a child (however
many layers deep) to calculate distance, et cetera, from a parent's point.
It does not allow a parent to calculate the relationship to a child's
point, nor does it allow any component to calculate relationships between
"cousins".
I'm not saying it isn't useful, but there's a lot of important cases that
it can't cover.
If you have a model structured like so:
M
/ \
A X
/ \
B Y
/ \
C Z
then this technique cannot tell you anything about the relationship
between C and Z.
(Now, come to think of it, in one case where I needed this the model was
symmetric; A and X, B and Y, and C and Z were all mirrors of each other.
That would, in that case, allow at least some measurements from M to C to
be used to derive measurements from M to Z and thus C to Z. But that trick
wouldn't apply to an asymmetric model.)
