2D preview convexity issue

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

2D preview convexity issue

nophead
When I display these 2D gear teeth with F5 they have convexity issues.

image.png

They are just polygons with the convexity set to the number of teeth with a circle subtracted.

If I linear extrude them they display correctly in 3D.

image.png

It looks like the 2D display doesn't take convexity into account, or polygon ignores convexity.

If I linear extrude the polygon and then subtract a cylinder then I have to set convexity in the linear extrude. Should it get the value from the polygon? I.e. what is the point in setting it in a polygon?





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

Ronaldo
It looks like the 2D display doesn't take convexity into account, or polygon ignores convexity.

If I linear extrude the polygon and then subtract a cylinder then I have to set convexity in the linear extrude. Should it get the value from the polygon? I.e. what is the point in setting it in a polygon?

Due to the way preview deals with 2D objects, given them a unit height, it makes sense to have a convexity argument in polygon. If it worked, for sure. But what is the meaning of a convexity parameter to 2D figures? Why do 2D objects have a height in preview? Why may 2D objects be rotated around an axis other than Z axis in preview?  F6 will show a very different animal for any of that.

As it is now, we can preview even the difference between a square and a cube. Render will complain about the mix of 2D and 3D objects. That is a lot confusing for beginners and useless for experienced users. I understand that 2D objects may be a trouble to Z-buffer but a negligible height should solve that. And the mixing of 2D and 3D objects should be caught by preview.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

nophead
Yes 2D preview is a bit of bodge but convexity makes sense in 2D just the same as in 3D but it doesn't seem to work in 2D preview and isn't propagated to 3D. Surely if you linear_extrude a 2D object with convexity n, the 3D object should have the same convexity, unless it is twisted, in which case it could be more I think, but not less, so it could become the default for linear_extrude.

Convexity is only needed for OpenCSG, which only works in 3D. So if polygon has a convexity parameter the only thing it could be used for is displaying it in 3D. Either when it gets converted to 3D by linear_extrude, or by the implicit extrude to 1mm for 2D preview. It seems to not work for either, so why does polygon have a convexity parameter?

On Sun, 5 Jul 2020 at 21:54, Ronaldo Persiano <[hidden email]> wrote:
It looks like the 2D display doesn't take convexity into account, or polygon ignores convexity.

If I linear extrude the polygon and then subtract a cylinder then I have to set convexity in the linear extrude. Should it get the value from the polygon? I.e. what is the point in setting it in a polygon?

Due to the way preview deals with 2D objects, given them a unit height, it makes sense to have a convexity argument in polygon. If it worked, for sure. But what is the meaning of a convexity parameter to 2D figures? Why do 2D objects have a height in preview? Why may 2D objects be rotated around an axis other than Z axis in preview?  F6 will show a very different animal for any of that.

As it is now, we can preview even the difference between a square and a cube. Render will complain about the mix of 2D and 3D objects. That is a lot confusing for beginners and useless for experienced users. I understand that 2D objects may be a trouble to Z-buffer but a negligible height should solve that. And the mixing of 2D and 3D objects should be caught by preview.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

Whosawhatsis
Convexity *doesn't* make sense in 2D. It is only needed because the OpenCSG preview doesn't actually display 2D things as 2D.

This would be less of an issue if OpenCSG previews of 2D objects weren't so thick. 1mm is simple, and seemed to be ok when printer resolution was more restricted, and designs with lots of ~1mm features were less common. Assuming there's still no way to make truly 2D previews work, I've been wondering if it's time to step down the thickness of these previews to .1 or .01mm. It would also be helpful if the default color for previews of 2D objects was different, so that it would be easier to tell when you're mixing 2D and 3D objects (especially with the feature in the beta version that lets you identify a feature in the code by clicking on it in the preview).

On July 5, 2020 at 14:07:39, nop head ([hidden email]) wrote:

Yes 2D preview is a bit of bodge but convexity makes sense in 2D just the same as in 3D but it doesn't seem to work in 2D preview and isn't propagated to 3D. Surely if you linear_extrude a 2D object with convexity n, the 3D object should have the same convexity, unless it is twisted, in which case it could be more I think, but not less, so it could become the default for linear_extrude.

Convexity is only needed for OpenCSG, which only works in 3D. So if polygon has a convexity parameter the only thing it could be used for is displaying it in 3D. Either when it gets converted to 3D by linear_extrude, or by the implicit extrude to 1mm for 2D preview. It seems to not work for either, so why does polygon have a convexity parameter?

On Sun, 5 Jul 2020 at 21:54, Ronaldo Persiano <[hidden email]> wrote:
It looks like the 2D display doesn't take convexity into account, or polygon ignores convexity.

If I linear extrude the polygon and then subtract a cylinder then I have to set convexity in the linear extrude. Should it get the value from the polygon? I.e. what is the point in setting it in a polygon?

Due to the way preview deals with 2D objects, given them a unit height, it makes sense to have a convexity argument in polygon. If it worked, for sure. But what is the meaning of a convexity parameter to 2D figures? Why do 2D objects have a height in preview? Why may 2D objects be rotated around an axis other than Z axis in preview?  F6 will show a very different animal for any of that.

As it is now, we can preview even the difference between a square and a cube. Render will complain about the mix of 2D and 3D objects. That is a lot confusing for beginners and useless for experienced users. I understand that 2D objects may be a trouble to Z-buffer but a negligible height should solve that. And the mixing of 2D and 3D objects should be caught by preview.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

rew
In reply to this post by nophead
On Sun, Jul 05, 2020 at 07:13:28PM +0100, nop head wrote:
> When I display these 2D gear teeth with F5 they have convexity issues.
>
> [image: image.png]
>
> They are just polygons with the convexity set to the number of teeth with a
> circle subtracted.

The convexity is the maximum number of times a straight line CAN enter
and exit the object. With convexity = number of teeth you've got a
pretty good margin. some thought would reduce that number
significantly. (A straight line can at most hit the teeth on one side,
so number of teeth/2 is still plenty)

        Roger.

--
** [hidden email] ** 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

nophead
True, I realised that after posting. The odd thing is setting it to 100 is no problem. People warn it will slow down but I have never noticed that. Even setting it to 10000 doesn't cause a noticeable slow down in an animation! What does making it bigger actually do?

On Mon, 6 Jul 2020 at 12:44, Rogier Wolff <[hidden email]> wrote:
On Sun, Jul 05, 2020 at 07:13:28PM +0100, nop head wrote:
> When I display these 2D gear teeth with F5 they have convexity issues.
>
> [image: image.png]
>
> They are just polygons with the convexity set to the number of teeth with a
> circle subtracted.

The convexity is the maximum number of times a straight line CAN enter
and exit the object. With convexity = number of teeth you've got a
pretty good margin. some thought would reduce that number
significantly. (A straight line can at most hit the teeth on one side,
so number of teeth/2 is still plenty)

        Roger.

--
** [hidden email] ** 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

rew
On Mon, Jul 06, 2020 at 12:48:54PM +0100, nop head wrote:
> True, I realised that after posting. The odd thing is setting it to 100 is
> no problem. People warn it will slow down but I have never noticed that.
> Even setting it to 10000 doesn't cause a noticeable slow down in an
> animation! What does making it bigger actually do?

I think it is a hint to the rendering pipeline that once you've
determined that a "visionray" has intersected the object X times then
you can stop looking for intersections. Maybe your rendering hardware
doesn't need that hint because it uses different algorithms.

        Roger.

--
** [hidden email] ** 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

nophead
It needs to be at least 2 to make it display correctly, which makes no sense to me.

On Mon, 6 Jul 2020 at 12:59, Rogier Wolff <[hidden email]> wrote:
On Mon, Jul 06, 2020 at 12:48:54PM +0100, nop head wrote:
> True, I realised that after posting. The odd thing is setting it to 100 is
> no problem. People warn it will slow down but I have never noticed that.
> Even setting it to 10000 doesn't cause a noticeable slow down in an
> animation! What does making it bigger actually do?

I think it is a hint to the rendering pipeline that once you've
determined that a "visionray" has intersected the object X times then
you can stop looking for intersections. Maybe your rendering hardware
doesn't need that hint because it uses different algorithms.

        Roger.

--
** [hidden email] ** 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

acwest
Any convex polyhedron will have a convexity of two, one surface going in and one going out

On Mon, 6 Jul 2020, 08:05 nop head, <[hidden email]> wrote:
It needs to be at least 2 to make it display correctly, which makes no sense to me.

On Mon, 6 Jul 2020 at 12:59, Rogier Wolff <[hidden email]> wrote:
On Mon, Jul 06, 2020 at 12:48:54PM +0100, nop head wrote:
> True, I realised that after posting. The odd thing is setting it to 100 is
> no problem. People warn it will slow down but I have never noticed that.
> Even setting it to 10000 doesn't cause a noticeable slow down in an
> animation! What does making it bigger actually do?

I think it is a hint to the rendering pipeline that once you've
determined that a "visionray" has intersected the object X times then
you can stop looking for intersections. Maybe your rendering hardware
doesn't need that hint because it uses different algorithms.

        Roger.

--
** [hidden email] ** 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

nophead
Well there seems to be some confusion in the documentation. I think it is actually half the number of crossings, or the number of crossings of front faces and not back faces.

Also with linear extrude it doesn't matter at all if it is the top level, it only matters if you do subsequent CGS ops on the result.

On Mon, 6 Jul 2020 at 13:19, A. Craig West <[hidden email]> wrote:
Any convex polyhedron will have a convexity of two, one surface going in and one going out

On Mon, 6 Jul 2020, 08:05 nop head, <[hidden email]> wrote:
It needs to be at least 2 to make it display correctly, which makes no sense to me.

On Mon, 6 Jul 2020 at 12:59, Rogier Wolff <[hidden email]> wrote:
On Mon, Jul 06, 2020 at 12:48:54PM +0100, nop head wrote:
> True, I realised that after posting. The odd thing is setting it to 100 is
> no problem. People warn it will slow down but I have never noticed that.
> Even setting it to 10000 doesn't cause a noticeable slow down in an
> animation! What does making it bigger actually do?

I think it is a hint to the rendering pipeline that once you've
determined that a "visionray" has intersected the object X times then
you can stop looking for intersections. Maybe your rendering hardware
doesn't need that hint because it uses different algorithms.

        Roger.

--
** [hidden email] ** 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

jon_bondy
In reply to this post by nophead
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:
> True, I realised that after posting. The odd thing is setting it to
> 100 is no problem. People warn it will slow down but I have never
> noticed that. Even setting it to 10000 doesn't cause a noticeable slow
> down in an animation! What does making it bigger actually do?
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

tp3
On 06.07.20 14:27, jon wrote:
> 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?

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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

nophead
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 <[hidden email]> wrote:
On 06.07.20 14:27, jon wrote:
> 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?

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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

rew
In reply to this post by tp3
On Mon, Jul 06, 2020 at 02:34:24PM +0200, Torsten Paul wrote:
> 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.

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.



>
> ciao,
>   Torsten.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

--
** [hidden email] ** 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

tp3
On 06.07.20 15:07, Rogier Wolff wrote:
> 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 (*)).

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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

nophead
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 <[hidden email]> wrote:
On 06.07.20 15:07, Rogier Wolff wrote:
> 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 (*)).

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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

tp3
On 06.07.20 18:07, nop head wrote:
> 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.

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.

> 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?

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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

Parkinbot
In reply to this post by Ronaldo
Ronaldo wrote

> But what is the meaning of a convexity parameter to 2D figures? Why
> do 2D objects have a height in preview? Why may 2D objects be rotated
> around an axis other than Z axis in preview?  F6 will show a very
> different animal for any of that.
>
> As it is now, we can preview even the difference between a square and a
> cube. Render will complain about the mix of 2D and 3D objects. That is a
> lot confusing for beginners and useless for experienced users. I
> understand
> that 2D objects may be a trouble to Z-buffer but a negligible height
> should
> solve that. And the mixing of 2D and 3D objects should be caught by
> preview.

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/$fn*i) 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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

nophead
> I also never understood, why 2D objects are displayed as 3D objects in 3D

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 <[hidden email]> wrote:
Ronaldo wrote
> But what is the meaning of a convexity parameter to 2D figures? Why
> do 2D objects have a height in preview? Why may 2D objects be rotated
> around an axis other than Z axis in preview?  F6 will show a very
> different animal for any of that.
>
> As it is now, we can preview even the difference between a square and a
> cube. Render will complain about the mix of 2D and 3D objects. That is a
> lot confusing for beginners and useless for experienced users. I
> understand
> that 2D objects may be a trouble to Z-buffer but a negligible height
> should
> solve that. And the mixing of 2D and 3D objects should be caught by
> preview.

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/$fn*i) 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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: 2D preview convexity issue

Parkinbot
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
> What happens if you try to do a 2D CSG op on a single face
> polyhedron in preview?






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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12