most primitive primitive (feature request)

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

most primitive primitive (feature request)

Lukasz Stelmach
-----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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Henry Baker
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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

David Powell
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:
* 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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

David Powell
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:
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:
* 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



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

nophead
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:
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:
* 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


_______________________________________________
OpenSCAD mailing list
[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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Lukasz Stelmach
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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Whosawhatsis
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:

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

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.


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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

nophead
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:
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:

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

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.


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


_______________________________________________
OpenSCAD mailing list
[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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Lukasz Stelmach
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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Lukasz Stelmach
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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Lukasz Stelmach
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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Lukasz Stelmach
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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

nophead
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:
-----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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Whosawhatsis
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:

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



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

nophead
Yes that would fit into the language much better.


On 15 July 2013 01:04, whosawhatsis <[hidden email]> wrote:
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:

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



_______________________________________________
OpenSCAD mailing list
[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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Kenneth R Sloan
"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.

--
Kenneth Sloan
[hidden email]


On Jul 15, 2013, at 01:11 , nop head <[hidden email]> wrote:

Yes that would fit into the language much better.


On 15 July 2013 01:04, whosawhatsis <[hidden email]> wrote:
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:

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

_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

David Powell
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:
Yes that would fit into the language much better.


On 15 July 2013 01:04, whosawhatsis <[hidden email]> wrote:
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:

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



_______________________________________________
OpenSCAD mailing list
[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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

David Powell
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:
"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.

--
Kenneth Sloan
[hidden email]


On Jul 15, 2013, at 01:11 , nop head <[hidden email]> wrote:

Yes that would fit into the language much better.


On 15 July 2013 01:04, whosawhatsis <[hidden email]> wrote:
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:

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

_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[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


_______________________________________________
OpenSCAD mailing list
[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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

Henry Baker
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
Reply | Threaded
Open this post in threaded view
|

Re: most primitive primitive (feature request)

buzz
interesting related library I stumbled apon.... sorry if its been mentioned before:

https://code.google.com/p/carve/
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.

Buzz.

On 15 July 2013 16:10, Henry Baker <[hidden email]> wrote:
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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
12