discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

how does OpenSCAD represent edges and how are spheres constructed?

B
boxcarmib
Tue, Feb 20, 2018 1:55 AM

I am fooling around with creating my own spheres from a points array, so I
took a look at the performance of sphere() with "show edges" turned on. I
noticed that it doesn't show edges for the top and bottom of the sphere...
so then I took a look at the output of cylinder() and cube() modules.
However if you create the same object with linear_extrude() using either
circle() or square() as the primitive, the display in F5 shows all the
triangles of the mesh.
This inconsistency isn't really a big thing to me, but it doesn't give me
much insight into how a sphere is formed... specifically how is the diameter
for the top and bottom of the sphere determined? I had thought that a sphere
might be topped and bottomed by a cone construction, but that doesn't seem
to be the case.
If you superimpose a cube over a sphere of the same size, you can also see
that there is inaccuracy at the top and bottom of the sphere which only
becomes more pronounced if you scale a sphere (i.e. construct spheres at the
size you ultimately require, don't scale).
So I'm thinking that the sphere generator I create should go for the cone
top and bottom so that the tip of the cone lies exactly on the measurement
specified, or do you folks think that's being overly picky? If I don't go
for the cone, then where should the truncation of the height dimension fall?
Just wanted the thoughts of the community on this.
Here's some code that displays the behaviour I've been talking about (just
remember to turn on "show edges")

$fn = 30;

cylinder(r = 5, h = 5);

translate([15,0,0])
linear_extrude(5)
circle(5);

translate([0,15,0]) {
cube([10,10,10], center = true);

translate([15,0,0])
	linear_extrude(10)
		square([10,10], center = true);

}

translate([35,10,0]) {
sphere(10);
#cube([20,20,20], center = true);
}

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

I am fooling around with creating my own spheres from a points array, so I took a look at the performance of sphere() with "show edges" turned on. I noticed that it doesn't show edges for the top and bottom of the sphere... so then I took a look at the output of cylinder() and cube() modules. However if you create the same object with linear_extrude() using either circle() or square() as the primitive, the display in F5 shows all the triangles of the mesh. This inconsistency isn't really a big thing to me, but it doesn't give me much insight into how a sphere is formed... specifically how is the diameter for the top and bottom of the sphere determined? I had thought that a sphere might be topped and bottomed by a cone construction, but that doesn't seem to be the case. If you superimpose a cube over a sphere of the same size, you can also see that there is inaccuracy at the top and bottom of the sphere which only becomes more pronounced if you scale a sphere (i.e. construct spheres at the size you ultimately require, don't scale). So I'm thinking that the sphere generator I create should go for the cone top and bottom so that the tip of the cone lies exactly on the measurement specified, or do you folks think that's being overly picky? If I don't go for the cone, then where should the truncation of the height dimension fall? Just wanted the thoughts of the community on this. Here's some code that displays the behaviour I've been talking about (just remember to turn on "show edges") $fn = 30; cylinder(r = 5, h = 5); translate([15,0,0]) linear_extrude(5) circle(5); translate([0,15,0]) { cube([10,10,10], center = true); translate([15,0,0]) linear_extrude(10) square([10,10], center = true); } translate([35,10,0]) { sphere(10); #cube([20,20,20], center = true); } -- Sent from: http://forum.openscad.org/
N
NateTG
Tue, Feb 20, 2018 3:17 AM

You can look at:

https://github.com/thehans/FunctionalOpenSCAD/blob/master/functional.scad

For a sphere construction.  It matches up pretty well to the one in
OpenSCAD.

There are some drawbacks to that approach - the same project has some
alternative sphere constructions.

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

You can look at: https://github.com/thehans/FunctionalOpenSCAD/blob/master/functional.scad For a sphere construction. It matches up pretty well to the one in OpenSCAD. There are some drawbacks to that approach - the same project has some alternative sphere constructions. -- Sent from: http://forum.openscad.org/
N
NateTG
Tue, Feb 20, 2018 3:19 AM

You can look at:

https://github.com/thehans/FunctionalOpenSCAD/blob/master/functional.scad

For a sphere construction.  It matches up pretty well to the one in
OpenSCAD.

The same project has some alternative sphere constructions.

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

You can look at: https://github.com/thehans/FunctionalOpenSCAD/blob/master/functional.scad For a sphere construction. It matches up pretty well to the one in OpenSCAD. The same project has some alternative sphere constructions. -- Sent from: http://forum.openscad.org/
T
Troberg
Tue, Feb 20, 2018 8:16 AM

Isn't it simpler to simply add more polygons to the sphere?

sphere(100,$fn=10); //Looks like crap

translate([240,0,0])
sphere(100,$fn=50); //Looks pretty good

translate([480,0,0])
sphere(100,$fn=500); //Looks smooth

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

Isn't it simpler to simply add more polygons to the sphere? sphere(100,$fn=10); //Looks like crap translate([240,0,0]) sphere(100,$fn=50); //Looks pretty good translate([480,0,0]) sphere(100,$fn=500); //Looks smooth -- Sent from: http://forum.openscad.org/
P
Parkinbot
Tue, Feb 20, 2018 12:43 PM

OpenSCAD internally generates polyhedrons for those primitives and obviously
uses the rule that each vertex v satisfies the respective equation. Thus all
other points on the 2-manifold don't.

You can see this by

circle(5, $fn=4);
#square(10, center = true);

From an approximation error point of view this might not be the best

solution, but it is how it is.

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

OpenSCAD internally generates polyhedrons for those primitives and obviously uses the rule that each vertex v satisfies the respective equation. Thus all other points on the 2-manifold don't. You can see this by circle(5, $fn=4); #square(10, center = true); >From an approximation error point of view this might not be the best solution, but it is how it is. -- Sent from: http://forum.openscad.org/
GC
Gary Crowell
Tue, Feb 20, 2018 4:08 PM

There's this: https://www.thingiverse.com/thing:1484333

On Tue, Feb 20, 2018 at 5:43 AM, Parkinbot rudolf@parkinbot.com wrote:

OpenSCAD internally generates polyhedrons for those primitives and
obviously
uses the rule that each vertex v satisfies the respective equation. Thus
all
other points on the 2-manifold don't.

You can see this by

circle(5, $fn=4);
#square(10, center = true);

From an approximation error point of view this might not be the best
solution, but it is how it is.

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


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

There's this: https://www.thingiverse.com/thing:1484333 On Tue, Feb 20, 2018 at 5:43 AM, Parkinbot <rudolf@parkinbot.com> wrote: > OpenSCAD internally generates polyhedrons for those primitives and > obviously > uses the rule that each vertex v satisfies the respective equation. Thus > all > other points on the 2-manifold don't. > > You can see this by > > circle(5, $fn=4); > #square(10, center = true); > > From an approximation error point of view this might not be the best > solution, but it is how it is. > > > > > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > -- ---------------------------------------------- Gary A. Crowell Sr., P.E. <http://www.ipels.idaho.gov/>, CID+ <http://dc.ipc.org/html/default.htm> Linkedin <http://www.linkedin.com/in/garyacrowellsr> Elance <http://www.linkedin.com/redirect?url=http%3A%2F%2Fgaryacrowellsr%2Eelance%2Ecom&urlhash=kJm9> KE7FIZ <http://www.arrl.org> Things <http://www.thingiverse.com/garyacrowellsr/designs> RocketryCNC <https://www.etsy.com/shop/RocketryCNC?ref=l2-shopheader-name>
RP
Ronaldo Persiano
Tue, Feb 20, 2018 4:41 PM

The sphere polyhedral model in OpenSCAD is based on a subdivision by
meridians and parallels. The number of adjacencies of a vertex in that
subdivision (in quads) is four except for the top vertex of the cones at
the top and bottom of the polyhedron. For high values of $fn, two vertices
have high number of adjacencies, the adjacent triangles are narrow and with
about the same normal. This may cause inaccuracies and issues on boolean
operations. Other sphere subdivisions, like the geodesic one, would be
preferable: they have low number of adjacencies, a few "fat" triangle
shapes and a better vertex distribution on the sphere surface. However,
some people argue that this should be done in user space.

The sphere polyhedral model in OpenSCAD is based on a subdivision by meridians and parallels. The number of adjacencies of a vertex in that subdivision (in quads) is four except for the top vertex of the cones at the top and bottom of the polyhedron. For high values of $fn, two vertices have high number of adjacencies, the adjacent triangles are narrow and with about the same normal. This may cause inaccuracies and issues on boolean operations. Other sphere subdivisions, like the geodesic one, would be preferable: they have low number of adjacencies, a few "fat" triangle shapes and a better vertex distribution on the sphere surface. However, some people argue that this should be done in user space.
NH
nop head
Tue, Feb 20, 2018 7:48 PM

It tends to be important that spheres have vertices spot on the six 90
degree points so that when you hull them to make rounded cubes they have
the correct dimensions.

On 20 February 2018 at 16:41, Ronaldo Persiano rcmpersiano@gmail.com
wrote:

The sphere polyhedral model in OpenSCAD is based on a subdivision by
meridians and parallels. The number of adjacencies of a vertex in that
subdivision (in quads) is four except for the top vertex of the cones at
the top and bottom of the polyhedron. For high values of $fn, two vertices
have high number of adjacencies, the adjacent triangles are narrow and with
about the same normal. This may cause inaccuracies and issues on boolean
operations. Other sphere subdivisions, like the geodesic one, would be
preferable: they have low number of adjacencies, a few "fat" triangle
shapes and a better vertex distribution on the sphere surface. However,
some people argue that this should be done in user space.


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

It tends to be important that spheres have vertices spot on the six 90 degree points so that when you hull them to make rounded cubes they have the correct dimensions. On 20 February 2018 at 16:41, Ronaldo Persiano <rcmpersiano@gmail.com> wrote: > The sphere polyhedral model in OpenSCAD is based on a subdivision by > meridians and parallels. The number of adjacencies of a vertex in that > subdivision (in quads) is four except for the top vertex of the cones at > the top and bottom of the polyhedron. For high values of $fn, two vertices > have high number of adjacencies, the adjacent triangles are narrow and with > about the same normal. This may cause inaccuracies and issues on boolean > operations. Other sphere subdivisions, like the geodesic one, would be > preferable: they have low number of adjacencies, a few "fat" triangle > shapes and a better vertex distribution on the sphere surface. However, > some people argue that this should be done in user space. > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >
N
NateTG
Tue, Feb 20, 2018 8:44 PM

nophead wrote

It tends to be important that spheres have vertices spot on the six 90
degree points so that when you hull them to make rounded cubes they have
the correct dimensions
...

Ideally they also have seams that correspond to octahedron edges.  Then you
can use the octahedron/cube duality for the edges of the rounded cube as
well.

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

nophead wrote > It tends to be important that spheres have vertices spot on the six 90 > degree points so that when you hull them to make rounded cubes they have > the correct dimensions > ... Ideally they also have seams that correspond to octahedron edges. Then you can use the octahedron/cube duality for the edges of the rounded cube as well. -- Sent from: http://forum.openscad.org/
HJ
Hugo Jackson
Tue, Feb 20, 2018 8:58 PM

Hey, thanks to all of you for your input on this… clearly nothing is simple… I guess life would be a lot easier if we lived in flatland.
I hadn’t thought of the value of hulling spheres so I can see how a ‘proper’ sphere with cone caps would make that problematic.
I was hoping to craft a sphere module that could be used with more versatility, but it’s obvious that objects need to be crafted with more specificity for the context.

On Feb 20, 2018, at 11:48 AM, nop head nop.head@gmail.com wrote:

It tends to be important that spheres have vertices spot on the six 90 degree points so that when you hull them to make rounded cubes they have the correct dimensions.

On 20 February 2018 at 16:41, Ronaldo Persiano <rcmpersiano@gmail.com mailto:rcmpersiano@gmail.com> wrote:
The sphere polyhedral model in OpenSCAD is based on a subdivision by meridians and parallels. The number of adjacencies of a vertex in that subdivision (in quads) is four except for the top vertex of the cones at the top and bottom of the polyhedron. For high values of $fn, two vertices have high number of adjacencies, the adjacent triangles are narrow and with about the same normal. This may cause inaccuracies and issues on boolean operations. Other sphere subdivisions, like the geodesic one, would be preferable: they have low number of adjacencies, a few "fat" triangle shapes and a better vertex distribution on the sphere surface. However, some people argue that this should be done in user space.


OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Hey, thanks to all of you for your input on this… clearly nothing is simple… I guess life would be a lot easier if we lived in flatland. I hadn’t thought of the value of hulling spheres so I can see how a ‘proper’ sphere with cone caps would make that problematic. I was hoping to craft a sphere module that could be used with more versatility, but it’s obvious that objects need to be crafted with more specificity for the context. > On Feb 20, 2018, at 11:48 AM, nop head <nop.head@gmail.com> wrote: > > It tends to be important that spheres have vertices spot on the six 90 degree points so that when you hull them to make rounded cubes they have the correct dimensions. > > On 20 February 2018 at 16:41, Ronaldo Persiano <rcmpersiano@gmail.com <mailto:rcmpersiano@gmail.com>> wrote: > The sphere polyhedral model in OpenSCAD is based on a subdivision by meridians and parallels. The number of adjacencies of a vertex in that subdivision (in quads) is four except for the top vertex of the cones at the top and bottom of the polyhedron. For high values of $fn, two vertices have high number of adjacencies, the adjacent triangles are narrow and with about the same normal. This may cause inaccuracies and issues on boolean operations. Other sphere subdivisions, like the geodesic one, would be preferable: they have low number of adjacencies, a few "fat" triangle shapes and a better vertex distribution on the sphere surface. However, some people argue that this should be done in user space. > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org> > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org