Getting more information

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

Re: Getting more information

adrianv
Is the base of the whole arch structure (left side) supposed to be coplanar?
It doesn't look coplanar in your image.  

Can you reduce the transition steps to 2 or 1 (I'm not sure how you are
counting so I don't know what is the minimum sensible option here).  The
point is to really push things to the minimal example that triggers your
problem, so that you can really inspect the example carefully---for example
look at every vertex coordinate in your polyhedron and every face list by
hand and see if you notice anything odd.  

Are you generating this by using the skin() module from
list-comprehension-demos?


DanS wrote

> So I was taking your idea of doing less.  Instead of 105 transition steps
> I
> did 15.
> If I union it with a cube it only works if they don't touch at all, if
> they
> do touch it seems to blow up and render nothing.
>
> If I take the more simple version and do Preview -> Thrown together I
> don't
> see any pink / purple facets (but the edges are all pink purple) the one
> thing that strikes me as very odd is that each arch should be planar.  I
> would intuitively expect no triangles on the ends yet all the vertices on
> the ends are part of triangles.  Of course, it might also do those
> triangles if all the vertexes are planar, I just don't know.
>
> [image: image.png]
>
> On Thu, Jul 4, 2019 at 6:39 PM adrianv <

> avm4@

> > wrote:
>
>> DanS wrote
>> > yes, I've simplified it to where it seems to work.  So I know it breaks
>> > down where I do "wave" which interpolates between one curve and another
>> > using sin() (to give a smooth curve rather than a linear transition).
>>
>> Is it possible that you have very skinny facets showing up in pink
>> between
>> larger facets?   It just takes a single bad facet to ruin your entire
>> model.
>>
>> If the interpolation process is at fault can you use a simpler polygon as
>> the base for the interpolation?
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> image.png (13K)
> <http://forum.openscad.org/attachment/26727/0/image.png>





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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
In reply to this post by nophead
If there is a hole I don't seem to be able to see into it.  I think what you are implying is that each of the "edges" I see is actually a rectangular hole.  That is possible but I can't prove or disprove it.

I'm trying to do the interpolations with the case that each arch segment is also on an arched pathway.  Maybe I'll see if I can get an error on interpolated arches on a straight line path, might be easier for me to view in preview.

On Thu, Jul 4, 2019 at 7:03 PM nop head <[hidden email]> wrote:
I don't think you should see purple edges. Do they meet or is there a hole through which you can see the purple interior?


On Thu, 4 Jul 2019, 23:51 Dan Shriver, <[hidden email]> wrote:
So I was taking your idea of doing less.  Instead of 105 transition steps I did 15.
If I union it with a cube it only works if they don't touch at all, if they do touch it seems to blow up and render nothing.

If I take the more simple version and do Preview -> Thrown together I don't see any pink / purple facets (but the edges are all pink purple) the one thing that strikes me as very odd is that each arch should be planar.  I would intuitively expect no triangles on the ends yet all the vertices on the ends are part of triangles.  Of course, it might also do those triangles if all the vertexes are planar, I just don't know.

image.png

On Thu, Jul 4, 2019 at 6:39 PM adrianv <[hidden email]> wrote:
DanS wrote
> yes, I've simplified it to where it seems to work.  So I know it breaks
> down where I do "wave" which interpolates between one curve and another
> using sin() (to give a smooth curve rather than a linear transition).

Is it possible that you have very skinny facets showing up in pink between
larger facets?   It just takes a single bad facet to ruin your entire model. 

If the interpolation process is at fault can you use a simpler polygon as
the base for the interpolation?




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

MichaelAtOz
Administrator
In reply to this post by nophead
> ERROR: CGAL error

Any CGAL error is almost guaranteed to be either bad polygon/polyhedron, or
import() of a bad .stl file.

In Thrown-together any purple is bad.

It is difficult to debug without seeing your code.



-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
In reply to this post by adrianv
Yes, skin is from list comprehension.  Or at least I believe so.

Each arch is supposed to be coplanar.

I created a new function (that I felt would help me view things) by not centering each arch on top of a path that is itself an arch.  When I do that I can render a union with a cube.  This is starting to suggest the problem comes about when putting each arch on a path that is itself an arch (but I thought I tested and cleared that earlier :( ).

Even in this case (where I can render a union with the cube, preview -> thrown together shows pink purple edges)

Nop / MichaelAtOz:
I only see the pink/purple color in throw together either on the edges or if I am already inside of something (that is the viewpoint is partway inside the arch)

MichaelAtOz:
I can show the code to people but it isn't pretty and rightfully people have said in the past "I don't want to debug that"

On Thu, Jul 4, 2019 at 7:13 PM adrianv <[hidden email]> wrote:
Is the base of the whole arch structure (left side) supposed to be coplanar?
It doesn't look coplanar in your image. 

Can you reduce the transition steps to 2 or 1 (I'm not sure how you are
counting so I don't know what is the minimum sensible option here).  The
point is to really push things to the minimal example that triggers your
problem, so that you can really inspect the example carefully---for example
look at every vertex coordinate in your polyhedron and every face list by
hand and see if you notice anything odd. 

Are you generating this by using the skin() module from
list-comprehension-demos?


DanS wrote
> So I was taking your idea of doing less.  Instead of 105 transition steps
> I
> did 15.
> If I union it with a cube it only works if they don't touch at all, if
> they
> do touch it seems to blow up and render nothing.
>
> If I take the more simple version and do Preview -> Thrown together I
> don't
> see any pink / purple facets (but the edges are all pink purple) the one
> thing that strikes me as very odd is that each arch should be planar.  I
> would intuitively expect no triangles on the ends yet all the vertices on
> the ends are part of triangles.  Of course, it might also do those
> triangles if all the vertexes are planar, I just don't know.
>
> [image: image.png]
>
> On Thu, Jul 4, 2019 at 6:39 PM adrianv &lt;

> avm4@

> &gt; wrote:
>
>> DanS wrote
>> > yes, I've simplified it to where it seems to work.  So I know it breaks
>> > down where I do "wave" which interpolates between one curve and another
>> > using sin() (to give a smooth curve rather than a linear transition).
>>
>> Is it possible that you have very skinny facets showing up in pink
>> between
>> larger facets?   It just takes a single bad facet to ruin your entire
>> model.
>>
>> If the interpolation process is at fault can you use a simpler polygon as
>> the base for the interpolation?
>>
>>
>>
>>
>> --
>> Sent from: http://forum.openscad.org/
>>
>> _______________________________________________
>> OpenSCAD mailing list
>>

> Discuss@.openscad

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> image.png (13K)
> &lt;http://forum.openscad.org/attachment/26727/0/image.png&gt;





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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

adrianv
In reply to this post by MichaelAtOz
MichaelAtOz wrote
>> ERROR: CGAL error
>
> Any CGAL error is almost guaranteed to be either bad polygon/polyhedron,
> or
> import() of a bad .stl file.
>
> In Thrown-together any purple is bad.
>
> It is difficult to debug without seeing your code.

I think he posted the code before and it was several hundred lines and
pretty chaotic.  That's why I'm pushing for simplifications instead.  

For curiosity I was able to get pink "edges" by leaving a small gap.   One
of the octahedra has gaps along four of its edges (not all) and this shows
up as pink "edges" in the thrown together view.  

vertices = [[0,0,-1],   //0
            [0,0,1],    // 1
            [1,0,0],    // 2
            [0,1,0],    // 3
            [-1,0,0],// 4
            [0,-1,0], //5
            [1,0,.01],    // 6
            [0,1,.01],    // 7
            [-1,0,.01],//8
            [0,-1,.01]]; //9


goodfaces = [[2,5,1], [5,2,0],
         [3,2,1], [2,3,0],
         [4,3,1], [3,4,0],
         [5,4,1], [4,5,0]];


badfaces = [[6,9,1], [5,2,0],
         [7,6,1], [2,3,0],
         [8,7,1], [3,4,0],
         [9,8,1], [4,5,0]];

polyhedron(vertices,faces=goodfaces);
translate([4,0,0]) polyhedron(vertices,faces=badfaces);




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
So here's the thing that has me real confused now.  I thought that union() with a cube was guaranteed to not work if things are bad.

If I do the interpolation of arch types (using sin() to make it curved) but I put all the arches along a linear path (not a path that is part of an arch), I can union it with a cube and get it to render fine.

Then if I do preview -> thrown together I get the pink / purple (should I say magenta?) edges.
So if union with a cube only renders if things are good, then that would imply magenta edges in preview -> thrown together do not necessarily imply a problem in my version of openscad (I think I have some 2018 release).  I can easily believe that magenta edges could also (under some cases) be rectangular holes or rectangular magenta facets.

On Thu, Jul 4, 2019 at 7:52 PM adrianv <[hidden email]> wrote:
MichaelAtOz wrote
>> ERROR: CGAL error
>
> Any CGAL error is almost guaranteed to be either bad polygon/polyhedron,
> or
> import() of a bad .stl file.
>
> In Thrown-together any purple is bad.
>
> It is difficult to debug without seeing your code.

I think he posted the code before and it was several hundred lines and
pretty chaotic.  That's why I'm pushing for simplifications instead. 

For curiosity I was able to get pink "edges" by leaving a small gap.   One
of the octahedra has gaps along four of its edges (not all) and this shows
up as pink "edges" in the thrown together view. 

vertices = [[0,0,-1],   //0
            [0,0,1],    // 1
            [1,0,0],    // 2
            [0,1,0],    // 3
            [-1,0,0],// 4
            [0,-1,0], //5
            [1,0,.01],    // 6
            [0,1,.01],    // 7
            [-1,0,.01],//8
            [0,-1,.01]]; //9


goodfaces = [[2,5,1], [5,2,0],
         [3,2,1], [2,3,0],
         [4,3,1], [3,4,0],
         [5,4,1], [4,5,0]];


badfaces = [[6,9,1], [5,2,0],
         [7,6,1], [2,3,0],
         [8,7,1], [3,4,0],
         [9,8,1], [4,5,0]];

polyhedron(vertices,faces=goodfaces);
translate([4,0,0]) polyhedron(vertices,faces=badfaces);




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

MichaelAtOz
Administrator
In reply to this post by DanS
DanS wrote
> MichaelAtOz:
> I can show the code to people but it isn't pretty and rightfully people
> have said in the past "I don't want to debug that"

I'll have a first look, no guarantees tho.



-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
use <list-comprehension/skin.scad>;
use <nSpline/splines.scad>;
use <scad-utils/transformations.scad>
use <scad-utils/lists.scad>


function echoit(x) = echo(x) x;
//function echoit2(y,x) = echo(y,x) x; //debug version
function echoit2(y,x) =  x; //debug off
function echoit3(y,x) = x; //debug off
//function echoit4(y,x) = echo(y,x) x; //debug version
function echoit4(y,x) =  x; //debug off
function echoit5(y,x) = echo(y,x) x; //debug

function innerAngle(radius, thickness, angle) = atan(((radius-thickness)*sin(angle))/((radius-thickness)*cos(angle)));

function partitionNum(pn,points) =
    (pn < (points-2)/4) ? 0 :         //OUTER RIGHT
    (pn < (points-2)/4 + 1)  ? 1 :    //OUTER TOP
    (pn < (points-2)/2 + 1) ? 2:      //OUTER LEFT
    (pn < (3*(points-2))/4 + 1) ? 3:  //INNER LEFT
    (pn < (3*(points-2))/4 + 2) ? 4:  //INNER TOP
    5;                                // INNER RIGHT

function subPointNum(points, pointNum, partition) =
 [pointNum,
  1, //doesn't matter
  ((points-2)/2) - pointNum,
  pointNum - points/2,
  1, //doesn't matter
  ((points-1) - pointNum)]
 [partition];
 

//one more point in the outer arcs one less in the inner
function partitionNumNc(pn,points,solid) = (solid) ? (pn < (points)/2) ? 0 :         //OUTER RIGHT
    (pn == (points)/2)  ? 1 :    //OUTER TOP
    2 :
    (pn < (points)/4) ? 0 :         //OUTER RIGHT
    (pn == (points)/4)  ? 1 :    //OUTER TOP
    (pn < ((points)/2)+1) ? 2:      //OUTER LEFT
    (pn < (3*points)/4) ? 3:  //INNER LEFT
    (pn == (3*points)/4) ? 4:  //INNER TOP
    5                                // INNER RIGHT
    ;

function subPointNumNc(points, pointNum, partition) =
 [pointNum,
  1, //doesn't matter
  ((points)/2) - pointNum,
  pointNum - (points/2+1),
  1, //doesn't matter
  ((points-1) - pointNum)]
 [partition];
 

//a roman arch with 4n + 4 points to match an ogee
//no cap arch with 8n points
//use a number of points that is a multiple of 8
 function archXNc(radius, thickness, angle, pointNum, points, solid) = let(inner = innerAngle(radius, thickness, angle),
    partition = partitionNumNc(pointNum,points,solid),
    subPoint = subPointNumNc(points, pointNum, partition),
    steps = (pointNum < (points/2)) ? (((points)/4)) : (((points)/4) - 1))
    [radius * cos(angle/steps * pointNum) - radius * (cos(angle)),
     0,
     -(radius * cos(angle/steps * subPoint) - radius * (cos(angle))), // PTS - 2 EXP + 1
    -(((radius - thickness) * cos((angle/steps) *  subPoint)) - ((radius - thickness)*cos(angle))), //PTS -2  EXP +1
     0,
    (radius - thickness) * cos((angle/steps) *  subPoint) - (radius-thickness)*cos(angle) //PTS - 2 EXP +2
    ]
    [partition];


function archYNc(radius, thickness, angle, pointNum, points, solid) = let(inner = innerAngle(radius, thickness, angle),
    partition = partitionNumNc(pointNum,points,solid),
    subPoint = subPointNumNc(points, pointNum, partition),
    steps = (pointNum < (points/2)) ? ((points)/4) : ((points)/4) - 1)
    [radius * sin(angle/steps * pointNum),
     radius * sin(angle),
     (radius * sin(angle/steps * subPoint)),
     (radius - thickness) * sin( angle/steps * subPoint),
     (radius - thickness) * sin(angle),
     (radius - thickness) * sin((angle*subPoint)/steps)
    ]
    [partition];

     
  //use this with a no-cap ogee as this works out to
  //be 4n +  4 points which meshes with 8n of a no cap ogee
  // 8, 12, 16, 20,....
  // you will have to use ODD N values to match with
  // a linear progression of 8n
  // (4m)+ 4 = 8n for 1 on both sides 3m=2n; 5m = 3n etc
// This function actuall works on ugly numbers 6 + 4(n) points: 10, 14, 18, 22 ...
function romanArchNc(radius, thickness, angle, pointCnt, solid = false)
  = (solid) ? [ for (i = [0:1:(pointCnt/2 -1)]) [archXNc(radius, thickness, angle, i, pointCnt, solid), archYNc(radius, thickness, angle, i, pointCnt, solid)] ] : [ for (i = [0:1:(pointCnt-1)]) [archXNc(radius, thickness, angle, i, pointCnt, solid), archYNc(radius, thickness, angle, i, pointCnt, solid)] ];



//the second half is missing one point, figure it out...
//romanArch(20, 1, 70, 200);



//8n (if capwidth = 0); 8n + 2 otherwise
function ogeepoly(width, thickness, lowerradius, upperradius, points, solid = false, capwidth = 0.0, apexangle = 45.0) =
    let(
    // Angle extended by the arcs
    lowerphi = 180.0 - acos((0.5*(width - capwidth) - lowerradius - thickness - upperradius * cos(0.5*apexangle)) / (lowerradius + thickness + upperradius)),
    upperphi = lowerphi - 0.5 * apexangle,
    apexhalf = 0.5 * apexangle,

    // Number of points per lower arc
    lowerpoints = echoit2("lowerpoints ",round((capwidth > 0.0) ? lowerphi*(points-4)/(8*lowerphi-4*apexangle) : lowerphi*(points-2)/(8*lowerphi-4*apexangle))),

    // Actual number of points in the upper arc
    uppertemp = echoit2("uppertemp ",round((capwidth > 0.0) ? (lowerphi-apexangle)*(points-4)/(8*lowerphi-4*apexangle) : (lowerphi-apexangle)*(points-2)/(8*lowerphi-4*apexangle))),
    targetpoints = echoit2("targetpoints ", (apexangle > 0.0) ? points - 5 : points - 2),
    upperpoints = echoit2("upperpoints ",(targetpoints - 4*(lowerpoints + uppertemp) >= -1) ? uppertemp + 1 : uppertemp),

    // Key horizontal coordinates. Note: w0=x1, w6=x2
    w0 = 0.5*width - thickness - lowerradius,
    w1 = 0.5*capwidth,
    w2 = w0 + lowerradius * cos(lowerphi),
    w3 = w0 + (lowerradius + thickness) * cos(lowerphi),
    w4 = w0 + lowerradius,
    w5 = w0 + lowerradius + thickness,
    w6 = w0 + (lowerradius + thickness + upperradius) * cos(lowerphi),
   
    // Key vertical coordinates. Note: y1=h0=0, y2=h6
    h6 = (lowerradius + thickness + upperradius) * sin(lowerphi),
    h5 = h6 - upperradius * sin(apexhalf),
    h4 = h5 - 0.5*capwidth * tan(apexhalf),
    h3 = h6 - (upperradius + thickness) * sqrt(1.0 - w6*w6 / ((upperradius + thickness) * (upperradius + thickness))),
    h2 = (lowerradius + thickness) * sin(lowerphi),
    h1 = lowerradius * sin(lowerphi),
    h0 = 0.0,
    height = (apexangle > 0.0) ? (h5 + 0.5*capwidth / tan(apexhalf)) : h5,

    // We use the same number of points for the upper inner arc,
    // even though it is a bit smaller angle.
    innertheta = acos(w6 / (upperradius + thickness)),
    innerphi = lowerphi - innertheta,

    // Lower Right Outer arc
    lro = echoit3("lro ",[ for (i = [0:1:lowerpoints-1]) [ w0 + (lowerradius + thickness) * cos(i * lowerphi / lowerpoints), h0 + (lowerradius + thickness) * sin(i * lowerphi / lowerpoints) ] ]),
    // Upper Right Outer arc
    uro = echoit3("uro ",[ for (i = [upperpoints-1:-1:0]) [ w6 - upperradius * cos(apexhalf + i * upperphi / upperpoints), h6 - upperradius * sin(apexhalf + i * upperphi / upperpoints) ] ]),
    // Cap
    cap = (capwidth > 0.0) ? [ [ w1, h5 ], [ 0, height ] ] : [],
    // Upper Left Outer arc
    ulo = echoit3("ulo ",[ for (i = [0:1:upperpoints-1]) [ -w6 + upperradius * cos(apexhalf + i * upperphi / upperpoints), h6 - upperradius * sin(apexhalf + i * upperphi / upperpoints) ] ]),
    // Lower Left Outer arc
    //incorrectly 4 pts
    //changing loop first contition to lowerpoints-1 from "lowerpoints"
    llo = echoit3("llo ",[ for (i = [lowerpoints-1:-1:0]) [ -w0 - (lowerradius + thickness) * cos(i * lowerphi / lowerpoints), h0 + (lowerradius + thickness) * sin(i * lowerphi / lowerpoints) ] ]),
    // Lower Left Inner arc
    lli = (solid) ? [] : [ for (i = [0:1:lowerpoints-1]) [ -w0 - lowerradius * cos(i * lowerphi / lowerpoints), h0 + lowerradius * sin(i * lowerphi / lowerpoints) ] ],
    // Upper Left Inner arc
    uli = (solid) ? [] : [ for (i = [upperpoints-1:-1:0]) [ -w6 + (upperradius + thickness) * cos(innertheta + i * innerphi / upperpoints), h6 - (upperradius + thickness) * sin(innertheta + i * innerphi / upperpoints) ] ],
    // Upper Right Inner arc
    uri = (solid) ? [] : [ for (i = [0:1:upperpoints-1]) [ w6 - (upperradius + thickness) * cos(innertheta + i * innerphi / upperpoints), h6 - (upperradius + thickness) * sin(innertheta + i * innerphi / upperpoints) ] ],
    // Lower Right Inner arc
    lri = (solid) ? [] : [ for (i = [lowerpoints-1:-1:0]) [ w0  + lowerradius * cos(i * lowerphi / lowerpoints), h0 + lowerradius * sin(i * lowerphi / lowerpoints) ] ]
)
    concat(lro, uro, cap, ulo, llo, lli, uli, uri, lri);

//this is used to make half of an ogee arch
// it is a "pathway" on which the real arches are
// centered on in arch2()
function ogeepolyPath(width, thickness, lowerradius, upperradius, points, capwidth = 0.0, apexangle = 45.0) =
    let(
    // Angle extended by the arcs
    lowerphi = 180.0 - acos((0.5*(width - capwidth) - lowerradius - thickness - upperradius * cos(0.5*apexangle)) / (lowerradius + thickness + upperradius)),
    upperphi = lowerphi - 0.5 * apexangle,
    apexhalf = 0.5 * apexangle,

    // Number of points per lower arc
    lowerpoints = round((capwidth > 0.0) ? lowerphi*(points-4)/(8*lowerphi-4*apexangle) : lowerphi*(points-2)/(8*lowerphi-4*apexangle)),

    // Actual number of points in the upper arc
    uppertemp = round((capwidth > 0.0) ? (lowerphi-apexangle)*(points-4)/(8*lowerphi-4*apexangle) : (lowerphi-apexangle)*(points-2)/(8*lowerphi-4*apexangle)),
    targetpoints = (apexangle > 0.0) ? points - 5 : points - 2,
    upperpoints = (targetpoints - 4*(lowerpoints + uppertemp) >= -1) ? uppertemp + 1 : uppertemp,

    // Key horizontal coordinates. Note: w0=x1, w6=x2
    w0 = 0.5*width - thickness - lowerradius,
    w1 = 0.5*capwidth,
    w2 = w0 + lowerradius * cos(lowerphi),
    w3 = w0 + (lowerradius + thickness) * cos(lowerphi),
    w4 = w0 + lowerradius,
    w5 = w0 + lowerradius + thickness,
    w6 = w0 + (lowerradius + thickness + upperradius) * cos(lowerphi),
   
    // Key vertical coordinates. Note: y1=h0=0, y2=h6
    h6 = (lowerradius + thickness + upperradius) * sin(lowerphi),
    h5 = h6 - upperradius * sin(apexhalf),
    h4 = h5 - 0.5*capwidth * tan(apexhalf),
    h3 = h6 - (upperradius + thickness) * sqrt(1.0 - w6*w6 / ((upperradius + thickness) * (upperradius + thickness))),
    h2 = (lowerradius + thickness) * sin(lowerphi),
    h1 = lowerradius * sin(lowerphi),
    h0 = 0.0,
    height = (apexangle > 0.0) ? (h5 + 0.5*capwidth / tan(apexhalf)) : h5,

    // We use the same number of points for the upper inner arc,
    // even though it is a bit smaller angle.
    innertheta = acos(w6 / (upperradius + thickness)),
    innerphi = lowerphi - innertheta,

    // Lower Right Outer arc
    lro = [ for (i = [0:1:lowerpoints-1]) [ w0 + (lowerradius + thickness) * cos(i * lowerphi / lowerpoints), 0, h0 + (lowerradius + thickness) * sin(i * lowerphi / lowerpoints) ] ],
    // Upper Right Outer arc
    uro = [ for (i = [upperpoints-1:-1:0]) [ w6 - upperradius * cos(apexhalf + i * upperphi / upperpoints), 0, h6 - upperradius * sin(apexhalf + i * upperphi / upperpoints) ] ],
    // Cap
    cap = (capwidth > 0.0) ? [ [ w1, 0, h5 ], [ 0, 0, height ] ] : [],
    // Upper Left Outer arc
    ulo = [ for (i = [0:1:upperpoints-1]) [ -w6 + upperradius * cos(apexhalf + i * upperphi / upperpoints), 0, h6 - upperradius * sin(apexhalf + i * upperphi / upperpoints) ] ],
    // Lower Left Outer arc
    llo = [ for (i = [lowerpoints:-1:0]) [ -w0 - (lowerradius + thickness) * cos(i * lowerphi / lowerpoints), 0, h0 + (lowerradius + thickness) * sin(i * lowerphi / lowerpoints) ] ]
)
    concat(lro, uro, cap, ulo, llo);

function stupid(i) = (i==1) ? ogeepoly(65,3,60,60,100,1,10) : romanArch(70, 3, 62, 200);
   


//makes an arch interpolation between a wider roman
//arch and ogee arch, uses sin() so the transition
//is curved
function waveOut(i,verticies,thickness,solid) = abs(sin(i)) * romanArchNc(65, thickness, 70, echoit5("verticies",verticies),solid) + (1 - abs(sin(i))) * ogeepoly(65,thickness,60,60,echoit5("verticies",verticies),solid,0.0,0);//was 1,10 at end

//makes an arch interpolation between a narrow roman
//arch and ogee arch, uses sin() so the transition
//is curved
function waveIn(i,verticies,thickness,solid) = abs(sin(i)) * romanArchNc(95, thickness, 40, echoit5("verticies",verticies),solid) + (1 - abs(sin(i))) * ogeepoly(65,thickness,60,60,echoit5("verticies",verticies),solid,0.0,0);//was 1,10 at end


//alternates wave in and wave out...
function wave(i,verticies=200,thickness,solid) = (i < 31) ? waveOut(echoit4("<31",(i*6)),echoit5("verticies",verticies),thickness,solid) :
                   (i < 61) ? waveIn(echoit4("<61",(180-((i-30)*6))),verticies,thickness,solid) :
                   (i < 91) ? waveOut(echoit4("<91",(i-60)*6),verticies,thickness,solid) :
                   waveIn(echoit4("last",180-((i-90)*6)),verticies,thickness,solid);

function archselect(i,verticies=160,thickness,solid) = (i == 0) ? romanArchNc(95, thickness, 40, verticies,solid) + (1 - abs(sin(i))) * ogeepoly(65,thickness,60,60,verticies,solid,0.0,0) :ogeepoly(65,thickness,60,60,verticies,solid,0.0,0);



//this makes the shape I want a transtion between
//roman and ogee arches on a pathway that is half
//an ogee arch
//I'd use 6 of these to make the hallways I want
//16 verticies simplifies things
module arches2(verticies=192, thickness = 8, solid = false) {
   
    yxzpath = ogeepolyPath(650, 3, 600, 600, 420, 1, 10);
   
    //echo(yxzpath);
    //echo("blah");
    //echo(yxzpath[10]);
   
    skin([
           for (i=[1 : 1 :  105])
transform(translation(yxzpath[i]) * rotation([0,0,0]), wave(i,verticies,thickness,solid))
]);
}

//this does one fully roman arch and one fully
// ogee arch (or it should) for testing
module arches5(verticies=160, thickness = 4, solid = false) {
    skin([
        for (i=[0 : 1 : 1])
          transform(translation([0,0,(i*90)]) * rotation([0,0,0]), archselect(i, verticies, thickness, solid))
    ]);
}

//for testing, does the arches transitioning
//but on a linear path
module arches6(verticies=192, thickness = 8, solid = false) {
    skin([
           for (i=[1 : 1 : 105])
transform(translation([0,0,i]) * rotation([0,0,0]), wave(i,verticies,thickness,solid))
]);
}

//for testing
//do fewer interpolations to find where it goes wrong
module arches7(verticies=192, thickness = 8, solid = false) {
   
    yxzpath = ogeepolyPath(650, 3, 600, 600, 420, 1, 10);
   
    //echo(yxzpath);
    //echo("blah");
    //echo(yxzpath[10]);
   
    skin([
           for (i=[90 : 1 :  105])
transform(translation(yxzpath[i]) * rotation([0,0,0]), wave(i,verticies,thickness,solid))
]);
}

//for testing
/*uses wave but on a linear path to make it easier to view
allows you to select how many slices to use
*/
module arches8(verticies=192, thickness = 8, solid = false, start = 0, end = 105) {
   
    skin([
           for (i=[start : 1 :  end])
transform(translation([0,0,(i-start)]) * rotation([0,0,0]), wave(i,verticies,thickness,solid))
]);
}

//for testing
//another linear path with wave in and out
module arches4(verticies=190) {
   
   
    skin([
           for (i=[1 : 1 : 90])
transform(translation([0,0,i*0.5]) * rotation([0,0,0]), wave(i,verticies))
]);
}

//for testing
//another linear path this one with just wave out
module arches3(start,end,verticies=190) {
   
    skin([
           for (i=[start : 1 : end])
transform(translation([0,0,i*0.5]) * rotation([0,0,0]), waveOut(i,verticies))
]);
}
   

//polygon test of roman arch or ogee poly
//they both look ok with the same number of verticies
//(10,14,18,22,26.... 6+4(n))
//but the verticies must not be in the same order
//or number because if you do "arches3(0,90,22);"
//there is a twist...
//pts = romanArch(65, 3, 70, 22);
//pts = ogeepoly(65,3,60,60,22,0.0,0);
//polygon(pts);


//pts = romanArchNc(65, 3, 70, 24);
//polygon(pts);

//90 goes from ogee to roman completely
//arches3(0,90,24);

//half the passageway
//arches2(64,4);

//arches5(16,2);


//polygon(romanArchNc(65, 3, 70, 16));

//polygon(ogeepoly(65,3,60,60,16,0,10));

//this test case works
/*
union () {
arches5(48);

translate([0,0,90]) {cube([80,80,80], true); }
}
*/

/*this test case seems to work:
does give the disturbing warning

"DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated.
Rendering Polygon Mesh using CGAL...
ERROR: Unable to convert point at index 1 to a vec3 of numbers
PolySet has nonplanar faces. Attempting alternate construction"
*/
/*
difference() {
    arches5(24);
    mirror([1,0,1]) {
       arches5(24,true); //subtract a SOLID version
    }
}
mirror([1,0,1]) {
       arches5(24);
    }
*/

//works
//arches6(8,2);

//works
/*
union () {
arches6(8,2);

translate([0,0,90]) {cube([80,80,80], true); }
}
*/

//this test case says non-planiar facets, but renders
//24 verticies try lower
/*
difference() {
    arches6(24,2);
    mirror([1,0,1]) {
       arches6(24,2,true); //subtract a SOLID version
    }
}
mirror([1,0,1]) {
       arches6(24,2);
    }
 */

//translate([0,0,750]) {cube([80,80,80], true); }

//a test of unioning half the passageway with a cube
//gets errors

//works
//arches2(24,2);

//does not work
/* "
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below != SHalfedge_handle() File: /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h Line: 426
Geometries in cache: 17
Geometry cache size in bytes: 2167192
CGAL Polyhedrons in cache: 4
CGAL cache size in bytes: 11344
Total rendering time: 0 hours, 0 minutes, 4 seconds
   Top level object is a 3D object:
   Simple:        yes
   Vertices:        8
   Halfedges:      24
   Edges:          12
   Halffacets:     12
   Facets:          6
   Volumes:         2
Rendering finished.
"
*/
/*
union () {
arches2(16,4);

translate([0,0,750]) {cube([80,80,80], true); }
}
*/

//arches7(16);

//arches8(16,8,false,1,3);

//this works odd
/*
union() {
arches8(16,8,false,0,105);
    translate([0,20,00]) {cube([50,50,50], true); }
}
*/

//blows up:
/*
union() {
arches7(16,4);
    //for the first 15 translate 300, 0, 10 works nice
    translate([0,0,600]) {cube([40,40,40], true); }
}
*/
//arches2(16,4);
//translate([0,0,600]) {cube([80,80,80], true); }

//arches2(16,2);

//does not work
/*
Rendering Polygon Mesh using CGAL...
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below != SHalfedge_handle() File: /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h Line: 426
ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below != SHalfedge_handle() File: /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h Line: 426
Geometries in cache: 21
Geometry cache size in bytes: 3129336
CGAL Polyhedrons in cache: 5
CGAL cache size in bytes: 11344
Total rendering time: 0 hours, 0 minutes, 8 seconds
Rendering finished.
*/
/*
    arches2(16,2);
mirror([0,0,1]) {
       arches2(16,2);
    }
*/

//does not work either
/*
difference() {
    arches2(16,4);
    mirror([0,0,1]) {
       arches2(16,4,true); //subtract a SOLID version
    }
}
*/

//arches2(16);

//making a full passageway, gets errors
/*
gets "
DEPRECATED: Using ranges of the form [begin:end] with begin value greater than the end value is deprecated. "
partway through the verticies calculation

then at the end it has "

Rendering Polygon Mesh using CGAL...
Geometries in cache: 21
Geometry cache size in bytes: 3129336
CGAL Polyhedrons in cache: 5
CGAL cache size in bytes: 11344
Total rendering time: 0 hours, 0 minutes, 6 second
"
*/
/*
difference() {
    arches2(16);
    mirror([0,0,1]) {
       arches2(16,true); //subtract a SOLID version
    }
}
mirror([0,0,1]) {
       arches2(16);
    }
*/

//polygon(ogeepoly(65,3,60,60,200,0.0,0));

/*
polygon(ogeepoly(65,3,60,60,200,1,10));
polygon(romanArch(65, 3, 70, 200));
polygon(romanArch(95, 3, 40, 200));
*/

On Thu, Jul 4, 2019 at 11:44 PM MichaelAtOz <[hidden email]> wrote:
DanS wrote
> MichaelAtOz:
> I can show the code to people but it isn't pretty and rightfully people
> have said in the past "I don't want to debug that"

I'll have a first look, no guarantees tho.



-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

MichaelAtOz
Administrator
Which commented out call should I use?





-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
It depends what you want to test.

My end goal is to make six passageways that interconnect with arches2().
So far, for whatever reason, I can't even join 2.  My idea was to take one, and subtract the solid mirror version of it, then re-add a mirror version (not solid).  The interior would not be correct but the exterior would be correct.

arches2() alternates between a roman arch and an ogee arch.  One transition goes from a fat roman arch to a thinner ogee, then it goes from that thinner ogee to an even thinner roman arch and then the cycle restarts.  It does this on a path that is itself one half of an ogee arch.

All the other arch#() ones are just for testing.  I tried to put comments before them to give an idea of what they do, also I have commented out example tests with comments that showed my console results (some of the tests involve union with a cube, others involve intersecting these arch sets).  O

echoit() routines at the start are for debugging, they can be turned off by just having them return the input value or turned on to enable where they are used to output messages

arches8() can take start and end arguments that specify how many iterations to do (another person on the list was suggesting fewer iterations)

On Fri, Jul 5, 2019 at 7:04 PM MichaelAtOz <[hidden email]> wrote:
Which commented out call should I use?





-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

NateTG
I did start writing up a polyhedron checker:

http://forum.openscad.org/Mesh-Polyhedron-Test-Script-td23106.html

I'm not sure how quickly or easily you could run something like that on that
on the polyhedron you're generating, or if it would find the issue that
you're running into, but it should find holes and topologically incorrectly
oriented faces.

It won't detect if you're generating a self-intersecting extrusion profile.

I've run into issues because OpenSCAD doesn't do exact geometry or because
of floating point problems.  So you can get into trouble if you have very
short line segments or wall thickness.




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

MichaelAtOz
Administrator
In reply to this post by DanS
Well I can give you a clue to the CGAL error.

I looked at arches2(16,4).
Exported a .stl, where Netfabb pointed to self-intersections at the top end.
<http://forum.openscad.org/file/t359/Capture_arches2_full.jpg>

I then changed arches2() to just make the end slice, ie "for (i=[103 : 1 :
105])"

STL:  arch2e.stl <http://forum.openscad.org/file/t359/arch2e.stl>  

<http://forum.openscad.org/file/t359/Capture_arches2_end.jpg>

Note the red edges v's orange faces.

Close-up, near the arrow above:
<http://forum.openscad.org/file/t359/Capture_arches2_end_close.jpg>
Those lines are what looks red edges above.

Closer:
<http://forum.openscad.org/file/t359/Capture_arches2_end_close2.jpg>

Closer:
<http://forum.openscad.org/file/t359/Capture_arches2_end_close3.jpg>
That is an overhang.

From below:
<http://forum.openscad.org/file/t359/Capture_arches2_end_close_below.jpg>

Above:
<http://forum.openscad.org/file/t359/Capture_arches2_end_close_above.jpg>
Note that is not legal triangulation I believe.

I don't know whether that is due to your input to skin() or skin().

I change it to the following so the vector can be examined.

module arches2(verticies=192, thickness = 8, solid = false) {
   
    yxzpath = ogeepolyPath(650, 3, 600, 600, 420, 1, 10);
   
    //echo(yxzpath);
    //echo("blah");
    //echo(yxzpath[10]);
   
    skinv= [
          for (i=[103 : 1 :  105])
            transform( translation(yxzpath[i]) * rotation([0,0,0])
                      , wave(i,verticies,thickness,solid))
          ];
    echo(skinv);
    skin(skinv);
}


ECHO:
[
 [
  [23.7722, 0, 763.327], [22.2656, 16.6424, 763.327],
  [17.5469, 33.136, 763.327], [10.6125, 48.2908, 763.327],
  [1.32186, 61.5592, 763.327], [-8.0577, 47.8162, 763.327],
  [-15.4296, 32.2882, 763.327], [-19.7167, 16.1361, 763.327],
  [-21.041, 0, 763.327], [-20.0367, 0.474642, 763.327],
  [-17.221, 21.6275, 763.327], [-10.0349, 41.2904, 763.327],
  [1.32186, 58.5576, 763.327], [12.7961, 41.0483, 763.327],
  [20.2811, 21.0021, 763.327], [22.7694, 0, 763.327]
 ],
 [
  [22.7821, 0, 771.996], [21.3229, 16.5331, 771.996],
  [16.9285, 32.6534, 771.996], [9.94616, 47.6982, 771.996],
  [0.5, 61.1888, 771.996], [-8.96845, 47.5793, 771.996],
  [-16.0605, 32.4408, 771.996], [-20.3467, 16.4062, 771.996],
  [-21.7601, 0, 771.996], [-20.8072, 0.118986, 771.996],
  [-18.2633, 21.1468, 771.996], [-11.0469, 40.9534, 771.996],
  [0.5, 58.5097, 771.996], [12.0764, 40.8928, 771.996],
  [19.3677, 20.9901, 771.996], [21.8295, 0, 771.996]
 ],
 [
  [22.7258, 0, 771.996], [21.2825, 16.4966, 771.996],
  [16.9966, 32.4919, 771.996], [9.99819, 47.5, 771.996],
  [0.5, 61.0648, 771.996], [-8.99819, 47.5, 771.996],
  [-15.9966, 32.4919, 771.996], [-20.2825, 16.4966, 771.996],
  [-21.7258, 0, 771.996], [-20.79, 0, 771.996],
  [-18.337, 20.986, 771.996], [-11.1105, 40.8407, 771.996],
  [0.5, 58.4937, 771.996], [12.1105, 40.8407, 771.996],
  [19.337, 20.986, 771.996], [21.79, 0, 771.996]
 ]
]




-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

MichaelAtOz
Administrator
Disregard the above. I think I introduced a side effect when formatting the
code.



-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

MichaelAtOz
Administrator
OK re-regard the above, I got confounded by a F6 before F5 artifact...

 

So plotting the points

module plotvv3(vv,size=2)
  for(j=vv) plotv3(j,size,"red");

module plotv3(v,size=4,c="blue") { // v=[ [x,y,z], ... ]
  for(i=v)
    translate([i.x,i.y,i.z])
      color(c)
        sphere(size,$fn=12);
}
 
//this makes the shape I want a transtion between
//roman and ogee arches on a pathway that is half
//an ogee arch
//I'd use 6 of these to make the hallways I want
//16 verticies simplifies things

module arches2(verticies=192, thickness = 8, solid = false) {
    yxzpath = ogeepolyPath(650, 3, 600, 600, 420, 1, 10);

    //echo(yxzpath);
    //echo("blah");
    //echo(yxzpath[10]);
    translate([0,0,750]) cube();
    skinv=[
           for (i=[103 : 1 :  105])
              transform(translation(yxzpath[i]) * rotation([0,0,0]),
                        wave(i,verticies,thickness,solid))
          ];  
    echo(len(skinv),skinv=skinv);
    plotvv3(skinv,size=0.3);
    skin(skinv);
}

Shows:
<http://forum.openscad.org/file/t359/arches2_plot_orig.jpg>


Looking at the 103-105 points, which are black, red, blue respectively
<http://forum.openscad.org/file/t359/Capture_arches2_skinv_plot_103-105.jpg>

The 104 & 105 are likely the cause.

Doing,

    plotv3(yxzpath);

Shows:
<http://forum.openscad.org/file/t359/Capture_arches2_yxzpath.jpg>

Looking into ogeepolyPath(),

    // Lower Right Outer arc
    lro = [ for (i = [0:1:lowerpoints-1])

Remove the '-1' fixes that gap.

Then:
<http://forum.openscad.org/file/t359/arches2_plot_fixed.jpg>

No more CGAL error with a cube().

STL fixed:  arches2_fixed_w_cube.stl
<http://forum.openscad.org/file/t359/arches2_fixed_w_cube.stl>  
No self-intersections.

But Thrown-together still shows purple...
<http://forum.openscad.org/file/t359/arches2_fixed_purple.jpg>

I suspect that may be a skin() thing...looking...








-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
Thanks for all your hard work.  I am confused on some things though:

1) " But Thrown-together still shows purple...
<http://forum.openscad.org/file/t359/arches2_fixed_purple.jpg> "
So that is the kind of thing I have been seeing but the image shows the facets in shades of yellow, and only the edges are purple/magenta/pink.  I have been operating under the assumption that whole faces/facets should be purple/magenta/pink to show a problem.  Another person suggested those "edges" were really very narrow facets or gaps.  But it seems hard for me to believe that every single face / facet in my object also is bordered on all sides by either facets with a very tiny width or holes with a tiny width.  Or does this mean I have been looking for the wrong thing in "thrown together" and edges with purple/magenta/pink mean there is a problem (that is still somewhat confusing because it suggests that somehow everything is in error; I'd think it would be almost impossible to generate something that was all bad or nearly all bad)?  So I think I don't know how to interpret "thrown together" properly

2) the overhang thing you found I believe is the problem, but I don't really get how it happens.  Lately I've been doing arches2(16) specifying only 16 points per arch.  The advantage of doing that is (given the other defaults) the points should be widely enough spaced apart that floating point vagaries don't cause two points to end up (with rounding errors) at the same coordinate.  Also I set some debug messages in the code to spit out how many points each arch had.  All the messages said "16", so with equal number of point I don't see how an overhang should happen.  You mentioned there might be some problem with skin() (I didn't realize skin() had known bugs) which could explain things; otherwise I don't understand how when knitting together polygons (with roughly similar shapes, non degenerate points, the same order of points, and the same number of vertices) gives an overhang

That being said it did occur to me that ogeepolyPath (which is generating the coordinate path to center the arches on) is generating 402 points, whereas my wave() routine is generating 105 arch polygons.  I could see that it might cause a problem (if skin() has to interpolate or do something like that to make them match).  I did go back to force ogeepolyPath to generate 105 points so it would match the number of archways being generated.  Unfortunately I still get the "ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e_below != SHalfedge_handle() File: /opt/mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_FM_decorator.h Line: 426 " error when I try to build the hallway, subtract a solid mirrored version, then add the mirror version

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

Parkinbot
well, to be honest, your coding is a bit callenging. But having played a bit
with your code, I can say that

     translate([0,0,750]) cube();
     skinv=[
           for (i=[0 : 1 :  104])
              reverse(transform(translation(yxzpath[i]) * rotation([0,0,0]),
                        wave(i,verticies,thickness,solid)))
          ];  
    skin(skinv);

works well with F6. Note that I had to include a reverse() to correct the
point order. Further I count the 105 polygons from 0 to 104. Your problem
might be that a loop from 104 to 105 will return two identical polygons,
which will trigger the CGAL error, when skinned.

     skinv=[
           for (i=[104 : 1 :  105])  // identical polygons




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

DanS
Thanks everyone!

I hope to print out the 1/3 of the main hallways soon.  Then I'll move on to the domes, and after that buttresses etc.

Parkinbot- how did you quickly determine that the last two polygons were the same?  Did you look for the purple in the display and then compare points or....?

On Sat, Jul 6, 2019 at 4:47 PM Parkinbot <[hidden email]> wrote:
well, to be honest, your coding is a bit callenging. But having played a bit
with your code, I can say that

     translate([0,0,750]) cube();
     skinv=[
           for (i=[0 : 1 :  104])
              reverse(transform(translation(yxzpath[i]) * rotation([0,0,0]),
                        wave(i,verticies,thickness,solid)))
          ]; 
    skin(skinv);

works well with F6. Note that I had to include a reverse() to correct the
point order. Further I count the 105 polygons from 0 to 104. Your problem
might be that a loop from 104 to 105 will return two identical polygons,
which will trigger the CGAL error, when skinned.

     skinv=[
           for (i=[104 : 1 :  105])  // identical polygons




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

MichaelAtOz
Administrator
In reply to this post by Parkinbot
Parkinbot wrote
> Note that I had to include a reverse() to correct the
> point order.
>
> Your problem
> might be that a loop from 104 to 105 will return two identical polygons,
> which will trigger the CGAL error, when skinned.
>
>      skinv=[
>            for (i=[104 : 1 :  105])  // identical polygons

Note the 105 prolem is caused by a gap in the ogee, see ogeepolyPath(),

    // Lower Right Outer arc
    lro = [ for (i = [0:1:lowerpoints-1])

Remove the '-1' fixes that gap, and [0:1:105] is good geometry.
[Dan, same issue with ogeepoly()]

When I included reverse() the result is everything is inside-out.
<http://forum.openscad.org/file/t359/arches2_fixed_all_purple.jpg>
(note on closer examination the cube() has no purple, that is an artefact)

Without reverse(), without show-edges:
<http://forum.openscad.org/file/t359/arches2_fixed_purple_close.jpg>
Those purple bits behave as if there is z-fighting, when you rotate the
model.

It gets very psychedelic:
<http://forum.openscad.org/file/t359/arches2_fixed_purple_side1.jpg>
<http://forum.openscad.org/file/t359/arches2_fixed_purple_side2.jpg>

With show-edges:
<http://forum.openscad.org/file/t359/arches2_fixed_purple_close_edges.jpg>


I have no idea what's going on...



-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Getting more information

Parkinbot
In reply to this post by DanS
DanS wrote
> Parkinbot- how did you quickly determine that the last two polygons were
> the same?  Did you look for the purple in the display and then compare
> points or....?

two identical polygons are not visualized as purple by F12, but trigger CGAL
errors due to self intersection. When playing, I wondered why the loop going
from 103 to 105 produced only a single segment and there was no difference
to a loop going from 103 to 104. Thus I suspected that 104 to 105 will
generate a flat segment, which proved to be true.  




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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12