Checking your polyhedron with vnf_validate() from BOSL2 reveals that you
have T-junctions, where a segment terminates in the middle of another
segment.  That's illegal.  You need to split the "top" of the T into two
segments.

ECHO: "ERROR T_JUNCTION (magenta): Vertex is mid-edge on another Face at
[[-15, -15, 2.5]] indices: [20]"

ECHO: "ERROR T_JUNCTION (magenta): Vertex is mid-edge on another Face at
[[-15, 5, 2.5]] indices: [21]"

See here:

https://github.com/revarbat/BOSL2/wiki/vnf.scad#functionmodule-vnf_validate

(Note: there is currently a bug in vnf_validate that it gives a bad picture
if your polyhedron has duplicate vertices in the vertex list. Workaround is
to use vnf_merge_points() first.)

Bad vertices are shown as oversized pink spheres below:

[image: image.png]

On Sat, Dec 3, 2022 at 5:37 PM jay@jdnd.co.uk wrote:

thank you for your response, i think i have already tried that though, i
thought the code i had posted already had that fix sorry.

this still fails

     polyhedron(points=p1, faces=[
         [16, 17, 9,  8],
         [8,  9,  5,  4],
         [4,  5,  1,  0],
         [1,  13, 12, 0],

         [17, 16, 20, 21],
         [21, 20, 12, 13],

         [16, 8,  4,  20],
         [20, 4,  0,  12],
         [9, 17, 21,  5],
         [5, 21, 13,  1],
         ]);

On 2022-12-03 22:47, Adrian Mariano wrote:

i take that back,

when i remove the line

showPoints(p1);

it does not fail.

im sorry, possibly i got confused having to comment in/out
showPoints(p1) all the time.

this is the method, im using it for testing, it wont render but dosent
need to, maby there is a better way of displaying the points that would
render, so that i dont get confused having to comment it out all the
time. very sorry for having to ask, it has done my head in for hours
trying to work out what i was doing wrong. many thanks again for the
help.

module showPoints(v)
{
for (i = [0: len(v)-1])
{
translate(v[i]) color("red")
text(str(i), font = "Courier New", size=1.5);
}
}

On 2022-12-03 22:47, Adrian Mariano wrote:

if you can arrange the points like below, it would be much easier to make
polyhedron

module make_polyhedron(surf)
let(l=len(surf[0]),
points=[for(j=[0:len(surf)-1])each surf[j]],
faces=[each [for(j=[0:len(surf)-1])if(j==0)[for(i=[0:l-1])i+jl]],
each [for(j=[0:len(surf)-2])each
[for(i=[0:l-1])let(i_plus=i<l-1?i+1:0)[i+lj,i+l+lj,i_plus+l+lj,i_plus+lj]]],
each [for(j=[0:len(surf)-1])if(j==len(surf)-1)[for(i=[l-1:-1:0])i+lj]]
]
)
polyhedron(points,faces,convexity=10);

translate([-5,-1,4.7])
cube();

p1=[[[-15,-15,0],[0,0,0],[0,5,0],[-15,5,0]],
[[-15,-15,2.5],[-10,-10,2.5],[-10,5,2.5],[-15,5,2.5]],
[[-15,-15,5],[0,0,5],[0,5,5],[-15,5,5]]];

make_polyhedron(p1);

On Sun, 4 Dec 2022 at 04:07, jay@jdnd.co.uk wrote:

To show the difference it has to draw the negative object, When it is too
close to the camera some of its faces get clipped and the difference
doesn't work. If you switch to orthogonal view instead of perspective it
will work.

On Tue, 20 Dec 2022 at 16:11, jay@jdnd.co.uk wrote:

Yes, OpenCSG is used to draw the preview without calculating any of the
geometry. It just draws all the primitive objects with different graphics
modes.

On Tue, 20 Dec 2022 at 16:40, jay jay@jdnd.co.uk wrote:

On Tue, Dec 20, 2022 at 04:42:26PM +0000, nop head wrote:

What it boils down to is that most people don't understand how say "a
cube" ends up on the screen. A quick computer graphics lesson:

Let us work towards the situation where we put:

difference () {cube (10);translate ([5,5,5]) cube (10);}

on the screen. But first lets do the first cube only.

In practice, these things often only work on triangles, Not sure if
nowadays that's still true, but for now lets pretend we can work with
squares too.

The cube has 6 faces. For each face, we first compare the normal to
the viewing vector. If it is facing away from the camera(i.e. angle
between them is less than 90 degrees), we can ignore it.

This leaves us with just three faces we need to draw. We transform the
cube's coorinates to screen coordinates and simply draw the pixels
inside the quadrilaterals with the proper color depending on the angle
between the normal, viewing angle and the light source.

Now if we want to draw a second cube (not a difference, like above,
but a union), things get a bit fishy: Depending on the drawing order
you get to see faces that should be obscured by the other
cube. So... for each pixel, we calculate the distance from the viewing
plane and store that together with the color of the pixel.

Now while drawing a pixel instead of just drawing it, we compare the
depth value. If the current depth value is further away than what's
already drawn, we ignore this pixel of this face, otherwise we draw as
normal and update the depth value.

Now you can pretty quickly get a reasonable preview for multiple
objects combined.

But how to draw the difference?  For the "negative" cube in my example
case we need to turn things around: We ignore faces pointing towards
us, and draw faces pointing away from us. Also the depth rule turns
around: We only draw pixels that are DEEPER than the pixel already
drawn.

Now this is going to be "messy" to implement. Corner cases everywhere
and things like that, but this is the principle. All in all, this is
the X billion pixels per second that graphics cards claim to be able
to handle. So this also includes all the pixels that do NOT end up on
your screen.

It also explains the Z-fighting that you sometimes see: Two planes
in theory at precisely the same depth so it depends on floating point
rounding errors if one is in front of the other or not.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.