K
Ken
Thu, Jan 18, 2024 7:24 AM
Thanks Jordan, that will be greatly appreciated if you can find the time
for it.
On 2024-01-18 17:58, Jordan Brown via Discuss wrote:
On 1/17/2024 10:31 PM, Ken via Discuss wrote:
And the customiser would be a lot more usable for some of us if the
developer gave it customisable font size so we could actually see it!
I'll see if I can spend some time on that. No promises - prying time
free is tough - but since it's not a language change it shouldn't have
the slow going that most of my work does.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
A baby can be defined as an ego with a noise at one end and a smell at the other.
Your job as parents is to teach them to control all three.
My job as a grandad is to tell you how you are doing it all wrong!
Thanks Jordan, that will be greatly appreciated if you can find the time
for it.
On 2024-01-18 17:58, Jordan Brown via Discuss wrote:
> On 1/17/2024 10:31 PM, Ken via Discuss wrote:
>> And the customiser would be a lot more usable for some of us if the
>> developer gave it customisable font size so we could actually see it!
>
> I'll see if I can spend some time on that. No promises - prying time
> free is tough - but since it's not a language change it shouldn't have
> the slow going that most of my work does.
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
Cheers, Ken
bats059@gmail.com
https://vk7krj.com
https://vk7krj.com/running.html
----------------------------------------
A baby can be defined as an ego with a noise at one end and a smell at the other.
Your job as parents is to teach them to control all three.
My job as a grandad is to tell you how you are doing it all wrong!
RW
Rogier Wolff
Thu, Jan 18, 2024 11:11 AM
On Wed, Jan 17, 2024 at 07:51:33PM +0000, Jordan Brown wrote:
On 1/17/2024 5:02 AM, Rogier Wolff via Discuss wrote:
On Wed, Jan 17, 2024 at 04:19:22AM +0000, Jordan Brown via Discuss wrote:
- Have a click-y way to add any existing module, parameterized, to the
top level.
I think much more is possible.
[ ... what you might call click-assisted editing ... ]
Well, yeah... but were any of those clicks on the model in the view area?
If you reverse the projection of 3D => screen, you'll get a line.
If you keep a "default distance from the camera", then that is the
place to put new objects. The user is responsible for turning the
viewpoint and positioning the new objects to the correct 3D position.
A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
right" button would be very useful to prevent unwanted movement on the
line that was just correctly positioned.
But my impression is that that's not what people are talking about when
they talk about GUI interfaces to modeling.
Right, and my suggestion is.
Keep in mind that openscad is just being used as something to visualize the
textfile that is being edited by the gui.
I don't think that's what the people who occasional ask for this kind of
thing are thinking of. I think they'd rather hide the editor pane and
work only with the view pane. (But I'm not one of them, so maybe I
misread their desires.)
Yes. My inclusion of the openscad code was meant as the "reasonably
simple" actions that the editor-shell would need to do to the openscad
file to give the user the impresion that actions are being taken on
their clicks.
With some help from openscad, this could become even more
useful. People like to select (sub)modules by pointing and
clicking. So something that might need to be added to openscad is:
"What object caused the pixel at x,y to be colored the way it is?". I
think it would need to report the lowest level object that
satisfies. The user should then be able to click "up" enough times to
go up the hierarchy to find the proper
There is some of that today, with the ability to right-click on the
model in the view pane and get the stack and click on the desired
level. That will show you all of the "color" invocations that fed into
that pixel.
Oh Wow!
hmm. Rightclick is move viewpoint on mine. If that's changed in a more
recent version... that's a change that is not backward compatble with
my wet-ware.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, 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.
On Wed, Jan 17, 2024 at 07:51:33PM +0000, Jordan Brown wrote:
> On 1/17/2024 5:02 AM, Rogier Wolff via Discuss wrote:
> > On Wed, Jan 17, 2024 at 04:19:22AM +0000, Jordan Brown via Discuss wrote:
> >> * Have a click-y way to add any existing module, parameterized, to the
> >> top level.
> > I think much more is possible.
> > [ ... what you might call click-assisted editing ... ]
>
> Well, yeah... but were any of those clicks on the model in the view area?
If you reverse the projection of 3D => screen, you'll get a line.
If you keep a "default distance from the camera", then that is the
place to put new objects. The user is responsible for turning the
viewpoint and positioning the new objects to the correct 3D position.
A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
right" button would be very useful to prevent unwanted movement on the
line that was just correctly positioned.
> But my impression is that that's not what people are talking about when
> they talk about GUI interfaces to modeling.
Right, and my suggestion is.
> > Keep in mind that openscad is just being used as something to visualize the
> > textfile that is being edited by the gui.
>
> I don't think that's what the people who occasional ask for this kind of
> thing are thinking of. I think they'd rather hide the editor pane and
> work only with the view pane. (But I'm not one of them, so maybe I
> misread their desires.)
Yes. My inclusion of the openscad code was meant as the "reasonably
simple" actions that the editor-shell would need to do to the openscad
file to give the user the impresion that actions are being taken on
their clicks.
> > With some help from openscad, this could become even more
> > useful. People like to select (sub)modules by pointing and
> > clicking. So something that might need to be added to openscad is:
> > "What object caused the pixel at x,y to be colored the way it is?". I
> > think it would need to report the lowest level object that
> > satisfies. The user should then be able to click "up" enough times to
> > go up the hierarchy to find the proper
>
> There is some of that today, with the ability to right-click on the
> model in the view pane and get the stack and click on the desired
> level. That will show you all of the "color" invocations that fed into
> that pixel.
Oh Wow!
hmm. Rightclick is move viewpoint on mine. If that's changed in a more
recent version... that's a change that is not backward compatble with
my wet-ware.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, 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.
RW
Rogier Wolff
Thu, Jan 18, 2024 11:22 AM
On Thu, Jan 18, 2024 at 12:11:45PM +0100, Rogier Wolff via Discuss wrote:
If you keep a "default distance from the camera", then that is the
place to put new objects. The user is responsible for turning the
viewpoint and positioning the new objects to the correct 3D position.
A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
right" button would be very useful to prevent unwanted movement on the
line that was just correctly positioned.
I'm now realizing that at first I was thinking: just put the object at
the origin. Now I'm thinking at the default distance from the current
view-point in the middle of the screen. That's implementation details
the implementer has to think about and implement whatever they think
is best.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, 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.
On Thu, Jan 18, 2024 at 12:11:45PM +0100, Rogier Wolff via Discuss wrote:
> If you keep a "default distance from the camera", then that is the
> place to put new objects. The user is responsible for turning the
> viewpoint and positioning the new objects to the correct 3D position.
> A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
> right" button would be very useful to prevent unwanted movement on the
> line that was just correctly positioned.
I'm now realizing that at first I was thinking: just put the object at
the origin. Now I'm thinking at the default distance from the current
view-point in the middle of the screen. That's implementation details
the implementer has to think about and implement whatever they think
is best.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, 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.
NH
nop head
Thu, Jan 18, 2024 11:52 AM
I think it is double right click to show the stack trace that produced the
pixel. It's a nightmare for me because my Microsoft mice have switch bounce
on the right button and on some PCs the stack trace makes the screen black
and I have to restart OpenSCAD.
On Thu, 18 Jan 2024 at 11:22, Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:
On Thu, Jan 18, 2024 at 12:11:45PM +0100, Rogier Wolff via Discuss wrote:
If you keep a "default distance from the camera", then that is the
place to put new objects. The user is responsible for turning the
viewpoint and positioning the new objects to the correct 3D position.
A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
right" button would be very useful to prevent unwanted movement on the
line that was just correctly positioned.
I'm now realizing that at first I was thinking: just put the object at
the origin. Now I'm thinking at the default distance from the current
view-point in the middle of the screen. That's implementation details
the implementer has to think about and implement whatever they think
is best.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, 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.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I think it is double right click to show the stack trace that produced the
pixel. It's a nightmare for me because my Microsoft mice have switch bounce
on the right button and on some PCs the stack trace makes the screen black
and I have to restart OpenSCAD.
On Thu, 18 Jan 2024 at 11:22, Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:
> On Thu, Jan 18, 2024 at 12:11:45PM +0100, Rogier Wolff via Discuss wrote:
> > If you keep a "default distance from the camera", then that is the
> > place to put new objects. The user is responsible for turning the
> > viewpoint and positioning the new objects to the correct 3D position.
> > A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
> > right" button would be very useful to prevent unwanted movement on the
> > line that was just correctly positioned.
>
> I'm now realizing that at first I was thinking: just put the object at
> the origin. Now I'm thinking at the default distance from the current
> view-point in the middle of the screen. That's implementation details
> the implementer has to think about and implement whatever they think
> is best.
>
> Roger.
>
> --
> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
> **
> ** Delftechpark 11 2628 XJ Delft, 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.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
GS
Guenther Sohler
Thu, Jan 18, 2024 11:53 AM
If you reverse the projection of 3D => screen, you'll get a line.
Exactly this, is key to be able to select existing points in the rendered
model.
Having this line last step is to find out, which points are nearby this
line with a few pixels tolerance.
Being able to select certain points, measuring stuff is just peanuts
>
> If you reverse the projection of 3D => screen, you'll get a line.
Exactly this, is key to be able to select existing points in the rendered
model.
Having this line last step is to find out, which points are nearby this
line with a few pixels tolerance.
Being able to select certain points, measuring stuff is just peanuts
>
>
GS
Guenther Sohler
Thu, Jan 18, 2024 11:55 AM
Once somebody manages to read back the the depth value right below the
cursor position, we can easily select 3D locations within the rendered
model even in preview mode.
On Thu, Jan 18, 2024 at 12:52 PM nop head via Discuss <
discuss@lists.openscad.org> wrote:
I think it is double right click to show the stack trace that produced the
pixel. It's a nightmare for me because my Microsoft mice have switch bounce
on the right button and on some PCs the stack trace makes the screen black
and I have to restart OpenSCAD.
On Thu, 18 Jan 2024 at 11:22, Rogier Wolff via Discuss <
discuss@lists.openscad.org> wrote:
On Thu, Jan 18, 2024 at 12:11:45PM +0100, Rogier Wolff via Discuss wrote:
If you keep a "default distance from the camera", then that is the
place to put new objects. The user is responsible for turning the
viewpoint and positioning the new objects to the correct 3D position.
A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
right" button would be very useful to prevent unwanted movement on the
line that was just correctly positioned.
I'm now realizing that at first I was thinking: just put the object at
the origin. Now I'm thinking at the default distance from the current
view-point in the middle of the screen. That's implementation details
the implementer has to think about and implement whatever they think
is best.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, 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.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Once somebody manages to read back the the depth value right below the
cursor position, we can easily select 3D locations within the rendered
model even in preview mode.
On Thu, Jan 18, 2024 at 12:52 PM nop head via Discuss <
discuss@lists.openscad.org> wrote:
> I think it is double right click to show the stack trace that produced the
> pixel. It's a nightmare for me because my Microsoft mice have switch bounce
> on the right button and on some PCs the stack trace makes the screen black
> and I have to restart OpenSCAD.
>
> On Thu, 18 Jan 2024 at 11:22, Rogier Wolff via Discuss <
> discuss@lists.openscad.org> wrote:
>
>> On Thu, Jan 18, 2024 at 12:11:45PM +0100, Rogier Wolff via Discuss wrote:
>> > If you keep a "default distance from the camera", then that is the
>> > place to put new objects. The user is responsible for turning the
>> > viewpoint and positioning the new objects to the correct 3D position.
>> > A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
>> > right" button would be very useful to prevent unwanted movement on the
>> > line that was just correctly positioned.
>>
>> I'm now realizing that at first I was thinking: just put the object at
>> the origin. Now I'm thinking at the default distance from the current
>> view-point in the middle of the screen. That's implementation details
>> the implementer has to think about and implement whatever they think
>> is best.
>>
>> Roger.
>>
>> --
>> ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
>> **
>> ** Delftechpark 11 2628 XJ Delft, 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.
>> _______________________________________________
>> 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
>
RW
Raymond West
Thu, Jan 18, 2024 1:19 PM
I do not need to measure much within openscad. When I do I find
eyeballing is good enough. There was a thread back in September 2021,
where I explained what I ended up doing, which works good enough for me.
You can home in pretty quickly adjusting the values of p1 and p2.
I've simplified my eyeballing technique, distances can be measured
fairly quickly.
I start off by defining the tolerance I'm happy with.
I've made a module named tol() and set it to 0.5 for this example
module tol(t){
# sphere(t);
}
then I place a tolerance sphere at each of the two points I'm
measuring between
e.g. like
p1=([0,0,10]);
translate(p1)tol(); // first point
p2=([54.5,11.2,41.3]);
translate(p2)tol(); // second point
They are easy to position, one at a time, by positioning x,y from the
top or bottom view, adjusting the appropriate values in PI or P2, and
then position z from one of the other views. zooming or rotating the
view as required.
then the distance can be echoed by something like
module dist(p1,p2){
dx= p2.x-p1.x;
dy= p2.y-p1.y;
dz= p2.z-p2.y;
l= sqrt((dxdx) +(dydy) +(dz*dz));
echo(distance = l);
}
provided the points of interest lie within the tolerance spheres, I
get the distance between the points within my defined tolerance,. If I
want a more accurate result, I can reduce the tolerance and zoom in
closer when positioning the spheres. If the tolerance sphere is too
small, to see on the full size view, then I could easily place a few
rings around them, or similar.
On 18/01/2024 00:20, edmund ronald via Discuss wrote:
I don't know whether it helps, but I like working in the Edit pane
typing code. It's just that some things like finding the distance
between two points, or quickly adjusting a size is a pain. One
workaround would be to have cursors inside the viewing area, for
measurement -like on engineering scopes where one places a cursor eg.
to measure lag- and also be able to slave a parameter in the Edit pane
to a slider so that one can quickly adjust it while seeing the effect
in the wireframe. Last and not least there is the thing about the
extrusion poly lines, but that is truly point and click and a
different story, I agree.
Edmund
I do not need to measure much within openscad. When I do I find
eyeballing is good enough. There was a thread back in September 2021,
where I explained what I ended up doing, which works good enough for me.
You can home in pretty quickly adjusting the values of p1 and p2.
> I've simplified my eyeballing technique, distances can be measured
> fairly quickly.
>
> I start off by defining the tolerance I'm happy with.
>
> I've made a module named tol() and set it to 0.5 for this example
>
> module tol(t){
>
> # sphere(t);
>
> }
>
> then I place a tolerance sphere at each of the two points I'm
> measuring between
>
> e.g. like
>
> p1=([0,0,10]);
> translate(p1)tol(); // first point
> p2=([54.5,11.2,41.3]);
> translate(p2)tol(); // second point
>
> They are easy to position, one at a time, by positioning x,y from the
> top or bottom view, adjusting the appropriate values in PI or P2, and
> then position z from one of the other views. zooming or rotating the
> view as required.
>
> then the distance can be echoed by something like
>
> module dist(p1,p2){
> dx= p2.x-p1.x;
> dy= p2.y-p1.y;
> dz= p2.z-p2.y;
> l= sqrt((dx*dx) +(dy*dy) +(dz*dz));
> echo(distance = l);
> }
>
> provided the points of interest lie within the tolerance spheres, I
> get the distance between the points within my defined tolerance,. If I
> want a more accurate result, I can reduce the tolerance and zoom in
> closer when positioning the spheres. If the tolerance sphere is too
> small, to see on the full size view, then I could easily place a few
> rings around them, or similar.
>
>
On 18/01/2024 00:20, edmund ronald via Discuss wrote:
> I don't know whether it helps, but I like working in the Edit pane
> typing code. It's just that some things like finding the distance
> between two points, or quickly adjusting a size is a pain. One
> workaround would be to have cursors inside the viewing area, for
> measurement -like on engineering scopes where one places a cursor eg.
> to measure lag- and also be able to slave a parameter in the Edit pane
> to a slider so that one can quickly adjust it while seeing the effect
> in the wireframe. Last and not least there is the thing about the
> extrusion poly lines, but that is truly point and click and a
> different story, I agree.
>
> Edmund
>
J
jon
Thu, Jan 18, 2024 2:45 PM
I really like the approach described below (without attribution).
Thought provoking.
I've simplified my eyeballing technique, distances can be measured
fairly quickly.
I start off by defining the tolerance I'm happy with.
I've made a module named tol() and set it to 0.5 for this example
module tol(t){
# sphere(t);
}
then I place a tolerance sphere at each of the two points I'm
measuring between
e.g. like
p1=([0,0,10]);
translate(p1)tol(); // first point
p2=([54.5,11.2,41.3]);
translate(p2)tol(); // second point
They are easy to position, one at a time, by positioning x,y from the
top or bottom view, adjusting the appropriate values in PI or P2, and
then position z from one of the other views. zooming or rotating
the view as required.
then the distance can be echoed by something like
module dist(p1,p2){
dx= p2.x-p1.x;
dy= p2.y-p1.y;
dz= p2.z-p2.y;
l= sqrt((dxdx) +(dydy) +(dz*dz));
echo(distance = l);
}
provided the points of interest lie within the tolerance spheres, I
get the distance between the points within my defined tolerance,. If
I want a more accurate result, I can reduce the tolerance and zoom in
closer when positioning the spheres. If the tolerance sphere is too
small, to see on the full size view, then I could easily place a few
rings around them, or similar.
I really like the approach described below (without attribution).
Thought provoking.
>> I've simplified my eyeballing technique, distances can be measured
>> fairly quickly.
>>
>> I start off by defining the tolerance I'm happy with.
>>
>> I've made a module named tol() and set it to 0.5 for this example
>>
>> module tol(t){
>>
>> # sphere(t);
>>
>> }
>>
>> then I place a tolerance sphere at each of the two points I'm
>> measuring between
>>
>> e.g. like
>>
>> p1=([0,0,10]);
>> translate(p1)tol(); // first point
>> p2=([54.5,11.2,41.3]);
>> translate(p2)tol(); // second point
>>
>> They are easy to position, one at a time, by positioning x,y from the
>> top or bottom view, adjusting the appropriate values in PI or P2, and
>> then position z from one of the other views. zooming or rotating
>> the view as required.
>>
>> then the distance can be echoed by something like
>>
>> module dist(p1,p2){
>> dx= p2.x-p1.x;
>> dy= p2.y-p1.y;
>> dz= p2.z-p2.y;
>> l= sqrt((dx*dx) +(dy*dy) +(dz*dz));
>> echo(distance = l);
>> }
>>
>> provided the points of interest lie within the tolerance spheres, I
>> get the distance between the points within my defined tolerance,. If
>> I want a more accurate result, I can reduce the tolerance and zoom in
>> closer when positioning the spheres. If the tolerance sphere is too
>> small, to see on the full size view, then I could easily place a few
>> rings around them, or similar.
>>
>>
SL
Steve Lelievre
Thu, Jan 18, 2024 6:35 PM
Yes, I like that trick. And, using the alt/arrow feature* makes it very
easy to position of the tolerance spheres exactly where you want them
based on what you see in the preview area.
In fact, come to think of it, perhaps alt/arrow already provides a
reasonable/adequate alternative to the click-and-dragging of vertices or
objects associated with a more interactive interface?
Steve
On 2024-01-18 6:45 a.m., jon via Discuss wrote:
I really like the approach described below (without attribution).
Thought provoking.
I've simplified my eyeballing technique, distances can be measured
fairly quickly.
I start off by defining the tolerance I'm happy with.
I've made a module named tol() and set it to 0.5 for this example
module tol(t){
# sphere(t);
}
then I place a tolerance sphere at each of the two points I'm
measuring between
e.g. like
p1=([0,0,10]);
translate(p1)tol(); // first point
p2=([54.5,11.2,41.3]);
translate(p2)tol(); // second point
They are easy to position, one at a time, by positioning x,y from
the top or bottom view, adjusting the appropriate values in PI or
P2, and then position z from one of the other views. zooming or
rotating the view as required.
then the distance can be echoed by something like
module dist(p1,p2){
dx= p2.x-p1.x;
dy= p2.y-p1.y;
dz= p2.z-p2.y;
l= sqrt((dxdx) +(dydy) +(dz*dz));
echo(distance = l);
}
provided the points of interest lie within the tolerance spheres, I
get the distance between the points within my defined tolerance,. If
I want a more accurate result, I can reduce the tolerance and zoom
in closer when positioning the spheres. If the tolerance sphere is
too small, to see on the full size view, then I could easily place
a few rings around them, or similar.
Yes, I like that trick. And, using the alt/arrow feature* makes it very
easy to position of the tolerance spheres exactly where you want them
based on what you see in the preview area.
In fact, come to think of it, perhaps alt/arrow already provides a
reasonable/adequate alternative to the click-and-dragging of vertices or
objects associated with a more interactive interface?
Steve
* =
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/The_OpenSCAD_User_Interface#Interactive_modification_of_the_numerical_value
On 2024-01-18 6:45 a.m., jon via Discuss wrote:
>
> I really like the approach described below (without attribution).
> Thought provoking.
>
>>> I've simplified my eyeballing technique, distances can be measured
>>> fairly quickly.
>>>
>>> I start off by defining the tolerance I'm happy with.
>>>
>>> I've made a module named tol() and set it to 0.5 for this example
>>>
>>> module tol(t){
>>>
>>> # sphere(t);
>>>
>>> }
>>>
>>> then I place a tolerance sphere at each of the two points I'm
>>> measuring between
>>>
>>> e.g. like
>>>
>>> p1=([0,0,10]);
>>> translate(p1)tol(); // first point
>>> p2=([54.5,11.2,41.3]);
>>> translate(p2)tol(); // second point
>>>
>>> They are easy to position, one at a time, by positioning x,y from
>>> the top or bottom view, adjusting the appropriate values in PI or
>>> P2, and then position z from one of the other views. zooming or
>>> rotating the view as required.
>>>
>>> then the distance can be echoed by something like
>>>
>>> module dist(p1,p2){
>>> dx= p2.x-p1.x;
>>> dy= p2.y-p1.y;
>>> dz= p2.z-p2.y;
>>> l= sqrt((dx*dx) +(dy*dy) +(dz*dz));
>>> echo(distance = l);
>>> }
>>>
>>> provided the points of interest lie within the tolerance spheres, I
>>> get the distance between the points within my defined tolerance,. If
>>> I want a more accurate result, I can reduce the tolerance and zoom
>>> in closer when positioning the spheres. If the tolerance sphere is
>>> too small, to see on the full size view, then I could easily place
>>> a few rings around them, or similar.
>>>
>>>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
https://www.gnomoni.ca
https://www.youtube.com/@gnomonica
JB
Jordan Brown
Thu, Jan 18, 2024 7:37 PM
On 1/18/2024 3:22 AM, Rogier Wolff wrote:
On Thu, Jan 18, 2024 at 12:11:45PM +0100, Rogier Wolff via Discuss wrote:
If you keep a "default distance from the camera", then that is the
place to put new objects. The user is responsible for turning the
viewpoint and positioning the new objects to the correct 3D position.
A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
right" button would be very useful to prevent unwanted movement on the
line that was just correctly positioned.
I'm now realizing that at first I was thinking: just put the object at
the origin. Now I'm thinking at the default distance from the current
view-point in the middle of the screen. That's implementation details
the implementer has to think about and implement whatever they think
is best.
But your example seemed to have it inserting the new object into the
right context in the program, which isn't the same thing as inserting it
at the origin (or at any point readily derivable from the view window).
On 1/18/2024 3:22 AM, Rogier Wolff wrote:
> On Thu, Jan 18, 2024 at 12:11:45PM +0100, Rogier Wolff via Discuss wrote:
>> If you keep a "default distance from the camera", then that is the
>> place to put new objects. The user is responsible for turning the
>> viewpoint and positioning the new objects to the correct 3D position.
>> A "rotate viewpoint 90 degrees left" and "rotate viewpoint 90 degrees
>> right" button would be very useful to prevent unwanted movement on the
>> line that was just correctly positioned.
> I'm now realizing that at first I was thinking: just put the object at
> the origin. Now I'm thinking at the default distance from the current
> view-point in the middle of the screen. That's implementation details
> the implementer has to think about and implement whatever they think
> is best.
>
But your example seemed to have it inserting the new object into the
right context in the program, which isn't the same thing as inserting it
at the origin (or at any point readily derivable from the view window).
