AP
Adam Purdie
Tue, Nov 12, 2019 8:33 AM
Adam,
OpenSCAD looks at the OPENSCADPATH environment variable for places to
find libraries.
Jordon,
Since all real objects are 2-manifold I don't see why OpenSCAD needs to be
able to handle non-manifold designs. What advantage is it?
If you want to print two cubes next to each then leave a small gap. They
will then get two separate perimeters. If you want to print two cubes that
are joined overlap them by your printers minimum wall width. Your model
then represents what you want your printer to print. If you export two
cubes sharing an edge who knows what the printer will do? It is much better
to give an error as soon as possible to avoid creating a model that can't
be printed. Yes the printer may print something but it won't match the
physically impossible model.
In answer to the original question. I don't find OpenSCAD limiting for
creating my designs at the moment. What I would like to see is module
literals to match function literals and a dict / record type. That would
tidy up my code.
A faster geometry engine like Carve looks like it would transform OpenSCAD
as a faster union would allow 3D Minkowski to be fast and that would allow
3D rounding to be practical.
On Tue, 12 Nov 2019 at 05:25, Adam Purdie adam@symmetry.ninja wrote:
My suggestions:
- Have a way of integrating custom libraries at the openscad level, i
currently do "import(../../../project/projectfile.scad)" and it's a little
tedious, a basic library path like the Arduino app has would be cool
- make it so exports can retain colours (or colors if you wish) - may
not be feasible for the current export formats
- make the default features overrideable like in normal OO - for example
the default center value is "center=false" it would be really nice to be
able to say something like:
module square($params) {
params[center] = true;
default_square($params)
}
- Create some kinda scheduler for the command line that runs multiple
processes across threads - i currently do this with my own python code and
it saves me heaps of rendering time to use all 12 vcpu's :)
On Tue, 12 Nov 2019 at 15:50, Steven Dick kg4ydw@gmail.com wrote:
Openscad is not a mesh editor. You might be able to do simple things
like fixing round off errors during import (which is an eternal problem
with STLs since every vertex is listed separately for every instance of
every edge) , but fixing problems like holes and intersecting polygons is
the job of a mesh editor like blender or meshlab. Use the right tool for
the right job.
Zero size polygons are similar to round off errors. Some holes and
cracks are not real and are caused by the importer not recognizing two
instances of the same edge due to round off errors, and I can see the
importer fixing these, but a real hole or intersecting faces from a
malformed mesh is much harder to fix.
On Mon, Nov 11, 2019 at 9:38 PM Sarah Cartwright sarah@untamed.zone
wrote:
I'd love the "thrown together" option to display holes, and
intersecting polygons.
Very useful for STL file imports.
Would it be possible to fix intersecting polygons, zero volume polygons
and holes in OpenSCAD's import?
It sounds difficult - but would make including existing models so much
easier.
Thanks @nop head :)
On Tue, 12 Nov 2019 at 18:20, nop head <nop.head@gmail.com> wrote:
> Adam,
> OpenSCAD looks at the OPENSCADPATH environment variable for places to
> find libraries.
>
> Jordon,
>
> Since all real objects are 2-manifold I don't see why OpenSCAD needs to be
> able to handle non-manifold designs. What advantage is it?
>
> If you want to print two cubes next to each then leave a small gap. They
> will then get two separate perimeters. If you want to print two cubes that
> are joined overlap them by your printers minimum wall width. Your model
> then represents what you want your printer to print. If you export two
> cubes sharing an edge who knows what the printer will do? It is much better
> to give an error as soon as possible to avoid creating a model that can't
> be printed. Yes the printer may print something but it won't match the
> physically impossible model.
>
> In answer to the original question. I don't find OpenSCAD limiting for
> creating my designs at the moment. What I would like to see is module
> literals to match function literals and a dict / record type. That would
> tidy up my code.
>
> A faster geometry engine like Carve looks like it would transform OpenSCAD
> as a faster union would allow 3D Minkowski to be fast and that would allow
> 3D rounding to be practical.
>
> On Tue, 12 Nov 2019 at 05:25, Adam Purdie <adam@symmetry.ninja> wrote:
>
>>
>> My suggestions:
>> 1. Have a way of integrating custom libraries at the openscad level, i
>> currently do "import(../../../project/projectfile.scad)" and it's a little
>> tedious, a basic library path like the Arduino app has would be cool
>> 2. make it so exports can retain colours (or colors if you wish) - may
>> not be feasible for the current export formats
>> 3. make the default features overrideable like in normal OO - for example
>> the default center value is "center=false" it would be really nice to be
>> able to say something like:
>> module square($params) {
>> params[center] = true;
>> default_square($params)
>> }
>> 4. Create some kinda scheduler for the command line that runs multiple
>> processes across threads - i currently do this with my own python code and
>> it saves me heaps of rendering time to use all 12 vcpu's :)
>>
>> On Tue, 12 Nov 2019 at 15:50, Steven Dick <kg4ydw@gmail.com> wrote:
>>
>>> Openscad is not a mesh editor. You might be able to do simple things
>>> like fixing round off errors during import (which is an eternal problem
>>> with STLs since every vertex is listed separately for every instance of
>>> every edge) , but fixing problems like holes and intersecting polygons is
>>> the job of a mesh editor like blender or meshlab. Use the right tool for
>>> the right job.
>>>
>>> Zero size polygons are similar to round off errors. Some holes and
>>> cracks are not real and are caused by the importer not recognizing two
>>> instances of the same edge due to round off errors, and I can see the
>>> importer fixing these, but a real hole or intersecting faces from a
>>> malformed mesh is much harder to fix.
>>>
>>> On Mon, Nov 11, 2019 at 9:38 PM Sarah Cartwright <sarah@untamed.zone>
>>> wrote:
>>>
>>>>
>>>> I'd love the "thrown together" option to display holes, and
>>>> intersecting polygons.
>>>> Very useful for STL file imports.
>>>>
>>>> Would it be possible to fix intersecting polygons, zero volume polygons
>>>> and holes in OpenSCAD's import?
>>>> It sounds difficult - but would make including existing models so much
>>>> easier.
>>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DE
David Eccles (gringer)
Tue, Nov 12, 2019 10:27 AM
#3 [Addition of new features]
I'd like to see a function that returns the points that would be encoded in
a rendered version of its children. For 2D objects, this would return a
[2Dpoints, paths] result; for 3D objects a [3Dpoints, faces] result, as used
in the polygon & polyhedron functions respectively.
Assuming this function were called "points", then
"polygon(points(2Dconstruction))" should produce an identical result to
"render(2Dconstruction)", and likewise "polyhedron(points(3Dconstruction))"
should produce an identical result to render(3Dconstruction).
Such a function would substantially simplify the code required for extruding
an arbitrarily complex 2D object along a path, implementing a 3D offset /
inset, and probably a lot of other things.
--
Sent from: http://forum.openscad.org/
#3 [Addition of new features]
I'd like to see a function that returns the points that would be encoded in
a rendered version of its children. For 2D objects, this would return a
[2Dpoints, paths] result; for 3D objects a [3Dpoints, faces] result, as used
in the polygon & polyhedron functions respectively.
Assuming this function were called "points", then
"polygon(points(2Dconstruction))" should produce an identical result to
"render(2Dconstruction)", and likewise "polyhedron(points(3Dconstruction))"
should produce an identical result to render(3Dconstruction).
Such a function would substantially simplify the code required for extruding
an arbitrarily complex 2D object along a path, implementing a 3D offset /
inset, and probably a lot of other things.
--
Sent from: http://forum.openscad.org/
NH
nop head
Tue, Nov 12, 2019 11:30 AM
There is already a PR for extruding arbitrary 2D objects along a path,
without needing to get at the coordinates. You can also do 3D inset with
Minkowski, the only problem being it is very slow in CGAL.
On Tue, 12 Nov 2019 at 10:15, David Eccles (gringer) <
bioinformatics@gringene.org> wrote:
#3 [Addition of new features]
I'd like to see a function that returns the points that would be encoded in
a rendered version of its children. For 2D objects, this would return a
[2Dpoints, paths] result; for 3D objects a [3Dpoints, faces] result, as
used
in the polygon & polyhedron functions respectively.
Assuming this function were called "points", then
"polygon(points(2Dconstruction))" should produce an identical result to
"render(2Dconstruction)", and likewise "polyhedron(points(3Dconstruction))"
should produce an identical result to render(3Dconstruction).
Such a function would substantially simplify the code required for
extruding
an arbitrarily complex 2D object along a path, implementing a 3D offset /
inset, and probably a lot of other things.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
There is already a PR for extruding arbitrary 2D objects along a path,
without needing to get at the coordinates. You can also do 3D inset with
Minkowski, the only problem being it is very slow in CGAL.
On Tue, 12 Nov 2019 at 10:15, David Eccles (gringer) <
bioinformatics@gringene.org> wrote:
> #3 [Addition of new features]
>
> I'd like to see a function that returns the points that would be encoded in
> a rendered version of its children. For 2D objects, this would return a
> [2Dpoints, paths] result; for 3D objects a [3Dpoints, faces] result, as
> used
> in the polygon & polyhedron functions respectively.
>
> Assuming this function were called "points", then
> "polygon(points(2Dconstruction))" should produce an identical result to
> "render(2Dconstruction)", and likewise "polyhedron(points(3Dconstruction))"
> should produce an identical result to render(3Dconstruction).
>
> Such a function would substantially simplify the code required for
> extruding
> an arbitrarily complex 2D object along a path, implementing a 3D offset /
> inset, and probably a lot of other things.
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
P
Parkinbot
Tue, Nov 12, 2019 12:26 PM
Besides namespaces and at least a shift to OOP (overloading of modules and
functions, classes instead of use-files) I would like to see some means to
documentation and reflection in OpenSCAD.
-
the current snapshot has some sort of code complete for built-in
keywords. This could be extended to all modules, functions, variables
visible with respect to the scope. I think especially getting hints about
the signatures of modules and functions defined in libraries would be very
useful and avoid many of the new warnings about wrong parameters typos and
so on.
-
syntax for including a help system e.g.
a) //* myfunction() - this is the documentation of myfunction with HTML
allowed *//
b) help ("myfunction", "myfile.scad") to output documentation in the
console window. An attribute like "showcode=true" could also list the
definition of myfunction()
-
links to source code in warnings and errors
-
expected signatures of malused functions and modules in warnings and
errors
--
Sent from: http://forum.openscad.org/
Besides namespaces and at least a shift to OOP (overloading of modules and
functions, classes instead of use-files) I would like to see some means to
documentation and reflection in OpenSCAD.
1. the current snapshot has some sort of code complete for built-in
keywords. This could be extended to all modules, functions, variables
visible with respect to the scope. I think especially getting hints about
the signatures of modules and functions defined in libraries would be very
useful and avoid many of the new warnings about wrong parameters typos and
so on.
2. syntax for including a help system e.g.
a) //* myfunction() - this is the documentation of myfunction with HTML
allowed *//
b) help ("myfunction", "myfile.scad") to output documentation in the
console window. An attribute like "showcode=true" could also list the
definition of myfunction()
3. links to source code in warnings and errors
4. expected signatures of malused functions and modules in warnings and
errors
--
Sent from: http://forum.openscad.org/
JB
Jordan Brown
Tue, Nov 12, 2019 6:31 PM
On 11/11/2019 11:19 PM, nop head wrote:
Since all real objects are 2-manifold I don't see why OpenSCAD needs
to be able to handle non-manifold designs. What advantage is it?
Not having to take care to never allow two objects to touch? Not having
to explain to people what "manifold" means?
(This isn't contrived; I've had real modeling cases where two objects
happened to touch at a single point. I had to figure out what was
happening and then artificially tweak them apart.)
If you want to print two cubes next to each then leave a small gap.
Why? Why should I have to do this, when the intent is obvious?
They will then get two separate perimeters. If you want to print two
cubes that are joined overlap them by your printers minimum wall
width. Your model then represents what you want your printer to
print. If you export two cubes sharing an edge who knows what the
printer will do? It is much better to give an error as soon as
possible to avoid creating a model that can't be printed. Yes the
printer may print something but it won't match the physically
impossible model.
My point is that it doesn't matter what the printer does.
Why is there any practical difference between two cubes that share an
edge, two cubes that are separated by a micrometer, and two cubes that
overlap by a micrometer? The printer's resolution isn't anywhere near
that small. It can't match any of the three, yet the software treats
them all as fundamentally different, and considers two "possible" and
the third "impossible".
When you say "can't be printed", do you mean "that the software can't
handle", or do you mean "where what is printed does not perfectly match
the mathematical model"? If the software can't handle it, that's
exactly the problem I'd like to see solved. If the printed object does
not perfectly match the mathematical model... nothing printed ever
perfectly matches the mathematical model. cube(100) is supposed to
generate a cube 100 units on a side. What gets printed is the result of
mushing together a bunch of cylinders of plastic - the sides aren't
flat, the edges are round instead of right angles, and it's measurably
off 100 units. Printing is always an approximation of the
mathematical model.
On 11/11/2019 11:19 PM, nop head wrote:
> Since all real objects are 2-manifold I don't see why OpenSCAD needs
> to be able to handle non-manifold designs. What advantage is it?
Not having to take care to never allow two objects to touch? Not having
to explain to people what "manifold" means?
(This isn't contrived; I've had real modeling cases where two objects
happened to touch at a single point. I had to figure out what was
happening and then artificially tweak them apart.)
> If you want to print two cubes next to each then leave a small gap.
Why? Why should I have to do this, when the intent is obvious?
> They will then get two separate perimeters. If you want to print two
> cubes that are joined overlap them by your printers minimum wall
> width. Your model then represents what you want your printer to
> print. If you export two cubes sharing an edge who knows what the
> printer will do? It is much better to give an error as soon as
> possible to avoid creating a model that can't be printed. Yes the
> printer may print something but it won't match the physically
> impossible model.
My point is that *it doesn't matter* what the printer does.
Why is there any practical difference between two cubes that share an
edge, two cubes that are separated by a micrometer, and two cubes that
overlap by a micrometer? The printer's resolution isn't anywhere near
that small. It can't match *any* of the three, yet the software treats
them all as fundamentally different, and considers two "possible" and
the third "impossible".
When you say "can't be printed", do you mean "that the software can't
handle", or do you mean "where what is printed does not perfectly match
the mathematical model"? If the software can't handle it, that's
exactly the problem I'd like to see solved. If the printed object does
not perfectly match the mathematical model... *nothing* printed ever
perfectly matches the mathematical model. cube(100) is supposed to
generate a cube 100 units on a side. What gets printed is the result of
mushing together a bunch of cylinders of plastic - the sides aren't
flat, the edges are round instead of right angles, and it's measurably
off 100 units. Printing is *always* an approximation of the
mathematical model.
MB
Max Bond
Tue, Nov 12, 2019 7:11 PM
Another thing I forgot, I'd love it if the GUI had a ruler that could
measure angles and distances
On Tue, Nov 12, 2019, 11:32 AM Jordan Brown openscad@jordan.maileater.net
wrote:
On 11/11/2019 11:19 PM, nop head wrote:
Since all real objects are 2-manifold I don't see why OpenSCAD needs to be
able to handle non-manifold designs. What advantage is it?
Not having to take care to never allow two objects to touch? Not having
to explain to people what "manifold" means?
(This isn't contrived; I've had real modeling cases where two objects
happened to touch at a single point. I had to figure out what was
happening and then artificially tweak them apart.)
If you want to print two cubes next to each then leave a small gap.
Why? Why should I have to do this, when the intent is obvious?
They will then get two separate perimeters. If you want to print two cubes
that are joined overlap them by your printers minimum wall width. Your
model then represents what you want your printer to print. If you export
two cubes sharing an edge who knows what the printer will do? It is much
better to give an error as soon as possible to avoid creating a model that
can't be printed. Yes the printer may print something but it won't match
the physically impossible model.
My point is that it doesn't matter what the printer does.
Why is there any practical difference between two cubes that share an
edge, two cubes that are separated by a micrometer, and two cubes that
overlap by a micrometer? The printer's resolution isn't anywhere near that
small. It can't match any of the three, yet the software treats them all
as fundamentally different, and considers two "possible" and the third
"impossible".
When you say "can't be printed", do you mean "that the software can't
handle", or do you mean "where what is printed does not perfectly match the
mathematical model"? If the software can't handle it, that's exactly the
problem I'd like to see solved. If the printed object does not perfectly
match the mathematical model... nothing printed ever perfectly matches
the mathematical model. cube(100) is supposed to generate a cube 100 units
on a side. What gets printed is the result of mushing together a bunch of
cylinders of plastic - the sides aren't flat, the edges are round instead
of right angles, and it's measurably off 100 units. Printing is always
an approximation of the mathematical model.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Another thing I forgot, I'd love it if the GUI had a ruler that could
measure angles and distances
On Tue, Nov 12, 2019, 11:32 AM Jordan Brown <openscad@jordan.maileater.net>
wrote:
> On 11/11/2019 11:19 PM, nop head wrote:
>
> Since all real objects are 2-manifold I don't see why OpenSCAD needs to be
> able to handle non-manifold designs. What advantage is it?
>
>
> Not having to take care to never allow two objects to touch? Not having
> to explain to people what "manifold" means?
>
> (This isn't contrived; I've had real modeling cases where two objects
> happened to touch at a single point. I had to figure out what was
> happening and then artificially tweak them apart.)
>
> If you want to print two cubes next to each then leave a small gap.
>
>
> Why? Why should I have to do this, when the intent is obvious?
>
> They will then get two separate perimeters. If you want to print two cubes
> that are joined overlap them by your printers minimum wall width. Your
> model then represents what you want your printer to print. If you export
> two cubes sharing an edge who knows what the printer will do? It is much
> better to give an error as soon as possible to avoid creating a model that
> can't be printed. Yes the printer may print something but it won't match
> the physically impossible model.
>
>
> My point is that *it doesn't matter* what the printer does.
>
> Why is there any practical difference between two cubes that share an
> edge, two cubes that are separated by a micrometer, and two cubes that
> overlap by a micrometer? The printer's resolution isn't anywhere near that
> small. It can't match *any* of the three, yet the software treats them all
> as fundamentally different, and considers two "possible" and the third
> "impossible".
>
> When you say "can't be printed", do you mean "that the software can't
> handle", or do you mean "where what is printed does not perfectly match the
> mathematical model"? If the software can't handle it, that's exactly the
> problem I'd like to see solved. If the printed object does not perfectly
> match the mathematical model... *nothing* printed ever perfectly matches
> the mathematical model. cube(100) is supposed to generate a cube 100 units
> on a side. What gets printed is the result of mushing together a bunch of
> cylinders of plastic - the sides aren't flat, the edges are round instead
> of right angles, and it's measurably off 100 units. Printing is *always*
> an approximation of the mathematical model.
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
NH
nop head
Tue, Nov 12, 2019 10:02 PM
My point is that all objects that can be printed are 2 manifold. Therefore
there is no reason why OpenSCAD needs to be able to model objects that
aren't 2-manifold because that can never be a valid design intent.
The fact that a 3D printer never exactly matches a model due to tolerances
is a different thing. My 3D printers always produce manifold objects so it
makes no sense to send them a non-manifold design because no matter how
accurate they are they cannot print it.
Why is there any practical difference between two cubes that share an
edge, two cubes that are separated by a micrometer, and two cubes that
overlap by a micrometer?
Because separate cubes separated by a micrometer is a valid design intent.
When sent to a 3D printer it creates two separate cubes with their own
outlines. Yes most likely they will be weakly bonded but easily separated.
Sending a design with a shared edge is nonsense as it never exists in
reality, only in maths. Sending a design where they overlap by one micron
only make sense on a printer that can produce 1 micron walls. So if they
overlap it should be my much more than that.
So the set of printable objects is ones that have two separate boundaries
plus those that overlap by the minimum feature size. It does not include
the case where they share an edge, so why should OpenSCAD and all the
downstream tools cater for that edge case? Better to tell the user it is an
invalid design intent.
.
On Tue, 12 Nov 2019 at 18:31, Jordan Brown openscad@jordan.maileater.net
wrote:
On 11/11/2019 11:19 PM, nop head wrote:
Since all real objects are 2-manifold I don't see why OpenSCAD needs to be
able to handle non-manifold designs. What advantage is it?
Not having to take care to never allow two objects to touch? Not having
to explain to people what "manifold" means?
(This isn't contrived; I've had real modeling cases where two objects
happened to touch at a single point. I had to figure out what was
happening and then artificially tweak them apart.)
If you want to print two cubes next to each then leave a small gap.
Why? Why should I have to do this, when the intent is obvious?
They will then get two separate perimeters. If you want to print two cubes
that are joined overlap them by your printers minimum wall width. Your
model then represents what you want your printer to print. If you export
two cubes sharing an edge who knows what the printer will do? It is much
better to give an error as soon as possible to avoid creating a model that
can't be printed. Yes the printer may print something but it won't match
the physically impossible model.
My point is that it doesn't matter what the printer does.
Why is there any practical difference between two cubes that share an
edge, two cubes that are separated by a micrometer, and two cubes that
overlap by a micrometer? The printer's resolution isn't anywhere near that
small. It can't match any of the three, yet the software treats them all
as fundamentally different, and considers two "possible" and the third
"impossible".
When you say "can't be printed", do you mean "that the software can't
handle", or do you mean "where what is printed does not perfectly match the
mathematical model"? If the software can't handle it, that's exactly the
problem I'd like to see solved. If the printed object does not perfectly
match the mathematical model... nothing printed ever perfectly matches
the mathematical model. cube(100) is supposed to generate a cube 100 units
on a side. What gets printed is the result of mushing together a bunch of
cylinders of plastic - the sides aren't flat, the edges are round instead
of right angles, and it's measurably off 100 units. Printing is always
an approximation of the mathematical model.
My point is that all objects that can be printed are 2 manifold. Therefore
there is no reason why OpenSCAD needs to be able to model objects that
aren't 2-manifold because that can never be a valid design intent.
The fact that a 3D printer never exactly matches a model due to tolerances
is a different thing. My 3D printers always produce manifold objects so it
makes no sense to send them a non-manifold design because no matter how
accurate they are they cannot print it.
>Why is there any practical difference between two cubes that share an
edge, two cubes that are separated by a micrometer, and two cubes that
overlap by a micrometer?
Because separate cubes separated by a micrometer is a valid design intent.
When sent to a 3D printer it creates two separate cubes with their own
outlines. Yes most likely they will be weakly bonded but easily separated.
Sending a design with a shared edge is nonsense as it never exists in
reality, only in maths. Sending a design where they overlap by one micron
only make sense on a printer that can produce 1 micron walls. So if they
overlap it should be my much more than that.
So the set of printable objects is ones that have two separate boundaries
plus those that overlap by the minimum feature size. It does not include
the case where they share an edge, so why should OpenSCAD and all the
downstream tools cater for that edge case? Better to tell the user it is an
invalid design intent.
.
On Tue, 12 Nov 2019 at 18:31, Jordan Brown <openscad@jordan.maileater.net>
wrote:
> On 11/11/2019 11:19 PM, nop head wrote:
>
> Since all real objects are 2-manifold I don't see why OpenSCAD needs to be
> able to handle non-manifold designs. What advantage is it?
>
>
> Not having to take care to never allow two objects to touch? Not having
> to explain to people what "manifold" means?
>
> (This isn't contrived; I've had real modeling cases where two objects
> happened to touch at a single point. I had to figure out what was
> happening and then artificially tweak them apart.)
>
> If you want to print two cubes next to each then leave a small gap.
>
>
> Why? Why should I have to do this, when the intent is obvious?
>
> They will then get two separate perimeters. If you want to print two cubes
> that are joined overlap them by your printers minimum wall width. Your
> model then represents what you want your printer to print. If you export
> two cubes sharing an edge who knows what the printer will do? It is much
> better to give an error as soon as possible to avoid creating a model that
> can't be printed. Yes the printer may print something but it won't match
> the physically impossible model.
>
>
> My point is that *it doesn't matter* what the printer does.
>
> Why is there any practical difference between two cubes that share an
> edge, two cubes that are separated by a micrometer, and two cubes that
> overlap by a micrometer? The printer's resolution isn't anywhere near that
> small. It can't match *any* of the three, yet the software treats them all
> as fundamentally different, and considers two "possible" and the third
> "impossible".
>
> When you say "can't be printed", do you mean "that the software can't
> handle", or do you mean "where what is printed does not perfectly match the
> mathematical model"? If the software can't handle it, that's exactly the
> problem I'd like to see solved. If the printed object does not perfectly
> match the mathematical model... *nothing* printed ever perfectly matches
> the mathematical model. cube(100) is supposed to generate a cube 100 units
> on a side. What gets printed is the result of mushing together a bunch of
> cylinders of plastic - the sides aren't flat, the edges are round instead
> of right angles, and it's measurably off 100 units. Printing is *always*
> an approximation of the mathematical model.
>
>
JB
Jordan Brown
Tue, Nov 12, 2019 10:50 PM
On 11/12/2019 11:11 AM, Max Bond wrote:
Another thing I forgot, I'd love it if the GUI had a ruler that could
measure angles and distances
I wrote a measuring-stick module. It's not great, but it sort of
works. Note that it sort of autoscales based on the view distance; move
the view to where you like and refresh. You have to position it where
you need it in the model; there's no attempt to support "from <this
place> to <that place> measurements. Rotating and sizing to run it from
a particular [x,y,z] to another [x,y,z] is left as an exercise for the
reader.
$measure = true;
measuringstick(100);
module measuringstick(len, interval=pow(10,floor(log($vpd)-1)), center=false) {
if ($measure) {
r = 0.5;
mark = interval * 0.01;
%translate([0, 0, center ? -len/2 : 0]) {
for (z=[0:interval:len]) {
mark1 = min(len-z, mark/2);
if (mark1 > 0) {
translate([0,0,z]) color("black") cylinder(r=r, h=mark/2);
}
z2 = z + mark1;
block = min(len-z2, interval-mark);
if (block > 0) {
translate([0,0,z2]) cylinder(r=r, h=block);
}
z3 = z2 + block;
mark2 = min(len-z3, mark/2);
if (mark2 > 0) {
translate([0,0,z3]) color("black") cylinder(r=r, h=mark/2);
}
}
}
}
}
On 11/12/2019 11:11 AM, Max Bond wrote:
> Another thing I forgot, I'd love it if the GUI had a ruler that could
> measure angles and distances
>
I wrote a measuring-stick module. It's not great, but it sort of
works. Note that it sort of autoscales based on the view distance; move
the view to where you like and refresh. You have to position it where
you need it in the model; there's no attempt to support "from <this
place> to <that place> measurements. Rotating and sizing to run it from
a particular [x,y,z] to another [x,y,z] is left as an exercise for the
reader.
$measure = true;
measuringstick(100);
module measuringstick(len, interval=pow(10,floor(log($vpd)-1)), center=false) {
if ($measure) {
r = 0.5;
mark = interval * 0.01;
%translate([0, 0, center ? -len/2 : 0]) {
for (z=[0:interval:len]) {
mark1 = min(len-z, mark/2);
if (mark1 > 0) {
translate([0,0,z]) color("black") cylinder(r=r, h=mark/2);
}
z2 = z + mark1;
block = min(len-z2, interval-mark);
if (block > 0) {
translate([0,0,z2]) cylinder(r=r, h=block);
}
z3 = z2 + block;
mark2 = min(len-z3, mark/2);
if (mark2 > 0) {
translate([0,0,z3]) color("black") cylinder(r=r, h=mark/2);
}
}
}
}
}
JB
Jordan Brown
Tue, Nov 12, 2019 11:10 PM
I think we'll need to agree to disagree here.
I think it's inconvenient and awkward, and it's difficult to explain why
shared edges are a problem and how to diagnose and correct them. I know
that it's a problem for me.
It doesn't bother you. OK.
Supposing, hypothetically, that we had somebody who was able to spend
the time to make this case not be an error, is there any reason why they
should not do that work? Is there any way that that flexibility would
impair your ability to do what you want to do?
I think we'll need to agree to disagree here.
I think it's inconvenient and awkward, and it's difficult to explain why
shared edges are a problem and how to diagnose and correct them. I know
that it's a problem for me.
It doesn't bother you. OK.
Supposing, hypothetically, that we had somebody who was able to spend
the time to make this case not be an error, is there any reason why they
*should not* do that work? Is there any way that that flexibility would
impair your ability to do what you want to do?
NH
nop head
Tue, Nov 12, 2019 11:15 PM
It would mean I could accidentally design non-printable object instead of
being told it was non-manifold. Also it would waste developer time changing
OpenSCAD to be able to represents non real objects.
OpenSCAD can't represents objects with more than 3 dimensions, with
dimensions of zero or infinity or imaginary numbers. All of these are
mathematically possible by why spend time extending OpenSCAD to generate
them when they are not physically possible?
On Tue, 12 Nov 2019 at 23:10, Jordan Brown openscad@jordan.maileater.net
wrote:
I think we'll need to agree to disagree here.
I think it's inconvenient and awkward, and it's difficult to explain why
shared edges are a problem and how to diagnose and correct them. I know
that it's a problem for me.
It doesn't bother you. OK.
Supposing, hypothetically, that we had somebody who was able to spend the
time to make this case not be an error, is there any reason why they
should not do that work? Is there any way that that flexibility would
impair your ability to do what you want to do?
It would mean I could accidentally design non-printable object instead of
being told it was non-manifold. Also it would waste developer time changing
OpenSCAD to be able to represents non real objects.
OpenSCAD can't represents objects with more than 3 dimensions, with
dimensions of zero or infinity or imaginary numbers. All of these are
mathematically possible by why spend time extending OpenSCAD to generate
them when they are not physically possible?
On Tue, 12 Nov 2019 at 23:10, Jordan Brown <openscad@jordan.maileater.net>
wrote:
> I think we'll need to agree to disagree here.
>
> I think it's inconvenient and awkward, and it's difficult to explain why
> shared edges are a problem and how to diagnose and correct them. I know
> that it's a problem for me.
>
> It doesn't bother you. OK.
>
> Supposing, hypothetically, that we had somebody who was able to spend the
> time to make this case not be an error, is there any reason why they
> *should not* do that work? Is there any way that that flexibility would
> impair your ability to do what you want to do?
>
>
