NH
nop head
Sun, Aug 29, 2021 11:08 AM
Yes I nearly always model all the parts in the assembly to get my printed
parts to interface with them. I can see in the preview if things fit or
clash and never know the actual dimensions. If I need to know a dimension I
examine the STL with Netfabb studio.
On Sun, 29 Aug 2021 at 11:38, Rob Ward rl.ward@bigpond.com wrote:
Getting back on track, it took me a while to grasp the idea that the
programming part of Open SCAD is just an elaborate script producing
interface, and when the programming side of it finishes, the scripts that
are produced, are forwarded to the graphics engine to create the 3-D model.
The programs and the rendering do not run simultaneously. The first cannot
communicate with the second. So the program is not in the position to
access geometric dimensions that are then produced and rendered afterwards.
Producing a script that maps the transformation of the graphical objects
before they are calculated through the CSG Tree is in fact running a
parallel universe that involves far more effort for any degree of
complexity for my designs than I believe it is worth. Is this frustrating?
Yes. Is it trivial solving this problem? No.
The penny dropped when I understood the significance of:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL... in the console.
The "CSG Tree" becomes a static list of graphical transformations. I
calmed down substantially when I got it. So while it may seem the addition
of the "ruler" idea would be easy (given all the other amazing stuff
OpenSACD allows us to do), it will take a very crafty programmer to do it
in the first place, and really crafty one to retain compatibility with the
existing processes. So I listen to the experts on how they "work around"
this issue, the quality of their work attests to the fact they know what
they are doing.
My simple approach is to usually draw in any critical extras (eg bolts,
bearings axles etc) my creation has to work with, or position easily
"checkable chunks" of known dimensions, to test my model with and then
remove them when the final model is created. This will not be convenient
for all situations but there other really good ideas that have helped
others.
Rob
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Yes I nearly always model all the parts in the assembly to get my printed
parts to interface with them. I can see in the preview if things fit or
clash and never know the actual dimensions. If I need to know a dimension I
examine the STL with Netfabb studio.
On Sun, 29 Aug 2021 at 11:38, Rob Ward <rl.ward@bigpond.com> wrote:
> Getting back on track, it took me a while to grasp the idea that the
> programming part of Open SCAD is just an elaborate script producing
> interface, and when the programming side of it finishes, the scripts that
> are produced, are forwarded to the graphics engine to create the 3-D model.
> The programs and the rendering do not run simultaneously. The first cannot
> communicate with the second. So the program is not in the position to
> access geometric dimensions that are then produced and rendered afterwards.
>
> Producing a script that maps the transformation of the graphical objects
> before they are calculated through the CSG Tree is in fact running a
> parallel universe that involves far more effort for any degree of
> complexity for my designs than I believe it is worth. Is this frustrating?
> Yes. Is it trivial solving this problem? No.
>
> The penny dropped when I understood the significance of:
>
> Compiling design (CSG Tree generation)...
>
> Rendering Polygon Mesh using CGAL... in the console.
>
>
> The "CSG Tree" becomes a static list of graphical transformations. I
> calmed down substantially when I got it. So while it may seem the addition
> of the "ruler" idea would be easy (given all the other amazing stuff
> OpenSACD allows us to do), it will take a very crafty programmer to do it
> in the first place, and really crafty one to retain compatibility with the
> existing processes. So I listen to the experts on how they "work around"
> this issue, the quality of their work attests to the fact they know what
> they are doing.
>
>
> My simple approach is to usually draw in any critical extras (eg bolts,
> bearings axles etc) my creation has to work with, or position easily
> "checkable chunks" of known dimensions, to test my model with and then
> remove them when the final model is created. This will not be convenient
> for all situations but there other really good ideas that have helped
> others.
>
>
> Rob
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
AM
Adrian Mariano
Sun, Aug 29, 2021 11:57 AM
Gene,
I suggest that you revisit PrusaSlicer. Just print some simple calibration
test object with the default parameters and see if it comes out better
compared to the same print on Prusa---that won't require a deep
understanding of PrusaSlicer. I wonder if you can resolve most, if not all
of your problems by switching to PrusaSlicer and using the profiles that
are specifically built to work with the MK3S.
On Sun, Aug 29, 2021 at 7:10 AM nop head nop.head@gmail.com wrote:
Yes I nearly always model all the parts in the assembly to get my printed
parts to interface with them. I can see in the preview if things fit or
clash and never know the actual dimensions. If I need to know a dimension I
examine the STL with Netfabb studio.
On Sun, 29 Aug 2021 at 11:38, Rob Ward rl.ward@bigpond.com wrote:
Getting back on track, it took me a while to grasp the idea that the
programming part of Open SCAD is just an elaborate script producing
interface, and when the programming side of it finishes, the scripts that
are produced, are forwarded to the graphics engine to create the 3-D model.
The programs and the rendering do not run simultaneously. The first cannot
communicate with the second. So the program is not in the position to
access geometric dimensions that are then produced and rendered afterwards.
Producing a script that maps the transformation of the graphical objects
before they are calculated through the CSG Tree is in fact running a
parallel universe that involves far more effort for any degree of
complexity for my designs than I believe it is worth. Is this frustrating?
Yes. Is it trivial solving this problem? No.
The penny dropped when I understood the significance of:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL... in the console.
The "CSG Tree" becomes a static list of graphical transformations. I
calmed down substantially when I got it. So while it may seem the addition
of the "ruler" idea would be easy (given all the other amazing stuff
OpenSACD allows us to do), it will take a very crafty programmer to do it
in the first place, and really crafty one to retain compatibility with the
existing processes. So I listen to the experts on how they "work around"
this issue, the quality of their work attests to the fact they know what
they are doing.
My simple approach is to usually draw in any critical extras (eg bolts,
bearings axles etc) my creation has to work with, or position easily
"checkable chunks" of known dimensions, to test my model with and then
remove them when the final model is created. This will not be convenient
for all situations but there other really good ideas that have helped
others.
Rob
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Gene,
I suggest that you revisit PrusaSlicer. Just print some simple calibration
test object with the default parameters and see if it comes out better
compared to the same print on Prusa---that won't require a deep
understanding of PrusaSlicer. I wonder if you can resolve most, if not all
of your problems by switching to PrusaSlicer and using the profiles that
are specifically built to work with the MK3S.
On Sun, Aug 29, 2021 at 7:10 AM nop head <nop.head@gmail.com> wrote:
> Yes I nearly always model all the parts in the assembly to get my printed
> parts to interface with them. I can see in the preview if things fit or
> clash and never know the actual dimensions. If I need to know a dimension I
> examine the STL with Netfabb studio.
>
> On Sun, 29 Aug 2021 at 11:38, Rob Ward <rl.ward@bigpond.com> wrote:
>
>> Getting back on track, it took me a while to grasp the idea that the
>> programming part of Open SCAD is just an elaborate script producing
>> interface, and when the programming side of it finishes, the scripts that
>> are produced, are forwarded to the graphics engine to create the 3-D model.
>> The programs and the rendering do not run simultaneously. The first cannot
>> communicate with the second. So the program is not in the position to
>> access geometric dimensions that are then produced and rendered afterwards.
>>
>> Producing a script that maps the transformation of the graphical objects
>> before they are calculated through the CSG Tree is in fact running a
>> parallel universe that involves far more effort for any degree of
>> complexity for my designs than I believe it is worth. Is this frustrating?
>> Yes. Is it trivial solving this problem? No.
>>
>> The penny dropped when I understood the significance of:
>>
>> Compiling design (CSG Tree generation)...
>>
>> Rendering Polygon Mesh using CGAL... in the console.
>>
>>
>> The "CSG Tree" becomes a static list of graphical transformations. I
>> calmed down substantially when I got it. So while it may seem the addition
>> of the "ruler" idea would be easy (given all the other amazing stuff
>> OpenSACD allows us to do), it will take a very crafty programmer to do it
>> in the first place, and really crafty one to retain compatibility with the
>> existing processes. So I listen to the experts on how they "work around"
>> this issue, the quality of their work attests to the fact they know what
>> they are doing.
>>
>>
>> My simple approach is to usually draw in any critical extras (eg bolts,
>> bearings axles etc) my creation has to work with, or position easily
>> "checkable chunks" of known dimensions, to test my model with and then
>> remove them when the final model is created. This will not be convenient
>> for all situations but there other really good ideas that have helped
>> others.
>>
>>
>> Rob
>>
>>
>> _______________________________________________
>> 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
Ray West
Sun, Aug 29, 2021 12:29 PM
Hi Gene,
In Cura, load the extensions for 'parts for calibration' , go through
each process to set up your printer correctly to work with your slicer
and filament. In reality, you may need to run the tests every time you
change your filament. This stuff is not the same as cast iron/steel
milling machines, is is flimsy aluminium and plastic, generally built
down to a price (but with a high profit margin and a load of hype). If
you keep taking the same steps, you'll end up in the same place. Prusa
has a good support network, or so I'm led to believe, I would hope they
will guide you better on printing problems.
Best wishes,
Ray
On 29/08/2021 09:08, Gene Heskett wrote:
I expect dimmensional accuracy to generally print at about the target
move plus the nozzle dia, and generally write my code to be .2mm approx
undersized on each edge to come out with a decent press fit where parts
come together. Currently that value seems to be closer to .3 than .2.
for a .2mm layer, indicating over extrusion.
Thanks.
[...]
Cheers, Gene Heskett
Hi Gene,
In Cura, load the extensions for 'parts for calibration' , go through
each process to set up your printer correctly to work with your slicer
and filament. In reality, you may need to run the tests every time you
change your filament. This stuff is not the same as cast iron/steel
milling machines, is is flimsy aluminium and plastic, generally built
down to a price (but with a high profit margin and a load of hype). If
you keep taking the same steps, you'll end up in the same place. Prusa
has a good support network, or so I'm led to believe, I would hope they
will guide you better on printing problems.
Best wishes,
Ray
On 29/08/2021 09:08, Gene Heskett wrote:
> I expect dimmensional accuracy to generally print at about the target
> move plus the nozzle dia, and generally write my code to be .2mm approx
> undersized on each edge to come out with a decent press fit where parts
> come together. Currently that value seems to be closer to .3 than .2.
> for a .2mm layer, indicating over extrusion.
>
> Thanks.
> [...]
>
> Cheers, Gene Heskett
JB
Jordan Brown
Sun, Aug 29, 2021 12:39 PM
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and get
information about that object. How possible would it be to click on an
object - probably on a vertex - and get its coordinates? Or to drag a
ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it would
be a feature of the OpenSCAD model viewer. (That also means that it
would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable from
the language.)
I haven't looked at the viewer at all; before I do has somebody already
thought about this aspect?
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and get
information about that object. How possible would it be to click on an
object - probably on a vertex - and get its coordinates? Or to drag a
ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it would
be a feature of the OpenSCAD model viewer. (That also means that it
would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable from
the language.)
I haven't looked at the viewer at all; before I do has somebody already
thought about this aspect?
RW
Ray West
Sun, Aug 29, 2021 1:44 PM
Hi Michael,
On 28/08/2021 14:25, Michael Möller 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.
I can't quite envisage this. Any chance you could show a simple example?
So far, for measuring I sort of developed a digital caliper, but it is
easier for me to simply use a cube, and eyeball its fit, but so far I'm
not aiming at more precision than I can achieve by 'whittling' the final
object.
I've put some code below, to show the sort of thing I do. So, given the
two cones, what do you do?
// distance between two random points
$fn=50; // select two points (tips of cones, say)
cylinder(h=10, d1=10, d2=0);
translate([50,20,40])rotate([80,40,20])cylinder(h=10, d1=10, d2=0);
// fit a cube between points
//#cube([55,20,40]);// first try
translate([0,0,10])cube([xd,yd,zd]); // final cube posn. by trial and
error.
xd=54.5;
yd=11.3;
zd=31.3;
/*
and then need to calculate the diagonal
so diagonal of base (db) = sqrt((xdxd)+(ydyd))
so diagonal = sqrt((dbdb)+(zdzd))
*/
db = sqrt((xdxd)+(ydyd));
diagonal = sqrt((dbdb)+(zdzd));
#translate([0,-10,0])text(text= str("distance between points = ",
diagonal),size=3);
// that's it
Hi Michael,
On 28/08/2021 14:25, Michael Möller 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.
I can't quite envisage this. Any chance you could show a simple example?
So far, for measuring I sort of developed a digital caliper, but it is
easier for me to simply use a cube, and eyeball its fit, but so far I'm
not aiming at more precision than I can achieve by 'whittling' the final
object.
I've put some code below, to show the sort of thing I do. So, given the
two cones, what do you do?
// distance between two random points
$fn=50; // select two points (tips of cones, say)
cylinder(h=10, d1=10, d2=0);
translate([50,20,40])rotate([80,40,20])cylinder(h=10, d1=10, d2=0);
// fit a cube between points
//#cube([55,20,40]);// first try
# translate([0,0,10])cube([xd,yd,zd]); // final cube posn. by trial and
error.
xd=54.5;
yd=11.3;
zd=31.3;
/*
and then need to calculate the diagonal
so diagonal of base (db) = sqrt((xd*xd)+(yd*yd))
so diagonal = sqrt((db*db)+(zd*zd))
*/
db = sqrt((xd*xd)+(yd*yd));
diagonal = sqrt((db*db)+(zd*zd));
#translate([0,-10,0])text(text= str("distance between points = ",
diagonal),size=3);
// that's it
RW
Rob Ward
Sun, Aug 29, 2021 1:50 PM
Isn't the triangles, and their associated vertices potentially ambiguous once the complexities increase. For example a cylinder is no longer a pure geometric shape but a collection of triangles, the number of which depends on $fn and the concept of a tangent to the digitised cylinder no longer is simple? So as to measure a diameter, Tanger to tangent? If we come back to picking the vertices "by eye" what have we achieved that is better than "fit by inspection" to put roughly what I do?
Cheers, RobW
On 29 August 2021 10:39:16 pm AEST, Jordan Brown openscad@jordan.maileater.net wrote:
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and get
information about that object. How possible would it be to click on an
object - probably on a vertex - and get its coordinates? Or to drag a
ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it would
be a feature of the OpenSCAD model viewer. (That also means that it
would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable from
the language.)
I haven't looked at the viewer at all; before I do has somebody already
thought about this aspect?
Isn't the triangles, and their associated vertices potentially ambiguous once the complexities increase. For example a cylinder is no longer a pure geometric shape but a collection of triangles, the number of which depends on $fn and the concept of a tangent to the digitised cylinder no longer is simple? So as to measure a diameter, Tanger to tangent? If we come back to picking the vertices "by eye" what have we achieved that is better than "fit by inspection" to put roughly what I do?
Cheers, RobW
On 29 August 2021 10:39:16 pm AEST, Jordan Brown <openscad@jordan.maileater.net> wrote:
>Hmm.
>
>Most of the discussions on this topic are program-centric: "How can I
>find out where I am?". As discussed, that's difficult and limited at best.
>
>But has anybody given any thought to attacking it from a UI
>perspective? We have mechanisms that let you click on an object and get
>information about that object. How possible would it be to click on an
>object - probably on a vertex - and get its coordinates? Or to drag a
>ruler from it to another vertex?
>
>This would not be a feature of the OpenSCAD language. Rather, it would
>be a feature of the OpenSCAD model viewer. (That also means that it
>would be useful on imported STLs and on the results of boolean
>operations, both of which yield vertices that are not identifiable from
>the language.)
>
>I haven't looked at the viewer at all; before I do has somebody already
>thought about this aspect?
RW
Ray West
Sun, Aug 29, 2021 1:57 PM
I suppose, if another set of '3d cross hairs can not be generated and
moved known distances, the whole drawing could be translated so that the
point of interest was at the origin, but that again is eyeballing it,
but zooming in can get it good enough for many applications.
On 29/08/2021 13:39, Jordan Brown wrote:
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at
best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and
get information about that object. How possible would it be to click
on an object - probably on a vertex - and get its coordinates? Or to
drag a ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it
would be a feature of the OpenSCAD model viewer. (That also means
that it would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable
from the language.)
I haven't looked at the viewer at all; before I do has somebody
already thought about this aspect?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I suppose, if another set of '3d cross hairs can not be generated and
moved known distances, the whole drawing could be translated so that the
point of interest was at the origin, but that again is eyeballing it,
but zooming in can get it good enough for many applications.
On 29/08/2021 13:39, Jordan Brown wrote:
> Hmm.
>
> Most of the discussions on this topic are program-centric: "How can I
> find out where I am?". As discussed, that's difficult and limited at
> best.
>
> But has anybody given any thought to attacking it from a UI
> perspective? We have mechanisms that let you click on an object and
> get information about that object. How possible would it be to click
> on an object - probably on a vertex - and get its coordinates? Or to
> drag a ruler from it to another vertex?
>
> This would not be a feature of the OpenSCAD language. Rather, it
> would be a feature of the OpenSCAD model viewer. (That also means
> that it would be useful on imported STLs and on the results of boolean
> operations, both of which yield vertices that are not identifiable
> from the language.)
>
> I haven't looked at the viewer at all; before I do has somebody
> already thought about this aspect?
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
AM
Adrian Mariano
Sun, Aug 29, 2021 2:06 PM
I think the proposal was that you have a function that defines the critical
distance. Then you use it when needed. So if you have some complex
computation that determines the location of a screw hole then you put it in
a function and you use it when you need to make the screw hole and also to
make the mating hole in another part. But in your example you know
everything you need to compute the parameters of the cube, so why use trial
and error? Just use the actual points that define the cube. I prefer to
minimize the use of trial and error. I suppose you could embed the
calculation of the cone tips into a function.
On Sun, Aug 29, 2021 at 9:44 AM Ray West raywest@raywest.com wrote:
Hi Michael,
On 28/08/2021 14:25, Michael Möller 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.
I can't quite envisage this. Any chance you could show a simple example?
So far, for measuring I sort of developed a digital caliper, but it is
easier for me to simply use a cube, and eyeball its fit, but so far I'm
not aiming at more precision than I can achieve by 'whittling' the final
object.
I've put some code below, to show the sort of thing I do. So, given the
two cones, what do you do?
// distance between two random points
$fn=50; // select two points (tips of cones, say)
cylinder(h=10, d1=10, d2=0);
translate([50,20,40])rotate([80,40,20])cylinder(h=10, d1=10, d2=0);
// fit a cube between points
//#cube([55,20,40]);// first try
translate([0,0,10])cube([xd,yd,zd]); // final cube posn. by trial and
error.
xd=54.5;
yd=11.3;
zd=31.3;
/*
and then need to calculate the diagonal
so diagonal of base (db) = sqrt((xdxd)+(ydyd))
so diagonal = sqrt((dbdb)+(zdzd))
*/
db = sqrt((xdxd)+(ydyd));
diagonal = sqrt((dbdb)+(zdzd));
#translate([0,-10,0])text(text= str("distance between points = ",
diagonal),size=3);
// that's it
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I think the proposal was that you have a function that defines the critical
distance. Then you use it when needed. So if you have some complex
computation that determines the location of a screw hole then you put it in
a function and you use it when you need to make the screw hole and also to
make the mating hole in another part. But in your example you know
everything you need to compute the parameters of the cube, so why use trial
and error? Just use the actual points that define the cube. I prefer to
minimize the use of trial and error. I suppose you could embed the
calculation of the cone tips into a function.
On Sun, Aug 29, 2021 at 9:44 AM Ray West <raywest@raywest.com> wrote:
> Hi Michael,
>
> On 28/08/2021 14:25, Michael Möller 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.
>
> I can't quite envisage this. Any chance you could show a simple example?
> So far, for measuring I sort of developed a digital caliper, but it is
> easier for me to simply use a cube, and eyeball its fit, but so far I'm
> not aiming at more precision than I can achieve by 'whittling' the final
> object.
>
> I've put some code below, to show the sort of thing I do. So, given the
> two cones, what do you do?
>
>
> // distance between two random points
>
> $fn=50; // select two points (tips of cones, say)
> cylinder(h=10, d1=10, d2=0);
>
> translate([50,20,40])rotate([80,40,20])cylinder(h=10, d1=10, d2=0);
>
> // fit a cube between points
> //#cube([55,20,40]);// first try
>
> # translate([0,0,10])cube([xd,yd,zd]); // final cube posn. by trial and
> error.
>
> xd=54.5;
> yd=11.3;
> zd=31.3;
>
> /*
> and then need to calculate the diagonal
>
> so diagonal of base (db) = sqrt((xd*xd)+(yd*yd))
> so diagonal = sqrt((db*db)+(zd*zd))
> */
>
> db = sqrt((xd*xd)+(yd*yd));
> diagonal = sqrt((db*db)+(zd*zd));
>
> #translate([0,-10,0])text(text= str("distance between points = ",
> diagonal),size=3);
>
> // that's it
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
GH
Gene Heskett
Sun, Aug 29, 2021 2:43 PM
On Sunday 29 August 2021 09:50:50 Rob Ward wrote:
Isn't the triangles, and their associated vertices potentially
ambiguous once the complexities increase. For example a cylinder is no
longer a pure geometric shape but a collection of triangles, the
number of which depends on $fn and the concept of a tangent to the
digitised cylinder no longer is simple? So as to measure a diameter,
Tanger to tangent? If we come back to picking the vertices "by eye"
what have we achieved that is better than "fit by inspection" to put
roughly what I do? Cheers, RobW
I generally do the final fit .1mm or even .05mm at a time, adjusting till
it fits well.
One of my more nagging problems lies in forming the splines for this
drive, two parts use exactly the same code to lay out the triangle whose
sides become the working faces of the spline, but one module does a
rotate([0,0,180]) of that to point the splines or outward. The outward
faceing splines print flawlessly, but the inward ones bridge heavily
from tip to tip. Requires some precise work with a box knife, freshly
broken off and sharp. And macular degeneration is becomeing a problem.
I'm playing with temps and retractions, even speeds, but haven't found
the magic twanger yet, halfway thru this spool of PETG.
As for the Z thickness, I could develop a scale foctor but I'd druther
fix the printer. But one has to understand what it is he is fixing by
first determining the cause. eg Does ironing cause any growth. Many more
questions so first is finding the actual src of the problem. When you
are down the the radius of the nezzle, fix your src, but that isn't a
scale, its an offset, ditto for /some/, but not all of the z growth.And
I'm due to take the air junk off and tighten the nozzle again too.
On 29 August 2021 10:39:16 pm AEST, Jordan Brown
Hmm.
Most of the discussions on this topic are program-centric: "How can
I find out where I am?". As discussed, that's difficult and limited
at best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and
get information about that object. How possible would it be to
click on an object - probably on a vertex - and get its
coordinates? Or to drag a ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it
would be a feature of the OpenSCAD model viewer. (That also means
that it would be useful on imported STLs and on the results of
boolean operations, both of which yield vertices that are not
identifiable from the language.)
I haven't looked at the viewer at all; before I do has somebody
already thought about this aspect?
Take care & Thanks Rod.
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.
On Sunday 29 August 2021 09:50:50 Rob Ward wrote:
> Isn't the triangles, and their associated vertices potentially
> ambiguous once the complexities increase. For example a cylinder is no
> longer a pure geometric shape but a collection of triangles, the
> number of which depends on $fn and the concept of a tangent to the
> digitised cylinder no longer is simple? So as to measure a diameter,
> Tanger to tangent? If we come back to picking the vertices "by eye"
> what have we achieved that is better than "fit by inspection" to put
> roughly what I do? Cheers, RobW
>
I generally do the final fit .1mm or even .05mm at a time, adjusting till
it fits well.
One of my more nagging problems lies in forming the splines for this
drive, two parts use exactly the same code to lay out the triangle whose
sides become the working faces of the spline, but one module does a
rotate([0,0,180]) of that to point the splines or outward. The outward
faceing splines print flawlessly, but the inward ones bridge heavily
from tip to tip. Requires some precise work with a box knife, freshly
broken off and sharp. And macular degeneration is becomeing a problem.
I'm playing with temps and retractions, even speeds, but haven't found
the magic twanger yet, halfway thru this spool of PETG.
As for the Z thickness, I could develop a scale foctor but I'd druther
fix the printer. But one has to understand what it is he is fixing by
first determining the cause. eg Does ironing cause any growth. Many more
questions so first is finding the actual src of the problem. When you
are down the the radius of the nezzle, fix your src, but that isn't a
scale, its an offset, ditto for /some/, but not all of the z growth.And
I'm due to take the air junk off and tighten the nozzle again too.
> On 29 August 2021 10:39:16 pm AEST, Jordan Brown
<openscad@jordan.maileater.net> wrote:
> >Hmm.
> >
> >Most of the discussions on this topic are program-centric: "How can
> > I find out where I am?". As discussed, that's difficult and limited
> > at best.
> >
> >But has anybody given any thought to attacking it from a UI
> >perspective? We have mechanisms that let you click on an object and
> > get information about that object. How possible would it be to
> > click on an object - probably on a vertex - and get its
> > coordinates? Or to drag a ruler from it to another vertex?
> >
> >This would not be a feature of the OpenSCAD language. Rather, it
> > would be a feature of the OpenSCAD model viewer. (That also means
> > that it would be useful on imported STLs and on the results of
> > boolean operations, both of which yield vertices that are not
> > identifiable from the language.)
> >
> >I haven't looked at the viewer at all; before I do has somebody
> > already thought about this aspect?
Take care & Thanks Rod.
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>
BE
Bob Ewart
Sun, Aug 29, 2021 5:48 PM
I've been a programmer for over 60 years, which is probably why I like
OpenSCAD so much. I'm not sure my hands are steady enough to place a
point on the UI.
I would much rather put an echo in the code to find out where I am.
Your discussion
https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates-for-objects-td30377.html
in the forum on Oct 22, 2020 contained code which I've added to my local
library. I will be using it.
You should consider putting it somewhere like on github so everyone can
find it.
Thank you very much
--
Bob
The world is coming to an end! Repent and return those library books!
On 8/29/21 8:39 AM, Jordan Brown wrote:
Hmm.
Most of the discussions on this topic are program-centric: "How can I
find out where I am?". As discussed, that's difficult and limited at
best.
But has anybody given any thought to attacking it from a UI
perspective? We have mechanisms that let you click on an object and
get information about that object. How possible would it be to click
on an object - probably on a vertex - and get its coordinates? Or to
drag a ruler from it to another vertex?
This would not be a feature of the OpenSCAD language. Rather, it
would be a feature of the OpenSCAD model viewer. (That also means
that it would be useful on imported STLs and on the results of boolean
operations, both of which yield vertices that are not identifiable
from the language.)
I haven't looked at the viewer at all; before I do has somebody
already thought about this aspect?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I've been a programmer for over 60 years, which is probably why I like
OpenSCAD so much. I'm not sure my hands are steady enough to place a
point on the UI.
I would much rather put an echo in the code to find out where I am.
Your discussion
<https://forum.openscad.org/Some-thoughts-on-deriving-world-coordinates-for-objects-td30377.html>
in the forum on Oct 22, 2020 contained code which I've added to my local
library. I will be using it.
You should consider putting it somewhere like on github so everyone can
find it.
Thank you very much
--
Bob
The world is coming to an end! Repent and return those library books!
On 8/29/21 8:39 AM, Jordan Brown wrote:
> Hmm.
>
> Most of the discussions on this topic are program-centric: "How can I
> find out where I am?". As discussed, that's difficult and limited at
> best.
>
> But has anybody given any thought to attacking it from a UI
> perspective? We have mechanisms that let you click on an object and
> get information about that object. How possible would it be to click
> on an object - probably on a vertex - and get its coordinates? Or to
> drag a ruler from it to another vertex?
>
> This would not be a feature of the OpenSCAD language. Rather, it
> would be a feature of the OpenSCAD model viewer. (That also means
> that it would be useful on imported STLs and on the results of boolean
> operations, both of which yield vertices that are not identifiable
> from the language.)
>
> I haven't looked at the viewer at all; before I do has somebody
> already thought about this aspect?
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
