On 2019-11-11 05:15, Doug Moen wrote:

Actually, this is not correct. STL as such has no issues representing
such a thing. STL has no shared vertices or edges at all, every vertex
is duplicated for each triangle, and there are no explicit edges. The
problem is not representing such a thing in STL, the problem is
interpreting it consistently by OpenSCAD or any other program reading
it.

An STL file is a "polygon soup", it is simply a set of totally
disconnected triangles with zero shared topology. Such topology must be
guessed at by the program reading it, by comparing coordinates. This is
totally different from most other formats such as OBJ, OFF, AMF or 3MF
where the topology is explicitly represented.

For this reason, STL is particularly unsuitable for sharing models
between CAD applications. A slicer program is more forgiving so that
works better with STL.

No, this is not true. STL has no issues representing this case or any
other case, it does not care about non-manifoldness. It is not STL that
complains in this case, this issue is totally unrelated to STL.

The warning that the model is not 2-manifold can be considered false
alarm in some cases, whether it is a problem or not depends on the
intended use of the model. There is nothing wrong topologically with two
cubes sharing an edge in this way, it just happens to not be 2-manifold.

Manifoldness in this context means "how many times an edge is shared
between adjacent faces". An edge is the topological connection between 2
vertices. For a clean, closed volume every edge is used twice, hence it
is 2-manifold. In this case there are 2 volumes sharing an edge, so that
edge becomes 4-manifold as it is referenced by 4 faces.

But manifoldness is totally irrelevant in the STL file format, you can
write this file to STL without any issue. You can also write a single
triangle to an STL without any issue, there is no volume in that case.
The problem with STL is not that it is limited or restrictive, the
problem with STL is that there are no rules at all, so interpretation of
it becomes a problem.

Any of STL, OBJ, OFF, AMF will of course support such a model. It is not
a question of file format.

As does OBJ, OFF and AMF. All of them use the kind of topology you
describe below.

Not duplicating the vertices is what is causing the edge to be
4-manifold. If 3MF require all edges to be 2-manifold, it is 3MF that is
extra restrictive.

But that seems to violate the rule you just referred to?

Carsten Arnholm

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.

On Tue, 12 Nov 2019 at 01:30, jang0 ydmorenoc@unal.edu.co wrote:

Aspect 3:

My wish would be for an exportable 2D view (in SVG) of an elevation (xy
or yz or zx or definable) profile that preserved the colours of the
model as seen in preview mode.

I believe someone could write a coloured plane to CAM-GCode package from
such an image for routing, milling or laser work. I hesitate to say it
would be simple only for the fact I would certainly not find it simple,
but others could find it easier? Certainly, if possible, it could
release a lot more of OpenSCAD goodness into these other worlds (eg via
Inkscape+add-ons).

It would also be handy for documentation and trial fit purposes.

Rob

On 10/11/19 9:22 am, Hans L wrote:

On 11/10/2019 11:33 PM, nop head wrote:

While that's mathematically true, in practical reality it's not.

In practical reality I can jam two cubes edge-to-edge and get something
that sure looks like a shared zero-width edge.  Is it really?  It might
be separated by just a little, or down at the atomic level the two might
interpenetrate just a little.  Who cares?  When the printer is spitting
out 0.4mm plastic with a resolution best measured in fractions of a
millimeter, there's no practical difference between a separation of one
micrometer, zero, and an overlap of one micrometer.  The printer can't
represent any of them accurately, so it doesn't matter what it does.

If I have

cube(100);
translate([0,0,100]) cube(50);
translate([50,50,100]) cube(50);

it's clear that the two upper cubes are attached to the lower cube, and
it doesn't matter whether they're attached to each other.  There is no
practical reason why it should be different from

cube(100);
translate([0,0,100]) cube(50.001);
translate([50,50,100]) cube(50);

or

cube(100);
translate([0,0,100]) cube(49.999);
translate([50,50,100]) cube(50);

... and yet it is.

I would say that it would be correct in any of those cases for the
printer to draw a continuous line across the joint, or to not draw a
continuous line across the joint.  The joint is below its extrusion
width and so exactly what it should do is not well-defined.  (In fact,
it should probably be a user option what to do with volumes that are
below half the extrusion width - either round them out of existence, or
say that every volume deserves to be represented, if only as a single
extrusion.

2D programs deal with hairlines all the time; this seems like the same case.

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:

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:

JordanBrown wrote

Nothing is certain https://en.wikipedia.org/wiki/Uncertainty_principle the
edge is a waveform, electron orbits are also waveforms, so who can tell...
Unless you have:

Admin - email* me if you need anything, or if I've done something stupid...

• click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

Sent from: http://forum.openscad.org/

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:

On 2019-11-12 08:19, nop head wrote:

Carve does not have "native" support for 3D Minkowski, but I have
implemented 3D Minkowski on top of Carve, taking advantage of
multithreading for fast unions.

Carsten Arnholm