2D preview convexity issue

21 messages
12
Open this post in threaded view
|

2D preview convexity issue

 When I display these 2D gear teeth with F5 they have convexity issues.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.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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

Open this post in threaded view
|

Re: 2D preview convexity issue

Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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-Millisecondssounds 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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
Open this post in threaded view
|

Re: 2D preview convexity issue

 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)]]; 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]]; -- Sent from: http://forum.openscad.org/_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

Re: 2D preview convexity issue

 > I also never understood, why 2D objects are displayed as 3D objects in 3DI 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)]]; 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]]; -- 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