CSG - Maximum call stack size exceeded

[timknip]

I'm aware the below polygons aren't a valid 'solid', omitting some polygons for clarity.
In my 'real' code I'm using g/extrude some-poly {:depth 280} on some 100 different extruded polygons, which all are succeeding apart from the one below.

This fails with "call stack size exceeded":

(def polys
  [
  [(vec3 942 440 0) (vec3 879 515 0) (vec3 884 527 0) (vec3 954 445 0)]
  [(vec3 942 440 0) (vec3 879 515 0) (vec3 879 515 280) (vec3 942 440 280)]
  ])

(mesh->csg
  (reduce
    (fn [m f]
      (g/add-face m f))
    (basic-mesh)
    polys))

But with the first polygon only mesh->csg succeeds:

(def polys
  [
  [(vec3 942 440 0) (vec3 879 515 0) (vec3 884 527 0) (vec3 954 445 0)]
  ])

With the second polygon only mesh->csg throws "call stack size exceeded" (?!)

(def polys
  [
  [(vec3 942 440 0) (vec3 879 515 0) (vec3 879 515 280) (vec3 942 440 280)]
  ])

This is bizarre :-) Seems the call to csg-node ends up in an endless loop.
Question of course is: how the hell can that happen with a single polygon?

It looks like some specific polygon orientations induce the problem.

Below the full "problem" mesh:

#thi.ng.geom.types.BasicMesh{
:vertices #{
  #<[942 440.8021545410156 0]>
  #<[879.2171630859375 515 0]> 
  #<[884.7828369140625 527 0]>
  #<[954 445.1978454589844 0]> 
  #<[884.7828369140625 527 280]>
  #<[954 445.1978454589844 280]> 
  #<[879.2171630859375 515 280]> 
  #<[942 440.8021545410156 280]>},
:faces #{
  (#<[942 440.8021545410156 0]> #<[879.2171630859375 515 0]> 
   #<[884.7828369140625 527 0]>   #<[954 445.1978454589844 0]>) 
     [#<[954 445.1978454589844 0]> 
      #<[884.7828369140625 527 0]> 
      #<[884.7828369140625 527 280]> 
      #<[954 445.1978454589844 280]>]
     [#<[884.7828369140625 527 0]> 
      #<[879.2171630859375 515 0]> 
      #<[879.2171630859375 515 280]> 
      #<[884.7828369140625 527 280]>] 
     [#<[879.2171630859375 515 0]> 
      #<[942 440.8021545410156 0]> 
      #<[942 440.8021545410156 280]> 
      #<[879.2171630859375 515 280]>] 
    [#<[942 440.8021545410156 0]> 
     #<[954 445.1978454589844 0]> 
     #<[954 445.1978454589844 280]>
     #<[942 440.8021545410156 280]>]
    [#<[954 445.1978454589844 280]> 
     #<[884.7828369140625 527 280]> 
     #<[879.2171630859375 515 280]>
     #<[942 440.8021545410156 280]>]}, :fnormals {}, :attribs {}}

The polygon used with (g/extrude poly {:depth 280})

#thi.ng.geom.types.Polygon2{
:points [
#<[942 440.8021545410156]> 
#<[879.2171630859375 515]> 
#<[884.7828369140625 527]> 
#<[954 445.1978454589844]>]}

[timknip]

It seems to be related to the *eps* value which makes compute-split-types classify the polygon wrongly. ie: t is larger then *eps* or t smaller then (- *eps*) hence the polygon gets split-type 1 or 2, instead of the expected split-type 0 (as a csg-node with a single polygon of course should).

Not sure how to handle this. Guess there's some 'best' *eps*.

For now I'll fiddle with (set! thi.ng.math.core/*eps* MY_EPSILON)

Setting *eps* to 0.001 fixes the issue above, but well, guess it'll introduce others :)

NOTE: the t of the problem polygon in previous post is 0.000003032253516721539 with the default *eps* of 0.000001. Hence.

[timknip]

(binding [thi.ng.math.core/*eps* MY_EPS]
; csg stuff here
)

Seems to do the job fine...
Closing the "issue"