Is technical drawing possible?
[ crosshairs ]
I should have included a screen shot.
Adrian,
- polyRound: For example:
use <polyround.scad>module halfWrap(){
radiiPoints=[[-4,8,0],[12,8,20],[23,15,20], [55,0,13],
[23,-15,5],[12,-8,20],[-4,-8,0]]; polyRoundExtrude(radiiPoints,
winderThickness,3,3,fn=8);
%translate([0,0,0.3])polygon(getpoints(radiiPoints));//transparent}winderThickness
= 7;halfWrap();
Now, I want to put a hole 5mm from the right (+X) edge. How do I do that?
How can I determine the bounding-box for this shape?
- Gears:
Yes, my problem with BOSL2 gears is that I could not position the gear
correctly. For example:
include <BOSL2/std.scad>include <BOSL2/gears.scad>bevel_gear( pitch=5,
teeth=36, face_width=10, shaft_diam=5, pitch_angle=45, spiral_angle=0 );
How can I determine the distance that the lower face extends in the -Z
direction? How can I determine the distance that the upper face extends in
the +Z direction?
I finally gave up on using BOSL2 gears in favor of Dario Pellegrini's
PolyGear library which I was able to modify to provide bounding box info.
Thanks, Len
On Sun, Jan 16, 2022 at 10:26 AM Adrian Mariano avm4@cornell.edu wrote:
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:
For me, the lack of a measurement tool is most apparent when using
libraries such as Round-Anything.scad, or most gear-producing libraries
since they do not provide bounding-box info.
On Sun, Jan 16, 2022 at 6:12 AM jon jon@jonbondy.com wrote:
I sometimes use Ruler.SCAD when I want to see how my design compares to
an object of a known length. I also temporarily add a cube or cylinder of
the desired length. I have to do that only occasionally. For me, this is
only a minor annoyance.
On 1/16/2022 3:32 AM, edmund ronald wrote:
As you state this is clearly a doctrine issue because a reasonably
accurate measurement system can be integrated in the interface without
modifying the engine - I actually had to use a physical ruler to measure
the projections on the screen for my last design.
wrote:
I'm sorry, I didn't want to rekindle the tensions between those who
want an integrated measurement system and those who don't.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
when you select "show edges", what data is present In the application that
results in the lines and points displayed in the rendered window?
cube([2,2,2]);
translate([0,0,-1/128])
cylinder(,4,1,1,$fn=50);
Press F1 and F6 to render.
When rendered, where does the mapping between the 2d shapes that make up
the whole 3d object and the 2d display happening?
Is the problem that this mapping is done by a routine producing only what
is needed for the 2d display, and that no mapping from the 3d space to 2d
space is kept anywhere?
Where is the calculation that produces the edges happening?
-Pat
Crud! Now I'm going to have to get a copy of OpenScad sources and build it
and read some code. So many projects, so little time...
On Sun, Jan 16, 2022 at 12:42 PM Jordan Brown openscad@jordan.maileater.net
wrote:
On 1/16/2022 7:47 AM, dpa wrote:
Isn't there a possibility to get a distance by using Crosshair?
[image: Bildschirmfoto 2022-01-16 um 16.40.57.png]
like:
1. Place the crosshair to the start point (p0)
2. Press a (new) button "measure" to start measuring
3. now Place the crosshair to any other position
- while moving, a line is shown and always updated from p0 to the
current position
- and it always shows the distance from p0 to the current position
4. when done Press the "measure" button again = back to normal (no
measuring)
I know: Wishes are written very quickly but to build that in correctly is
a whole other effort. But the Crosshair certainly has a defined point... so
it's not quite so complicated. But I am a user, I can not write the code.
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([r2,t,t], center=true);
cube([t,r2,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 = r2;
cone_h = r4;
translate(a) rotate([0,p[2],p[1]]) {
translate([0,0,cone_h]) cylinder(h=p[0]-cone_h2,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=r2, center=true)
translate([p[0]/2,r*1.2,0])
text(label, size=h, halign="center", valign="bottom");
}
}
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Interesting.
I think what is happening here is similar to what happened to TeX. Knuth
designed a wonderful typesetting language, but he did not wish to provide
for interactivity. In practice, interactivity is very useful for layouts,
but it proved really hard to backfit any decent interactive environments to
TeX, between the "interactive" and the "programming" advocates, and LaTeX
layout still makes people cry from frustration today, and in practice a lot
of people prefer to go for a Wysiwyg system.
The object lesson here is that when (re)designing a language one should
provide hooks for introspection so that one can add interactivity to the
programmer's or user's experience.
Edmund
Edmund
On Sun, Jan 16, 2022 at 7:09 PM Jordan Brown openscad@jordan.maileater.net
wrote:
On 1/16/2022 8:31 AM, edmund ronald 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"
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.
On 1/16/2022 11:03 AM, Patrick Callahan wrote:
when you select "show edges", what data is present In the application
that results in the lines and points displayed in the rendered window?
I'm not sure how "show edges works".
All of the vertices are readily accessible. The problem is that it's
all of them, including the ones that are hidden or that will be
removed by intersection or difference.
When rendered, where does the mapping between the 2d shapes that make
up the whole 3d object and the 2d display happening?
Is the problem that this mapping is done by a routine producing only
what is needed for the 2d display, and that no mapping from the 3d
space to 2d space is kept anywhere?
Where is the calculation that produces the edges happening?
Strictly speaking, the 3D to 2D transform is done in OpenGL. But that's
the easy part; that's just a matrix multiply.
The hard part is figuring out which vertexes are visible.
OpenGL does all of that work, and the commentary that I've read suggests
that OpenGL itself doesn't really remember the intermediate steps.
If I'm understanding correctly: Each pixel on the screen has a Z
(depth) value. When OpenGL writes a pixel, that pixel includes its Z
value. Normally, if the new pixel's Z value is smaller than the old
pixel's Z value, it writes the new pixel; if not, it discards the new pixel.
Thus by the time that the display is complete, it doesn't remember
vertices or anything like that. It just knows that the pixels on the
screen are the topmost pixels. It doesn't truly "know" that a
particular vertex is visible.
Show edges only works when the result of F6 is a CGAL object. So that bug
would need to be fixed first as you need edges to be able to select them.
On Sun, 16 Jan 2022 at 20:29, Jordan Brown openscad@jordan.maileater.net
wrote:
On 1/16/2022 11:03 AM, Patrick Callahan wrote:
when you select "show edges", what data is present In the application that
results in the lines and points displayed in the rendered window?
I'm not sure how "show edges works".
All of the vertices are readily accessible. The problem is that it's
all of them, including the ones that are hidden or that will be removed
by intersection or difference.
When rendered, where does the mapping between the 2d shapes that make up
the whole 3d object and the 2d display happening?
Is the problem that this mapping is done by a routine producing only what
is needed for the 2d display, and that no mapping from the 3d space to 2d
space is kept anywhere?
Where is the calculation that produces the edges happening?
Strictly speaking, the 3D to 2D transform is done in OpenGL. But that's
the easy part; that's just a matrix multiply.
The hard part is figuring out which vertexes are visible.
OpenGL does all of that work, and the commentary that I've read suggests
that OpenGL itself doesn't really remember the intermediate steps.
If I'm understanding correctly: Each pixel on the screen has a Z (depth)
value. When OpenGL writes a pixel, that pixel includes its Z value.
Normally, if the new pixel's Z value is smaller than the old pixel's Z
value, it writes the new pixel; if not, it discards the new pixel.
Thus by the time that the display is complete, it doesn't remember
vertices or anything like that. It just knows that the pixels on the
screen are the topmost pixels. It doesn't truly "know" that a particular
vertex is visible.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 1/16/2022 11:19 AM, edmund ronald wrote:
I think what is happening here is similar to what happened to TeX.
Knuth designed a wonderful typesetting language, but he did not wish
to provide for interactivity. In practice, interactivity is very
useful for layouts, but it proved really hard to backfit any decent
interactive environments to TeX, between the "interactive" and the
"programming" advocates, and LaTeX layout still makes people cry from
frustration today, and in practice a lot of people prefer to go for a
Wysiwyg system.
I'd say that the enormous majority go for WYSIWYG, though they often
back-fill pseudo-programming onto it using styles. (I can support that
assertion with one word: Word.)
And yes, there are strong similarities. WYSIWYG and drawing programs
are about shoving your work around until it looks the way you want. TeX
and OpenSCAD are about writing rules that say how your work should be
processed to produce the final result.
This is a common mental disconnect when people come to OpenSCAD from
other environments. They say "I want to move that cube from here to
there", and they don't understand that the cube's location is not a
simple thing and may have been derived through some complex process...
and even the fact that it is a cube may have been derived through a
complex process.
It's also sort of like the difference between a "draw" program and a
"paint" program, that because "draw" programs work with shapes they can
do things like re-stack or rearrange the shapes that a "paint" program
can't do... and at the same time they can't easily do things like erase
half of a circle.
On 1/16/2022 12:36 PM, nop head wrote:
Show edges only works when the result of F6 is a CGAL object. So that
bug would need to be fixed first as you need edges to be able to
select them.
Hmm. My initial reaction was that (based on the stuff I was looking at
last night) it would be straightforward for the CSG / OpenGL stuff to
display edges.
But I think the problem is again that it would display all of the
edges, including the ones that are hidden or should have been removed by
intersection or difference.
(Not that I really understand how difference works in preview. And I
definitely don't understand how intersection works.)
Show edges in preview mode shows the edges of all the triangles, which
isn't really what you want for selecting features as the arbitrary
triangulation doesn't even match the STL that is produced.
On Sun, 16 Jan 2022 at 20:43, Jordan Brown openscad@jordan.maileater.net
wrote:
On 1/16/2022 12:36 PM, nop head wrote:
Show edges only works when the result of F6 is a CGAL object. So that bug
would need to be fixed first as you need edges to be able to select them.
Hmm. My initial reaction was that (based on the stuff I was looking at
last night) it would be straightforward for the CSG / OpenGL stuff to
display edges.
But I think the problem is again that it would display all of the edges,
including the ones that are hidden or should have been removed by
intersection or difference.
(Not that I really understand how difference works in preview. And I
definitely don't understand how intersection works.)
On 1/16/2022 12:47 PM, nop head wrote:
Show edges in preview mode shows the edges of all the triangles, which
isn't really what you want for selecting features as the arbitrary
triangulation doesn't even match the STL that is produced.
Ah. I believed you when you said it only works in CGAL mode, so I
didn't check whether it works in preview mode.
And indeed "show edges" works in preview mode, give or take as you say
the fact that CGAL triangulates differently than OpenSCAD itself does.
(Maybe OpenSCAD should triangulate before giving it to CGAL.)
In experimenting just now, I'm getting inconsistent results. For a
while, "wireframe" was giving me all of the edges, including the ones
intersected away, but now it's giving me the right answer. As is
correct for wireframe mode, it's not doing any hidden-edge elimination.
Anyhow, net, show-edges / wireframe look temptingly close to what you
need for vertex/edge selection, but I think they end up having the same
problems as ordinary preview mode.