JB
Jordan Brown
Wed, Nov 13, 2019 12:11 AM
On 11/12/2019 3:15 PM, nop head wrote:
It would mean I could accidentally design non-printable object instead
of being told it was non-manifold.
Why should OpenSCAD concern itself with printability? If it does,
shouldn't it also reject ludicrously large objects or ludicrously small
ones? Shouldn't it insist that all values be multiples of the print
resolution?
Maybe it's algorithmically impossible to disambiguate triangle-soup
representations that have shared edges. (I don't know one way or
another.) If so, that should prevent exports of such objects to
triangle-soup file formats, but shouldn't prevent it for file formats
where there's no problem.
If your slicer can't handle such an object... then that's on the slicer.
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?
See, what we're disagreeing on is whether the objects being discussed
are physically impossible, within the approximations implicit in 3D
printing, and in the real world at the microscopic and atomic levels.
I contend that for all practical purposes they are possible, and that
they are certainly no more impossible than objects separated by epsilon
or overlapping by epsilon.
I don't remember: were you one of the people who was arguing that
malformed polyhedra (disconnected faces, et cetera) should be allowed?
On 11/12/2019 3:15 PM, nop head wrote:
> It would mean I could accidentally design non-printable object instead
> of being told it was non-manifold.
Why should OpenSCAD concern itself with printability? If it does,
shouldn't it also reject ludicrously large objects or ludicrously small
ones? Shouldn't it insist that all values be multiples of the print
resolution?
Maybe it's algorithmically impossible to disambiguate triangle-soup
representations that have shared edges. (I don't know one way or
another.) If so, that should prevent exports of such objects to
triangle-soup file formats, but shouldn't prevent it for file formats
where there's no problem.
If your slicer can't handle such an object... then that's on the slicer.
> 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?
See, what we're disagreeing on is whether the objects being discussed
are physically impossible, *within the approximations implicit in 3D
printing, and in the real world at the microscopic and atomic levels*.
I contend that for all practical purposes they are possible, and that
they are certainly no more impossible than objects separated by epsilon
or overlapping by epsilon.
I don't remember: were you one of the people who was arguing that
malformed polyhedra (disconnected faces, et cetera) should be allowed?
AP
Adam Purdie
Wed, Nov 13, 2019 12:25 AM
This suggestions thread is being hijacked by this argument, how about
people make suggestions and the OpenSCAD people decide what to include and
we just leave disagreements to Twitter, Facebook and other social media.
On Wed, 13 Nov 2019, 11:12 am Jordan Brown, openscad@jordan.maileater.net
wrote:
On 11/12/2019 3:15 PM, nop head wrote:
It would mean I could accidentally design non-printable object instead of
being told it was non-manifold.
Why should OpenSCAD concern itself with printability? If it does,
shouldn't it also reject ludicrously large objects or ludicrously small
ones? Shouldn't it insist that all values be multiples of the print
resolution?
Maybe it's algorithmically impossible to disambiguate triangle-soup
representations that have shared edges. (I don't know one way or
another.) If so, that should prevent exports of such objects to
triangle-soup file formats, but shouldn't prevent it for file formats where
there's no problem.
If your slicer can't handle such an object... then that's on the slicer.
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?
See, what we're disagreeing on is whether the objects being discussed are
physically impossible, within the approximations implicit in 3D printing,
and in the real world at the microscopic and atomic levels.
I contend that for all practical purposes they are possible, and that they
are certainly no more impossible than objects separated by epsilon or
overlapping by epsilon.
I don't remember: were you one of the people who was arguing that
malformed polyhedra (disconnected faces, et cetera) should be allowed?
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
This suggestions thread is being hijacked by this argument, how about
people make suggestions and the OpenSCAD people decide what to include and
we just leave disagreements to Twitter, Facebook and other social media.
On Wed, 13 Nov 2019, 11:12 am Jordan Brown, <openscad@jordan.maileater.net>
wrote:
> On 11/12/2019 3:15 PM, nop head wrote:
>
> It would mean I could accidentally design non-printable object instead of
> being told it was non-manifold.
>
>
> Why should OpenSCAD concern itself with printability? If it does,
> shouldn't it also reject ludicrously large objects or ludicrously small
> ones? Shouldn't it insist that all values be multiples of the print
> resolution?
>
> Maybe it's algorithmically impossible to disambiguate triangle-soup
> representations that have shared edges. (I don't know one way or
> another.) If so, that should prevent exports of such objects to
> triangle-soup file formats, but shouldn't prevent it for file formats where
> there's no problem.
>
> If your slicer can't handle such an object... then that's on the slicer.
>
> 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?
>
>
> See, what we're disagreeing on is whether the objects being discussed are
> physically impossible, *within the approximations implicit in 3D printing,
> and in the real world at the microscopic and atomic levels*.
>
> I contend that for all practical purposes they are possible, and that they
> are certainly no more impossible than objects separated by epsilon or
> overlapping by epsilon.
>
> I don't remember: were you one of the people who was arguing that
> malformed polyhedra (disconnected faces, et cetera) should be allowed?
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DV
david vanhorn
Wed, Nov 13, 2019 1:26 AM
I'd like to see clipping planes
On Tue, Nov 12, 2019, 5:26 PM Adam Purdie adam@symmetry.ninja wrote:
This suggestions thread is being hijacked by this argument, how about
people make suggestions and the OpenSCAD people decide what to include and
we just leave disagreements to Twitter, Facebook and other social media.
On Wed, 13 Nov 2019, 11:12 am Jordan Brown, openscad@jordan.maileater.net
wrote:
On 11/12/2019 3:15 PM, nop head wrote:
It would mean I could accidentally design non-printable object instead of
being told it was non-manifold.
Why should OpenSCAD concern itself with printability? If it does,
shouldn't it also reject ludicrously large objects or ludicrously small
ones? Shouldn't it insist that all values be multiples of the print
resolution?
Maybe it's algorithmically impossible to disambiguate triangle-soup
representations that have shared edges. (I don't know one way or
another.) If so, that should prevent exports of such objects to
triangle-soup file formats, but shouldn't prevent it for file formats where
there's no problem.
If your slicer can't handle such an object... then that's on the slicer.
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?
See, what we're disagreeing on is whether the objects being discussed are
physically impossible, within the approximations implicit in 3D printing,
and in the real world at the microscopic and atomic levels.
I contend that for all practical purposes they are possible, and that
they are certainly no more impossible than objects separated by epsilon or
overlapping by epsilon.
I don't remember: were you one of the people who was arguing that
malformed polyhedra (disconnected faces, et cetera) should be allowed?
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I'd like to see clipping planes
On Tue, Nov 12, 2019, 5:26 PM Adam Purdie <adam@symmetry.ninja> wrote:
> This suggestions thread is being hijacked by this argument, how about
> people make suggestions and the OpenSCAD people decide what to include and
> we just leave disagreements to Twitter, Facebook and other social media.
>
> On Wed, 13 Nov 2019, 11:12 am Jordan Brown, <openscad@jordan.maileater.net>
> wrote:
>
>> On 11/12/2019 3:15 PM, nop head wrote:
>>
>> It would mean I could accidentally design non-printable object instead of
>> being told it was non-manifold.
>>
>>
>> Why should OpenSCAD concern itself with printability? If it does,
>> shouldn't it also reject ludicrously large objects or ludicrously small
>> ones? Shouldn't it insist that all values be multiples of the print
>> resolution?
>>
>> Maybe it's algorithmically impossible to disambiguate triangle-soup
>> representations that have shared edges. (I don't know one way or
>> another.) If so, that should prevent exports of such objects to
>> triangle-soup file formats, but shouldn't prevent it for file formats where
>> there's no problem.
>>
>> If your slicer can't handle such an object... then that's on the slicer.
>>
>> 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?
>>
>>
>> See, what we're disagreeing on is whether the objects being discussed are
>> physically impossible, *within the approximations implicit in 3D printing,
>> and in the real world at the microscopic and atomic levels*.
>>
>> I contend that for all practical purposes they are possible, and that
>> they are certainly no more impossible than objects separated by epsilon or
>> overlapping by epsilon.
>>
>> I don't remember: were you one of the people who was arguing that
>> malformed polyhedra (disconnected faces, et cetera) should be allowed?
>> _______________________________________________
>> 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
>
DM
Doug Moen
Wed, Nov 13, 2019 1:57 PM
On Tue, Nov 12, 2019, at 12:24 AM, Adam Purdie wrote:
- make it so exports can retain colours (or colors if you wish) - may not be feasible for the current export formats
To do full colour 3D printing, I export my model to either X3D or WRL format (depending on the 3D printing service provider).
Both of these file formats support a mode where you record the colour of each triangle or face (face colouring). This might be the simplest representation for retaining colours in an exported OpenSCAD model, at least without changing the language and switching to a different colour model. You can open one of these coloured models in MeshLab and the colours are displayed. As mentioned, you can 3D print these models in colour with certain types of full colour printers.
In order to implement this in OpenSCAD, you would need to preserve face colours across boolean operations (union, intersection, difference). I think that is possible with CGAL (since all of the algorithms are templated, and generic across data structures). However, it also involves an important change to data structures used throughout OpenSCAD. So it is not a trivial change.
Whether this is even a good idea depends on how you are using colour. Assigning colours to faces is not a good model of dual extruder 3D printing with 2 different types of filament. For the latter, you want to construct a separate mesh for each material/colour and export the mesh set to a 3MF file. So a good question is, what is your application for this?
On Tue, Nov 12, 2019, at 12:24 AM, Adam Purdie wrote:
> 2. make it so exports can retain colours (or colors if you wish) - may not be feasible for the current export formats
To do full colour 3D printing, I export my model to either X3D or WRL format (depending on the 3D printing service provider).
Both of these file formats support a mode where you record the colour of each triangle or face (face colouring). This might be the simplest representation for retaining colours in an exported OpenSCAD model, at least without changing the language and switching to a different colour model. You can open one of these coloured models in MeshLab and the colours are displayed. As mentioned, you can 3D print these models in colour with certain types of full colour printers.
In order to implement this in OpenSCAD, you would need to preserve face colours across boolean operations (union, intersection, difference). I think that is possible with CGAL (since all of the algorithms are templated, and generic across data structures). However, it also involves an important change to data structures used throughout OpenSCAD. So it is not a trivial change.
Whether this is even a good idea depends on how you are using colour. Assigning colours to faces is not a good model of dual extruder 3D printing with 2 different types of filament. For the latter, you want to construct a separate mesh for each material/colour and export the mesh set to a 3MF file. So a good question is, what is your application for this?
L
lar3ry@sasktel.net
Thu, Nov 14, 2019 4:12 PM
On 12 Nov 2019 at 12:11, Max Bond wrote:
Another thing I forgot, I'd love it if the GUI had a ruler that could measure angles and distances
Be still my beating heart! YES!
On 12 Nov 2019 at 12:11, Max Bond wrote:
> Another thing I forgot, I'd love it if the GUI had a ruler that could measure angles and distances
Be still my beating heart! YES!
L
lar3ry
Thu, Nov 14, 2019 5:20 PM
Nice! Thanks! It now lives in my library folder.
--
Sent from: http://forum.openscad.org/
Nice! Thanks! It now lives in my library folder.
--
Sent from: http://forum.openscad.org/
L
lar3ry
Thu, Nov 14, 2019 5:33 PM
The Arduino scheme is such that you do not have to put in the entire path.
For example, in the Arduino IDE, I can have:
#include <stepper.h>
and the actual file loaded is fetched from <OPENSCADPATH >/Stepper/Stepper.h
Adam,
OpenSCAD looks at the OPENSCADPATH environment variable for places to
find libraries.
- 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
The Arduino scheme is such that you do not have to put in the entire path.
For example, in the Arduino IDE, I can have:
#include <stepper.h>
and the actual file loaded is fetched from <OPENSCADPATH >/Stepper/Stepper.h
Adam,
OpenSCAD looks at the OPENSCADPATH environment variable for places to
find libraries.
> 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
--
Sent from: http://forum.openscad.org/
R
Robin2
Thu, Nov 14, 2019 5:46 PM
The Arduino scheme is such that you do not have to put in the entire path.
For example, in the Arduino IDE, I can have:
#include
<stepper.h>
and the actual file loaded is fetched from
<OPENSCADPATH >
/Stepper/Stepper.h
As a regular Arduino user their system has minuses as well as pluses. It is
designed to be effortless for newcomers to programming. But it can get in
the way for more experienced folks. And it requires a very precise system
for locating library code so it can be found by the compiler.
By the way, I am 100% behind any moves to make OpenSCAD effortless for
newcomers.
...R
--
Sent from: http://forum.openscad.org/
lar3ry wrote
> The Arduino scheme is such that you do not have to put in the entire path.
> For example, in the Arduino IDE, I can have:
>
> #include
> <stepper.h>
> and the actual file loaded is fetched from
> <OPENSCADPATH >
> /Stepper/Stepper.h
As a regular Arduino user their system has minuses as well as pluses. It is
designed to be effortless for newcomers to programming. But it can get in
the way for more experienced folks. And it requires a very precise system
for locating library code so it can be found by the compiler.
By the way, I am 100% behind any moves to make OpenSCAD effortless for
newcomers.
...R
--
Sent from: http://forum.openscad.org/
M
macdarren
Thu, Nov 14, 2019 8:41 PM
I would like to see improved handling of imported STL files.
I frequently have an older STL created by someone with way more skill or
more complex software and I want to change it slightly.
I don't expect complex editing, but the other day I had a solid model...it
sliced and multiple programs reported it as clean, even scad viewed it fine.
All I wanted to do was put a small hole in one side....differencing a
cylinder seemed so simple....But nothing I did would allow that to render
and export. I ended up having to learn just enough about some other
modeling program to cut the hole then re-export the STL for printing.
SCAD just spewed random errors...the preview sometimes looked okay but there
was just no rendering...I tried all sorts of variations and different
versions of scad and 'cleaned' versions of the STL without success.
--
Sent from: http://forum.openscad.org/
I would like to see improved handling of imported STL files.
I frequently have an older STL created by someone with way more skill or
more complex software and I want to change it slightly.
I don't expect complex editing, but the other day I had a solid model...it
sliced and multiple programs reported it as clean, even scad viewed it fine.
All I wanted to do was put a small hole in one side....differencing a
cylinder seemed so simple....But nothing I did would allow that to render
and export. I ended up having to learn just enough about some other
modeling program to cut the hole then re-export the STL for printing.
SCAD just spewed random errors...the preview sometimes looked okay but there
was just no rendering...I tried all sorts of variations and different
versions of scad and 'cleaned' versions of the STL without success.
--
Sent from: http://forum.openscad.org/
WC
W. Craig Trader
Mon, Nov 18, 2019 2:00 AM
I'm a little late, but I'd still like to add my thoughts.
On Sat, Nov 9, 2019 at 5:23 PM Hans L thehans@gmail.com wrote:
I wanted to get some input and have a bit of discussion from users here,
regarding what they would most like to see from current or near-future
OpenSCAD development.
What do you feel is the most important aspect to focus on, or would have
the biggest impact to your experience using OpenSCAD:
- Stability, squash more bugs in general
- Optimize existing code, make OpenSCAD faster
- Addition of new features
- More / improved documentation
- All of the above should be balanced equally
- Nothing, I am content
- Something else not mentioned
I'm a software engineer by trade, and model designer by hobby. OpenSCAD is
my go-to tool for modeling. I tend to organize useful code into libraries,
so that similar models can be built automatically. Most of the models I
design have multiple parts, and frequently need multiple copies of each
part. I've built up a set of makefiles, libraries, and external tools that
let me create a set of STL files and a Markdown BOM from a single model
(that includes a bunch of libraries), but the end result is less than
ideal. As an example of how complex this can get, see (
https://github.com/wcraigtrader/game-parts/tree/master/18XX), specifically
the Makefile, 18XX.scad, and the libraries in ../util/.
- What I want is to produce one or more 3MF file(s) from a model, with
multiple objects and metadata so that I can specify author name, license
terms, etcetera.
- To go along with that, it would be wonderful to be able to pick one
object (or set of objects) in the UI and just render those objects in
preview. That would make it much easier to work on the components of a
model without having to continually edit the rendering section while
working on a module somewhere else.
- Add a bounding box function that takes a child and returns the
coordinates of a box that would contain the child. In its simplest
form, it could just emit the information to the console, so I could know if
a sub-model was too large, or how large a mating part would need to be.
- Make it easier to create test suites for OpenSCAD libraries and
modules.
- Make it easier to debug complex libraries and modules. I would
dearly love to be able to set a breakpoint on a line and be able to inspect
the variable space, call stack, and object model.
- I frequently need to edit with multiple windows open just to render
results in one window. I've largely given up on the OpenSCAD editor,
because it doesn't have the editing power I need. Instead, I just use a
preview window with Automatic Reload and Preview, and edit in VSCode (not
my preferred IDE, but it has SCAD syntax support).
There are a couple of open tickets about 3MF
https://github.com/openscad/openscad/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+3mf
in Github, but they seem to be wrapped around several other features, with
low apparent likelihood of completion. As an example,
https://github.com/openscad/openscad/issues/1608 seems to cover the
language extensions necessary to capture the information I want, but much
more, and has been open for 3 years.
For bounding boxes, these stories have been open for years:
For test suites, see:
Thanks for asking!
I'm a little late, but I'd still like to add my thoughts.
On Sat, Nov 9, 2019 at 5:23 PM Hans L <thehans@gmail.com> wrote:
> I wanted to get some input and have a bit of discussion from users here,
> regarding what they would most like to see from current or near-future
> OpenSCAD development.
>
> What do you feel is the most important aspect to focus on, or would have
> the biggest impact to your experience using OpenSCAD:
>
> 1) Stability, squash more bugs in general
> 2) Optimize existing code, make OpenSCAD faster
> 3) Addition of new features
> 4) More / improved documentation
> 5) All of the above should be balanced equally
> 6) Nothing, I am content
> 7) Something else not mentioned
I'm a software engineer by trade, and model designer by hobby. OpenSCAD is
my go-to tool for modeling. I tend to organize useful code into libraries,
so that similar models can be built automatically. Most of the models I
design have multiple parts, and frequently need multiple copies of each
part. I've built up a set of makefiles, libraries, and external tools that
let me create a set of STL files and a Markdown BOM from a single model
(that includes a bunch of libraries), but the end result is less than
ideal. As an example of how complex this can get, see (
https://github.com/wcraigtrader/game-parts/tree/master/18XX), specifically
the Makefile, 18XX.scad, and the libraries in ../util/.
1. What I want is to *produce one or more 3MF file(s) from a model, with
multiple objects and metadata so that I can specify author name, license
terms, etcetera*.
2. To go along with that, it would be wonderful to be able to *pick one
object (or set of objects) in the UI and just render those objects in
preview*. That would make it much easier to work on the components of a
model without having to continually edit the rendering section while
working on a module somewhere else.
3. Add a *bounding box function that takes a child and returns the
coordinates of a box that would contain the child*. In its simplest
form, it could just emit the information to the console, so I could know if
a sub-model was too large, or how large a mating part would need to be.
4. Make it easier to *create test suites for OpenSCAD libraries and
modules*.
5. Make it easier to *debug complex libraries and modules*. I would
dearly love to be able to set a breakpoint on a line and be able to inspect
the variable space, call stack, and object model.
6. I frequently need to edit with multiple windows open just to render
results in one window. I've largely given up on the OpenSCAD editor,
because it doesn't have the editing power I need. Instead, I just use a
preview window with Automatic Reload and Preview, and edit in VSCode (not
my preferred IDE, but it has SCAD syntax support).
There are a couple of open tickets about 3MF
<https://github.com/openscad/openscad/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+3mf>
in Github, but they seem to be wrapped around several other features, with
low apparent likelihood of completion. As an example,
https://github.com/openscad/openscad/issues/1608 seems to cover the
language extensions necessary to capture the information I want, but much
more, and has been open for 3 years.
For bounding boxes, these stories have been open for years:
- https://github.com/openscad/openscad/issues/1088
- https://github.com/openscad/openscad/issues/301
For test suites, see:
- https://github.com/openscad/openscad/issues/2798
Thanks for asking!
- Craig -
