If making it 10000 causes no noticeable slow down, can we just eliminate
it as a parameter and force it to 10000 internal to the routine?

On 7/6/2020 7:48 AM, nop head wrote:

On 06.07.20 14:27, jon wrote:

That's not how it works. You can't change behavior because you
found one counter example. You'd have to prove it's working for
a reasonable high percentage of designs.

I don't know how the parameter is used internally, but my
understanding so far is that it's some kind of "number of
redraws" counter. So the effect does not just depend on the
geometry and the value, but also on the viewing direction.
If the number of redraws is not high enough, you'll end up
with areas that are not drawn in the correct color.

ciao,
Torsten.

I seem to remember on one of my old laptops it needs it set higher.

On Mon, 6 Jul 2020 at 13:35, Torsten Paul Torsten.Paul@gmx.de wrote:

On Mon, Jul 06, 2020 at 02:34:24PM +0200, Torsten Paul wrote:

What I remember from my Computer graphics class in 1985:

One strategy to rendering 3D scenes is to draw all pixels of all
objects, But for each pixel that is projected to the screen, you also
calculate the original Z-coordinate (not the Z coordinate of the real
object but the Z-coordinate just-before-the-projection-step (*)).

This is wat causes "Z-fighting" when you have a 0-thickness remnant
resulting from a subtraction of two planes that are precisely in the
same place.

I don't see how knowing the convexity can help in deciding not to
continue drawing objects.

Roger. 

(*) projection is always "towards the origin" and onto the Z=1 plane.
It is done by dividing X and Y by Z. It is this Z coordinate that
matters.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

On 06.07.20 15:07, Rogier Wolff wrote:

That's rendering a known mesh. The preview we are talking about,
where the convexity parameter comes into play, has no single mesh.
It's rendering the separate objects with some tricks using stencil
buffers and other GPU features.

E.g.
difference() {
cube(10, center = true);
cylinder(12, r = 4, center = true);
}

displays 2 solid convex objects. So if you look from some point
where you see the cut out cylinder, it will still render the
cylinder but not just with visible pixels but into a buffer that
will either inhibit drawing the pixels from the cube (where you
can see though) or the backside/inside of the cylinder where the
pixels are inside the cube (which is why the cut-out currently
gets the color of the object that is being subtracted).

Somewhere in that logic should be a clear definition of how
convexity behaves. It will likely depend on the algorithm used
(SCS or Goldfeather). I'm not sure if it also depends on the
GPU driver behavior, it's possible I guess.

I would like to understand that in more detail, so maybe there's
a bit of quiet time at some point to read though the references
in http://opencsg.org/publications.html - maybe there's also
more advanced algorithms out there that could improve the
preview behavior, e.g.
https://www.gdcvault.com/play/1026755/Tools-Summit-Geometry-in-Milliseconds
sounds interesting from the abstract, but I have not seen the
talk yet.

ciao,
Torsten.

Should I raise a bug report for the 2D rendering bug? I.e. difference
between a gear polygon with convexity set and a circle? There doesn't seem
to be anywhere else to specify convexity to get a correct display.

Also should a linear_extrude of a polygon with convexity set inherit that
convexity? If not, what does the convexity parameter of polygon actually do?

On Mon, 6 Jul 2020 at 14:40, Torsten Paul Torsten.Paul@gmx.de wrote:

On 06.07.20 18:07, nop head wrote:

Yes, as polygon is accepting convexity it looks like it's
intended to be used for the preview. So that seems to be a
bug.

Yep, it would make sense to inherit that. If that's not
implemented at all, convexity of polygon was probably just
intended for previewing the 2d shape.

ciao,
Torsten.

Ronaldo wrote

I also never understood, why 2D objects are displayed as 3D objects in 3D
space and OpenSCAD produces results like

difference()
{
rotate([45,0,0]) polygon(circle());
rotate([30,0,0]) translate([0, 0, 4])polygon(circle());
}
function circle(r=20, N = 30) = let($fn= $fn?$fn:N)  [for(i=[0:$fn-1])
let(a=360/$fni) r[cos(a), sin(a)]];

http://forum.openscad.org/file/t887/poly1.png
Furthermore polygon() accepts only 2D vectors. This can be quite confining
if you are juggling around with polygons defined in 3D (needed for skin()).
For this I am using a poly() module in my codes:

rotate([30,0,0]) translate([0, 0, 4]) poly(circle());

module poly(p)
{
p = (len(p[0])==2)?vec3(p):p;
polyhedron(p, [[for(i=[0:len(p)-1]) i]]);
}

function vec3(p) = [for(i=p) [i[0], i[1], 0]];

http://forum.openscad.org/file/t887/poly2.png

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

I think because the preview is generated by OpenCSG and that only handles
3D objects. What happens if you try to do a 2D CSG op on a single face
polyhedron in preview?

On Tue, 7 Jul 2020 at 10:45, Parkinbot rudolf@digitaldocument.de wrote:

You can try it out. Unions work, but intersection() and difference() produce
no result with F5. With F6 the result is correct but you get a warning ...

try it out ...

intersection()
{
poly(circle());
translate([10, 0, 0]) poly(circle());
}

nophead wrote

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