-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Greeting All. Although I am completely new to OpenSCAD (which I consider a great tool already, thanks), I've got some CSG background with ray tracing software (polyray, povray). As much as I like OpenSCAD, I already miss one primitive, the plane. The plane[1] that divides the space into two half-spaces (for example): the inside and outside one, that can be used as arguments in the difference() and the intersection() operations. The plane as an argument for the union() does not make much sense. The plane can be emulated with a large box, however it is not nearly as elegant as the plane. RFC [1] http://www.povray.org/documentation/view/3.6.0/297/ P.S. I am afraid my C++ is so rusty you wouldn't like to see me implementing even that trivial feature. - -- Było mi bardzo miło. Czwarta pospolita klęska, [...] >Łukasz< Już nie katolicka lecz złodziejska. (c)PP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR4vghAAoJEAC2l2xjkdNx1aEIAJToWINzI2+0ltoKoYYrcFVy cI5m5xIM9fIGtZGCtO013CnK5WjhiEF3kHzZ9uVnc0FjCPUEdm9AADJ42pPDR8XC rU+3ATrDRF6Vj2VKH8PYb133YlHVLDOeSjda2viStmd6RKg8qoiGGO2JyvNUL5Vr yefy7W4gVxpTYKQ5UHM0SDdUHOITzA8Zeu3JPN0tVt30b3zawInIP5vKzgAJhn9a 4fAGupvj1e+1JJTwo8JFi+hbtz2LBkW06b0xQhgterHThSRAV3qWAfscPaELWx9W ynHqtXo/26LxvEZzya7TScE9zQG8Mdfc9ZIduDufP3EwULNLj+Aqy+udIqo2gVM= =w8hF -----END PGP SIGNATURE----- _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
I agree with Lukasz. I implemented a 'plane' using a large box myself, but it is:
* very inelegant; and even more importantly, * a lot slower, because it requires at least 6x as much work as for a single plane. I'd also like a 3D line/line segment 'line()' (useful for convex hull operations 'hull()' and also Minkowski sums 'sum()'. Once again, you can attempt to emulate a line segment with very thin polyhedrons, but the emulate costs in terms of ending up with very thin triangles in your final object. Ditto with 3D points. Similarly useful for convex hulls and Minkowski sums. Henry Baker At 12:12 PM 7/14/2013, Lukasz Stelmach wrote: >Greeting All. > >Although I am completely new to OpenSCAD (which I consider a great tool already, thanks), I've got some CSG background with ray tracing software (polyray, povray). > >As much as I like OpenSCAD, I already miss one primitive, the plane. > >The plane[1] that divides the space into two half-spaces (for example): the inside and outside one, that can be used as arguments in the difference() and the intersection() operations. > >The plane as an argument for the union() does not make much sense. > >The plane can be emulated with a large box, however it is not nearly as elegant as the plane. > >RFC [1] http://www.povray.org/documentation/view/3.6.0/297/ > >P.S. I am afraid my C++ is so rusty you wouldn't like to see me implementing even that trivial feature. > >- -- ByÅo mi bardzo miÅo. Czwarta pospolita klÄska, [...] >Åukasz< JuÅ¼ nie katolicka lecz zÅodziejska. (c)PP _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
think i would disagree on the cube as inelegant from a cad point of view , and would say the plain is more so ,, given that a cube has a defined height over a plane , that would show the needed thickness in the data ,
where as a plain has infinite thickness from the base plain , the speed would be about the same for a box as it has "thickness" in difference() / intersection() /union() operations where a 2d object
does not ,as you can not implement it as 2 triangles that are 2d and a lot faster if you had to convert the plain to gcode for a mill then you would could end up waiting for the machine to ensure that all points to infinity are removed above the plain hight so it would ether run to all its limit stops or trash the machine , and would take far longer than rendering it as a cube to just over what's needed to be removed
i do agree on the need for a line() / line segment / path primitive as there are cases where you do need it and emulating it is not ideal On Sun, Jul 14, 2013 at 10:08 PM, Henry Baker <[hidden email]> wrote: I agree with Lukasz. I implemented a 'plane' using a large box myself, but it is: _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
if you look at it the following way in something like povray where you would say define a plane as ground , thats ideal for say CGI type programs were distance limits are not an issue other than visual
but in cad it would be better to define a cube as the size of the machine limits , in that case you would need 6 planes to do the same
so no quicker and less elegant than a cube for render times also working with plains that have an effective size greater than the actual limits of the machine that may produce such an item is going to lead to effective coordinates
outside the machines limits that is not good practice On Sun, Jul 14, 2013 at 11:30 PM, David Powell <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by David Powell
The issue is planes and lines don't have enough dimensions to be 3D shapes, so I can see why they don't exist in OpenScad 3D mode. I can't see how either would make any sense in any of the normal operations like difference(), union() or intersection()? Only in extrude, which adds dimensions and minkowski() and hull(), which could add dimensions, but infact I think they can't at the moment.
On 14 July 2013 23:30, David Powell <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by David Powell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 W dniu 15.07.2013 00:30, David Powell pisze: > think i would disagree on the cube as inelegant from a cad point of > view , and would say the plain is more so ,, given that a cube has > a defined height over a plane , that would show the needed > thickness in the data , where as a plain has infinite thickness > from the base plain , It does not matter (if I understand correctly). When you use the plane as an argument for the operations the thinckness does not matter. What matters is on which side of the plane other objects are. > the speed would be about the same for a box as it has "thickness" > in difference() / intersection() /union() operations where a 2d > object does not ,as you can not implement it as 2 triangles that > are 2d and a lot faster I admit, I don't know how OpenSCAD implements CSG operations but if they are true CSG then there is nothing faster than the plane. > if you had to convert the plain to gcode for a mill then you would > could end up waiting for the machine to ensure that all points to > infinity are removed above the plain hight so it would ether run to > all its limit stops or trash the machine , and would take far > longer than rendering it as a cube to just over what's needed to be > removed Converting a plane to gcode is somewhat impossible without clipping. Probably it shouldn't be possible to export a file with the plane used alone and not as a part of any operation. > i do agree on the need for a line() / line segment / path > primitive as there are cases where you do need it and emulating it > is not ideal I didn't hit that wall yet. > On Sun, Jul 14, 2013 at 10:08 PM, Henry Baker > <[hidden email] <mailto:[hidden email]>> wrote: > > I agree with Lukasz. I implemented a 'plane' using a large box > myself, but it is: * very inelegant; and even more importantly, * a > lot slower, because it requires at least 6x as much work as for a > single plane. > > I'd also like a 3D line/line segment 'line()' (useful for convex > hull operations 'hull()' and also Minkowski sums 'sum()'. Once > again, you can attempt to emulate a line segment with very thin > polyhedrons, but the emulate costs in terms of ending up with very > thin triangles in your final object. > > Ditto with 3D points. Similarly useful for convex hulls and > Minkowski sums. > > Henry Baker > > At 12:12 PM 7/14/2013, Lukasz Stelmach wrote: >> Greeting All. >> >> Although I am completely new to OpenSCAD (which I consider a >> great > tool already, thanks), I've got some CSG background with ray > tracing software (polyray, povray). >> >> As much as I like OpenSCAD, I already miss one primitive, the >> plane. >> >> The plane[1] that divides the space into two half-spaces (for > example): the inside and outside one, that can be used as > arguments in the difference() and the intersection() operations. >> >> The plane as an argument for the union() does not make much >> sense. >> >> The plane can be emulated with a large box, however it is not > nearly as elegant as the plane. >> >> RFC [1] http://www.povray.org/documentation/view/3.6.0/297/ >> >> P.S. I am afraid my C++ is so rusty you wouldn't like to see me > implementing even that trivial feature. - -- Było mi bardzo miło. Czwarta pospolita klęska, [...] > Łukasz< Już nie katolicka lecz złodziejska. (c)PP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR4zAMAAoJEAC2l2xjkdNx49YH/ik/U5NSR0KA0nHEDSLqfyMm Mv6qlr2ziqMqZAea2FseY+pw3JLrowzSdmiX9fzAQavegLS63cJr4s2YclZEmp6z xUL7ORV+cHc9Zsb2uouQl9JWV/odf1a5WLehpQ6Q35LcDCZnkLVT2BeuUu2dIJLE ZqZjqdYr7Oju8xa7YBXSnXk/shTH+uhvie7V8kzTqCHB9AXaP0xqHUAmp146Gl4a 2Z9W3J+4Nlzw5Ayg5Ex3aRLs16jityVULFFJYM58MvtiamYkWabq2WtDU5zOZS6w fZQ8LEEy/SdD1H221ZfwXjhOxTIANV4pP2RNc/iIU7qf7Mh+zaMfauFPvGqwoMs= =ksnN -----END PGP SIGNATURE----- _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
For the plane, since it can only be used for a difference operation, why not just provide a cut module that will function as if an infinitely large cube with a side bisecting the area was subtracted (though hopefully working more efficiently)?
On Sunday, July 14, 2013 at 4:11 PM, Lukasz Stelmach wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
If you difference() a plane surely you get an non-mainfold result with an infinitely thin sliver missing? You seem to be discussing a half plane, which is even less a 2D object.
On 15 July 2013 00:16, whosawhatsis <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by nophead
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Hello. I don't quit understand the issue with lines but the plane is really the basic operand for CSG. You use it to cut space into two half-spaces, one is considered to be inside and one outside. So no matter how large is an object you'd like to cut if you use the plane you will manage. I agree it may be quite hard to visualise the plane, however, it looks (to me) like a quite handy operand for difference() / intersection(). It doesn't make much sense in union() unless the union is going to be used as an operand for another difference() or intersection(). W dniu 15.07.2013 01:10, nop head pisze: > The issue is planes and lines don't have enough dimensions to be 3D > shapes, so I can see why they don't exist in OpenScad 3D mode. > > I can't see how either would make any sense in any of the normal > operations like difference(), union() or intersection()? Only in > extrude, which adds dimensions and minkowski() and hull(), which could > add dimensions, but infact I think they can't at the moment. > > > On 14 July 2013 23:30, David Powell <[hidden email] > <mailto:[hidden email]>> wrote: > > think i would disagree on the cube as inelegant from a cad point of > view , and would say the plain is more so ,, > given that a cube has a defined height over a plane , that would > show the needed thickness in the data , > where as a plain has infinite thickness from the base plain , > > the speed would be about the same for a box as it has "thickness" > in difference() / intersection() /union() operations where a 2d object > does not ,as you can not implement it as 2 triangles that are 2d and > a lot faster > > if you had to convert the plain to gcode for a mill then you would > could end up waiting for the machine to ensure that all points to > infinity are removed above the plain hight so it would ether run to > all its limit stops or trash the machine , and would take far longer > than rendering it as a cube to just over what's needed to be removed > > > i do agree on the need for a line() / line segment / path > primitive as there are cases where you do need it and emulating it > is not ideal > > > > > On Sun, Jul 14, 2013 at 10:08 PM, Henry Baker <[hidden email] > <mailto:[hidden email]>> wrote: > > I agree with Lukasz. I implemented a 'plane' using a large box > myself, but it is: > * very inelegant; and even more importantly, > * a lot slower, because it requires at least 6x as much work as > for a single plane. > > I'd also like a 3D line/line segment 'line()' (useful for convex > hull operations 'hull()' and also Minkowski sums 'sum()'. Once > again, you can attempt to emulate a line segment with very thin > polyhedrons, but the emulate costs in terms of ending up with > very thin triangles in your final object. > > Ditto with 3D points. Similarly useful for convex hulls and > Minkowski sums. > > Henry Baker > > At 12:12 PM 7/14/2013, Lukasz Stelmach wrote: > >Greeting All. > > > >Although I am completely new to OpenSCAD (which I consider a > great tool already, thanks), I've got some CSG background with > ray tracing software (polyray, povray). > > > >As much as I like OpenSCAD, I already miss one primitive, the > plane. > > > >The plane[1] that divides the space into two half-spaces (for > example): the inside and outside one, that can be used as > arguments in the difference() and the intersection() operations. > > > >The plane as an argument for the union() does not make much sense. > > > >The plane can be emulated with a large box, however it is not > nearly as elegant as the plane. > > > >RFC [1] http://www.povray.org/documentation/view/3.6.0/297/ > > > >P.S. I am afraid my C++ is so rusty you wouldn't like to see me > implementing even that trivial feature. > > - -- Było mi bardzo miło. Czwarta pospolita klęska, [...] >Łukasz< Już nie katolicka lecz złodziejska. (c)PP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR4zS0AAoJEAC2l2xjkdNx890IAJhv9IETqJXqBYO6yHIYL7dN QVHuUjWGeTQkNwq2KwZLLWN3Vzx7g+fVGcxRQL867OvgUxmTMMboZFdt9P80vzGx A2fRtRo5NPkY8IHoY+osj1zKum/SayYFwiGowYhUPRLCEghLHAwvKreluEhE9ENs NkVB8lz+WDeuNO1P4yuaiS0T+Hhkjd6MRQxxD+XY/wxqPeCFoRfssjxxMP6lXIu5 JyQ3xljXzSm3PW2k1U0Gf325uVAwpI4b1viOBCnBNHUe5WcCXIxX8pxHvHVRM8j2 zkOLt0sqFYv0gFVxjpNbaIqYsp418a3z1wO967tiT7f9366MEoBKMB8KK8frTPI= =1ZZC -----END PGP SIGNATURE----- _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by Whosawhatsis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Just for the record. The plane may be used in intersection as well and it will give exactly the same outcome as in difference() with the normal vector flipped. To use a cube to emulate the plane you need to properly calculate its dimensions so it bounds everything that is on "the other" side of one of its walls. This does not (as far as I know CSG in general) look easier to do than using the plane. W dniu 15.07.2013 01:16, whosawhatsis pisze: > For the plane, since it can only be used for a difference > operation, why not just provide a cut module that will function as > if an infinitely large cube with a side bisecting the area was > subtracted (though hopefully working more efficiently)? > > On Sunday, July 14, 2013 at 4:11 PM, Lukasz Stelmach wrote: > > W dniu 15.07.2013 00:30, David Powell pisze: > >>>> think i would disagree on the cube as inelegant from a cad >>>> point of view , and would say the plain is more so ,, given >>>> that a cube has a defined height over a plane , that would >>>> show the needed thickness in the data , where as a plain has >>>> infinite thickness from the base plain , > > It does not matter (if I understand correctly). When you use the > plane as an argument for the operations the thinckness does not > matter. What matters is on which side of the plane other objects > are. > >>>> the speed would be about the same for a box as it has >>>> "thickness" in difference() / intersection() /union() >>>> operations where a 2d object does not ,as you can not >>>> implement it as 2 triangles that are 2d and a lot faster > > I admit, I don't know how OpenSCAD implements CSG operations but > if they are true CSG then there is nothing faster than the plane. > >>>> if you had to convert the plain to gcode for a mill then you >>>> would could end up waiting for the machine to ensure that all >>>> points to infinity are removed above the plain hight so it >>>> would ether run to all its limit stops or trash the machine , >>>> and would take far longer than rendering it as a cube to just >>>> over what's needed to be removed > > Converting a plane to gcode is somewhat impossible without > clipping. Probably it shouldn't be possible to export a file with > the plane used alone and not as a part of any operation. > >>>> i do agree on the need for a line() / line segment / path >>>> primitive as there are cases where you do need it and >>>> emulating it is not ideal > > I didn't hit that wall yet. > >>>> On Sun, Jul 14, 2013 at 10:08 PM, Henry Baker >>>> <[hidden email] <mailto:[hidden email]>> wrote: >>>> >>>> I agree with Lukasz. I implemented a 'plane' using a large >>>> box myself, but it is: * very inelegant; and even more >>>> importantly, * a lot slower, because it requires at least 6x >>>> as much work as for a single plane. >>>> >>>> I'd also like a 3D line/line segment 'line()' (useful for >>>> convex hull operations 'hull()' and also Minkowski sums >>>> 'sum()'. Once again, you can attempt to emulate a line >>>> segment with very thin polyhedrons, but the emulate costs in >>>> terms of ending up with very thin triangles in your final >>>> object. >>>> >>>> Ditto with 3D points. Similarly useful for convex hulls and >>>> Minkowski sums. >>>> >>>> Henry Baker >>>> >>>> At 12:12 PM 7/14/2013, Lukasz Stelmach wrote: >>>>> Greeting All. >>>>> >>>>> Although I am completely new to OpenSCAD (which I consider >>>>> a great >>>> tool already, thanks), I've got some CSG background with ray >>>> tracing software (polyray, povray). >>>>> >>>>> As much as I like OpenSCAD, I already miss one primitive, >>>>> the plane. >>>>> >>>>> The plane[1] that divides the space into two half-spaces >>>>> (for >>>> example): the inside and outside one, that can be used as >>>> arguments in the difference() and the intersection() >>>> operations. >>>>> >>>>> The plane as an argument for the union() does not make >>>>> much sense. >>>>> >>>>> The plane can be emulated with a large box, however it is >>>>> not >>>> nearly as elegant as the plane. >>>>> >>>>> RFC [1] >>>>> http://www.povray.org/documentation/view/3.6.0/297/ >>>>> >>>>> P.S. I am afraid my C++ is so rusty you wouldn't like to >>>>> see me >>>> implementing even that trivial feature. > >> _______________________________________________ OpenSCAD mailing >> list [hidden email] <mailto:[hidden email]> >> http://rocklinux.net/mailman/listinfo/openscad >> http://openscad.org - https://flattr.com/thing/121566 > > > > _______________________________________________ OpenSCAD mailing > list [hidden email] > http://rocklinux.net/mailman/listinfo/openscad http://openscad.org > - https://flattr.com/thing/121566 > - -- By?o mi bardzo mi?o. Czwarta pospolita kl?ska, [...] > ?ukasz< Ju? nie katolicka lecz z?odziejska. (c)PP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR4zXbAAoJEAC2l2xjkdNxUcsH/RNHXh6eGzOYbNIoqZxxaWwb tGdN7eqY2Ga/fYc8sU0+UDwOvTIoturs/NjKKwlL9iWiWDJsJAdmsiJMB5eCM4ZM RI7mbKGLIMymzRLo7770xB3ne20lXnBY6t/kPMeBjyHNWKzU4oshspXqAp0nKgfq AYWU6ca3VJxnTt1DESqc1c/1o73LFOk2wToT5oyq6Q3jprd7sOn66q6pXbHCK/Dw tJupcNHGkrkaoDejO5Qsf/XbMJgyJgmgThFHQIQsAkcLUk3EQUmHh3qzCcG5GdzT fSk7TXeW8Zv7oLJNEmq6KTnK0jGZLaBDCYwwzzo1U67jgua0Bb4MeKEly/lDoNw= =d0E5 -----END PGP SIGNATURE----- _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by nophead
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 No. "The plane" (I try to introduce here) is actually I "half space" but the term "plane" is used in the ray tracing software I have seen (that's why I referred to povray documentation). W dniu 15.07.2013 01:22, nop head pisze: > If you difference() a plane surely you get an non-mainfold result > with an infinitely thin sliver missing? > > You seem to be discussing a half plane, which is even less a 2D > object. > > > On 15 July 2013 00:16, whosawhatsis <[hidden email] > <mailto:[hidden email]>> wrote: > > For the plane, since it can only be used for a difference > operation, why not just provide a cut module that will function as > if an infinitely large cube with a side bisecting the area was > subtracted (though hopefully working more efficiently)? > > On Sunday, July 14, 2013 at 4:11 PM, Lukasz Stelmach wrote: > > W dniu 15.07.2013 00:30, David Powell pisze: > >>>> think i would disagree on the cube as inelegant from a cad >>>> point of view , and would say the plain is more so ,, given >>>> that a cube has a defined height over a plane , that would >>>> show the needed thickness in the data , where as a plain has >>>> infinite thickness from the base plain , > > It does not matter (if I understand correctly). When you use the > plane as an argument for the operations the thinckness does not > matter. What matters is on which side of the plane other objects > are. > >>>> the speed would be about the same for a box as it has >>>> "thickness" in difference() / intersection() /union() >>>> operations where a 2d object does not ,as you can not >>>> implement it as 2 triangles that are 2d and a lot faster > > I admit, I don't know how OpenSCAD implements CSG operations but > if they are true CSG then there is nothing faster than the plane. > >>>> if you had to convert the plain to gcode for a mill then you >>>> would could end up waiting for the machine to ensure that all >>>> points to infinity are removed above the plain hight so it >>>> would ether run to all its limit stops or trash the machine , >>>> and would take far longer than rendering it as a cube to just >>>> over what's needed to be removed > > Converting a plane to gcode is somewhat impossible without > clipping. Probably it shouldn't be possible to export a file with > the plane used alone and not as a part of any operation. > >>>> i do agree on the need for a line() / line segment / path >>>> primitive as there are cases where you do need it and >>>> emulating it is not ideal > > I didn't hit that wall yet. > >>>> On Sun, Jul 14, 2013 at 10:08 PM, Henry Baker >>>> <[hidden email] <mailto:[hidden email]> >>>> <mailto:[hidden email]>> wrote: >>>> >>>> I agree with Lukasz. I implemented a 'plane' using a large >>>> box myself, but it is: * very inelegant; and even more >>>> importantly, * a lot slower, because it requires at least 6x >>>> as much work as for a single plane. >>>> >>>> I'd also like a 3D line/line segment 'line()' (useful for >>>> convex hull operations 'hull()' and also Minkowski sums >>>> 'sum()'. Once again, you can attempt to emulate a line >>>> segment with very thin polyhedrons, but the emulate costs in >>>> terms of ending up with very thin triangles in your final >>>> object. >>>> >>>> Ditto with 3D points. Similarly useful for convex hulls and >>>> Minkowski sums. >>>> >>>> Henry Baker >>>> >>>> At 12:12 PM 7/14/2013, Lukasz Stelmach wrote: >>>>> Greeting All. >>>>> >>>>> Although I am completely new to OpenSCAD (which I consider >>>>> a great >>>> tool already, thanks), I've got some CSG background with ray >>>> tracing software (polyray, povray). >>>>> >>>>> As much as I like OpenSCAD, I already miss one primitive, >>>>> the plane. >>>>> >>>>> The plane[1] that divides the space into two half-spaces >>>>> (for >>>> example): the inside and outside one, that can be used as >>>> arguments in the difference() and the intersection() >>>> operations. >>>>> >>>>> The plane as an argument for the union() does not make >>>>> much sense. >>>>> >>>>> The plane can be emulated with a large box, however it is >>>>> not >>>> nearly as elegant as the plane. >>>>> >>>>> RFC [1] >>>>> http://www.povray.org/documentation/view/3.6.0/297/ >>>>> >>>>> P.S. I am afraid my C++ is so rusty you wouldn't like to >>>>> see me >>>> implementing even that trivial feature. > >> _______________________________________________ OpenSCAD mailing >> list [hidden email] <mailto:[hidden email]> >> http://rocklinux.net/mailman/listinfo/openscad >> http://openscad.org - https://flattr.com/thing/121566 > > > _______________________________________________ OpenSCAD mailing > list [hidden email] <mailto:[hidden email]> > http://rocklinux.net/mailman/listinfo/openscad http://openscad.org > - https://flattr.com/thing/121566 > > > > > _______________________________________________ OpenSCAD mailing > list [hidden email] > http://rocklinux.net/mailman/listinfo/openscad http://openscad.org > - https://flattr.com/thing/121566 > - -- By?o mi bardzo mi?o. Czwarta pospolita kl?ska, [...] > ?ukasz< Ju? nie katolicka lecz z?odziejska. (c)PP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR4zZeAAoJEAC2l2xjkdNx9PQH/iuUEpvRjHHTJcH9x4mvkho1 nfdxXJY7lEskpWcVwXykjj7q6AglS5vrxLQJZqKMwQMPFnqRHSB07bxFhqUbHPUC F856jAhvMrpunrsYMUE9uXudEE1G5zYTEDezfkL1BZAlvvg/NmENl/P+s6XFSDNg wcgwvBC1E0aWKYw8OYJbqSF1CeXjs+squxwUz2w2PH/E4OrQdyXDFGz/PZ4RFixl kAlYzGTEwmYYHfD8RBQDhIgB9XVnJ/yOPN2YAsX0xw20yGNMn3VtFwikypmUtzzw DeNwX6nWBrw1T51DAqfXzolgjCnqB4yDX/6GfhDhBm+Yq7iXF3c1Wq5yyFqtkGE= =NYqP -----END PGP SIGNATURE----- _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by David Powell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Hi. I am not suggesting using planes for rendering anything but rather as a saw to cut other elements. In such context the limitlessness of the plane is not a problem as its existence is meaningful only in the presence of other objects. The plane which you can rotate and translate provides, IMHO, much better "API" for doing some operations. Let's say you want a beam to be cut on its ends like this _____________________ / \ / \ | \ ------------------------- where know angles and coordinates of important points. It is, at least for now, at least for *me*, much more *convenient* to define those operations with planes than care about the size and proper translation of the box. Of course I an new here, so I haven't probably learnt a few practicla tricks ;) W dniu 15.07.2013 01:01, David Powell pisze: > if you look at it the following way > > in something like povray where you would say define a plane as > ground , thats ideal for say CGI type programs were distance limits > are not an issue other than visual > > but in cad it would be better to define a cube as the size of the > machine limits , in that case you would need 6 planes to do the > same so no quicker and less elegant than a cube for render times > > > also working with plains that have an effective size greater than > the actual limits of the machine that may produce such an item is > going to lead to effective coordinates outside the machines limits > that is not good practice > > > On Sun, Jul 14, 2013 at 11:30 PM, David Powell > <[hidden email] <mailto:[hidden email]>> wrote: > > think i would disagree on the cube as inelegant from a cad point > of view , and would say the plain is more so ,, given that a cube > has a defined height over a plane , that would show the needed > thickness in the data , where as a plain has infinite thickness > from the base plain , > > the speed would be about the same for a box as it has "thickness" > in difference() / intersection() /union() operations where a 2d > object does not ,as you can not implement it as 2 triangles that > are 2d and a lot faster > > if you had to convert the plain to gcode for a mill then you would > could end up waiting for the machine to ensure that all points to > infinity are removed above the plain hight so it would ether run > to all its limit stops or trash the machine , and would take far > longer than rendering it as a cube to just over what's needed to be > removed > > > i do agree on the need for a line() / line segment / path > primitive as there are cases where you do need it and emulating it > is not ideal > > > > > On Sun, Jul 14, 2013 at 10:08 PM, Henry Baker > <[hidden email] <mailto:[hidden email]>> wrote: > > I agree with Lukasz. I implemented a 'plane' using a large box > myself, but it is: * very inelegant; and even more importantly, * a > lot slower, because it requires at least 6x as much work as for a > single plane. > > I'd also like a 3D line/line segment 'line()' (useful for convex > hull operations 'hull()' and also Minkowski sums 'sum()'. Once > again, you can attempt to emulate a line segment with very thin > polyhedrons, but the emulate costs in terms of ending up with very > thin triangles in your final object. > > Ditto with 3D points. Similarly useful for convex hulls and > Minkowski sums. > > Henry Baker > > At 12:12 PM 7/14/2013, Lukasz Stelmach wrote: >> Greeting All. >> >> Although I am completely new to OpenSCAD (which I consider a > great tool already, thanks), I've got some CSG background with ray > tracing software (polyray, povray). >> >> As much as I like OpenSCAD, I already miss one primitive, the > plane. >> >> The plane[1] that divides the space into two half-spaces (for > example): the inside and outside one, that can be used as arguments > in the difference() and the intersection() operations. >> >> The plane as an argument for the union() does not make much >> sense. >> >> The plane can be emulated with a large box, however it is not > nearly as elegant as the plane. >> >> RFC [1] http://www.povray.org/documentation/view/3.6.0/297/ >> >> P.S. I am afraid my C++ is so rusty you wouldn't like to see me > implementing even that trivial feature. >> - -- Było mi bardzo miło. Czwarta pospolita klęska, [...] > Łukasz< Już nie katolicka lecz złodziejska. (c)PP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR4zZ8AAoJEAC2l2xjkdNxhKAH/jico5uj31gPdTDqWfqMvW67 Iq3PA5kLh72a5H8+yatVAX1LnsnMU/ecL4z4qir0P+t9anrqlvpMNhVG8DvOvDht uy9mtJPyZ9rjVvUBd2ZZtylh47bJqIu3cYLH5ygl2RyPddKnUd1mgOqX0bQA2y8w t4d2C+ZRFVMLQwCBPV70406jjfI9hZVUZy3tb/Mp2kdjQrBXedYtyI+SrZ/Cwt/b 1bAW27RNxJ0U5zWx4rfdurRWiEx7cKg55R/p2MvX0FMe/atZ+E4kaQP5ZBxW231/ b+3Bm1G3j3Iy4KRMINXXUxKWwzs9n5eiGMpMkDEL+7capxTM90J0qHsG5ktsXV8= =ZzuF -----END PGP SIGNATURE----- _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
The issue is if you can write difference() { cube( ...); plane(...); } in OpenSCAD then you can also write
plane(...); and press F5 But that isn't a 2D or 3D object so can't exist outside of a difference() or intersection() and can't be rendered.
So you have to introduce a new type of node and operations and error messages but you don't actually add any new capabilities. Just make it more complex. Since everything you make has known dimensions you can always use a cube just big enough to get the same effect.
On 15 July 2013 00:38, Lukasz Stelmach <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
That's why I proposed the cut() module. It would act the same way, but you wouldn't have to worry about your cube being large enough, and it should be much faster to act on complex shapes like the one I've had crunching on a CGAL render for the last 5 hours.
On Sunday, July 14, 2013 at 5:01 PM, nop head wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
Yes that would fit into the language much better. On 15 July 2013 01:04, whosawhatsis <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
"Fitting into the language" is the problem.
OpenSCAD was designed and built from a particular point of view. It now has a tradition and a set of standard workarounds - but it is in many ways limited by the original ambitions.
The final product is (more-or-less) constrained to be a watertight manifold surface.
What Henry Baker, and others, are doing is coming at the language from a slightly different point of view and asking "why wasn't it designed to MY specifications". That can be viewed either as their failure to accept the tool for what it is OR it can
be viewed as an opportunity for OpenSCAD designers and developers to take another look at the requirements of a large community of users.
Yes - a "half-space" is unacceptable as a final output (for OpenSCAD's intended purpose), but it's not an unreasonable thing to ask for as an input or an intermediate result. Similarly for a "manifold-with-boundary", or even a solid (or surface!) with
other types of non-manifold features.
Personally, I think that "plane"/"halfspace" would be exceedingly useful to a very wide community - many of whom might otherwise be turned off by their absence and use other tools. Yes, implementation may required very deep changes in assumptions about
the underlying data structures maintained by OpenSCAD. That might be a useful re-examination.
Perhaps, along the way, we might also dispense with silliness such as "cubes" with three different dimensions…
And, while "plane"/"halfspace" seems most useful to me, I suspect that the work required to do that right would also
lead to good solutions for Henry's other issues: "point", "line", "line-segment" as well as a host of new operations.
We won't get there by incrementally tacking on individual new features. Each INDIVIDUAL newly requested feature is quite obviously "not worth the cost". But, taken together, the design and implementation work required to add *all* of these features (and
others that logically follow) might be worth it.
This will happen, either as a re-design of OpenSCAD, or as the motivation for someone to create a new language which addresses these issues from the beginning.
On the other hand…people such as Henry might consider that OpenSCAD is useful and available *because* it has limited ambitions. It is not a full-fledged programming language. It is a light-weight scripting language that emphasizes easy and quick access
to the core concepts chosen for inclusion. Every added feature threatens this.
Probably both Henry and I would *prefer* a CSG API embedded in a "real" language, which allowed us to take advantage of *both* general purpose programming *and* a decent CSG library. We may, however, differ on the choice of language…
Perhaps the right middle ground is to provide a richer repertoire of exchange file formats that OpenSCAD accepts.
As noted, STL is inadequate. I am not claiming that STL was the *wrong* choice in the beginning - it's a perfectly good option. It's just not the *only* option.
On Jul 15, 2013, at 01:11 , nop head <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by nophead
highlighting a plain /cut for debug is going to be rather useless to try to see how far out you got it when it does not quite intersect where you want it as to renter times , i cant see how it would improve them over using a cube as translate(...) rotate(...)cut(...) would still have to do the same calculations filling in the "missing" coordinates to be the drawing limits of the plane as translate(...)rotate(...)cube(...) would use ,, because although its a 2d object it behaves as a 3d object
there's other issues that need to be addressed in the render to speed it up overall , but unlike povray you cant use the same optimizations for objects that are "hidden from view" as
it needs to render the full object , the only practical way i can see of speeding up render times of some types of operations is to segment the meshes into arias that have
a/. no pending operations b/. that have intersection points with other objects c/.arias that are totally inside other objects by doing a quick pre render to find those arias , then it should save having to check each segment and ether know if its a/. just draw this section b/. process this section as there's an intersection within it c/. ignore doing this as its going to be removed anyway by the operation
although it would need to have some control vars to be able to set the level of segmentation , and may run the risk of increasing render times on simple objects as well as being almost a complete rewrite of the render code :(
i do remember using povray back in the days when i had a 386sx with 387 co proc, and 24 hours to render a single 1024*768 image
On Mon, Jul 15, 2013 at 1:11 AM, nop head <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by Kenneth R Sloan
the line segment / line / path is something that rhud has sort of touched on with the loop , loop extrude , but would be just as valid in the hull & minowski commands as would arc and other basic line drawing tools with functions to spline/bsline and the ability to group union() them to form paths paths in that form would be very useful as there would be easy to convert to tool paths for cnc gcode as well as allowing for the normal output to be used for 3d printing /stl objects On Mon, Jul 15, 2013 at 3:53 AM, Kenneth R Sloan <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
In reply to this post by Kenneth R Sloan
There are several issues here:
* back-end algorithm development * front-end (visible) language issues I haven't studied the CGAL library in any detail, but I would guess that it can _already handle_ the types of suggestions that we've been making here -- e.g., 'half'-planes, 3D lines/half-lines/line segments, 3D points, etc. I'd be very surprised if the CGAL library didn't already support intersection/difference with 'incomplete' (non-watertight) objects such as half-planes, 'polyhedra' with only a single oriented triangle, single isolated 3D points, etc. Re finite watertight objects: This is a great goal for the end product to be spit out as .stl, but it is very inconvenient for intermediate processing. This situation reminds me a lot of the mathematics of 'intervals' on the real line, which I have studied extensively in conjunction with so-called 'interval arithmetic'. The naive conception of intervals are 'closed' intervals like [1,2], which means all x, such that 1<=x<=2. However, even a little bit of fiddling with closed intervals tells you that you really also want 'open' intervals such as (1,2), which means all x, such that 1<x<2. But a bit more fiddling with intervals, and you realize you then also want 'half-open/half-closed' intervals like (1,2] and [1,2). But then you sit down to implement 'intervals' on a computer, and you find that the simplest way to implement them is as intersections of 'half-intervals' like (-oo,2), meaning all x such that x<2, (-oo,2], meaning all x such that x<=2, (1,+oo), meaning all x such that 1<x, and [1,+oo), meaning all x such that 1<=x. Thus, a simple closed interval [1,2] is 'really' the interval INTERSECT[ (-oo,2], [1,+oo) ], if you look inside the computer. The nice thing about IEEE floating point representations is that they _do_ have representations for -oo and +oo, so that one can easily represent these intervals using standard IEEE FP representations. Precisely the same thing should happen with so-called 'watertight' CAD models and CSG operations. --- Re language issues: As I mentioned before, there are 2 types of language issues: fundamental and/or 'atomic' operations, which can't be emulated by any other constructs; and convenient operations, which special case standard patterns to improve readability and construction. For example, as discussed before, matrix multiply is a fundamental operations, and 'translate', 'rotate', 'scale' are implemented in terms of matrix multiply. For such 'convenient' operations, we should use so-called 'macros', which provide for 'syntactic sugar' to make these convenient operations even easier to write down. --- P.S. There is a way to build 'watertight' models in an incremental way, but traditional CSG ("Constructive Solid Geometry") isn't that way. (Hint: consider what happens when a 3D triangular mesh is 'simplified' by removing vertices, edges, and/or faces (while preserving Euler's relationship); now _reverse_ these simplification operations one-by-one and you'll get a method for moving from one watertight model to another watertight model without ever having to deal with non-watertight intermediate steps.) At 07:53 PM 7/14/2013, Kenneth R Sloan wrote: >"Fitting into the language" is the problem. > >OpenSCAD was designed and built from a particular point of view. It now has a tradition and a set of standard workarounds - but it is in many ways limited by the original ambitions. > >The final product is (more-or-less) constrained to be a watertight manifold surface. _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
interesting related library I stumbled apon.... sorry if its been mentioned before: a C++ library for boolean operations between two arbitrary polygonal meshes. supports points, faces, open surfaces, touching, etc, and specifically mentions being used for CSG operations. https://code.google.com/p/carve/ Buzz. On 15 July 2013 16:10, Henry Baker <[hidden email]> wrote: There are several issues here: _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org - https://flattr.com/thing/121566 |
Free forum by Nabble | Edit this page |