shape-find-bounds is too conservative

[mkeeter]

This is a tracking issue for cases where automatic bounds detection gives technically correct, but too-large-to-be-useful results.

From issue #134:

(define s (sequence
  (sphere 0.8)
  (twirl-x 3 1 #[0 0 -1])
  (rotate-z 0.3)
  (move #[0.3 1 1.2])
))

From issue #129:

(let* ((profile (taper-x-y
                 (rectangle #[-1/8 0] #[1/8 7/20])
                #[0 0] 7/20
                1/2 1))
       (solid (move
               (rotate-z
                (extrude-z profile -1/24 1/24)
                (- (* 5 (/ pi 8))))
               #[99/100 1/2 0]))
       (bounds (shape-find-bounds solid)))

[omgitsraven]

Should the inability to use blend-poly with autobounds count as an example? #105 (Not a particularly urgent one since blend-expt works fine, but maybe a useful test case...)

[omgitsraven]

Here's a freebie:

(sequence
  (sphere 1)
  (rotate-x 1)
  (rotate-y 1)
  (rotate-z 1)
)

This is the one I'm running into all the time; anything that I want to apply an arbitrary rotation to, I wind up having to go rotate-x, rotate-y, intersection with a box, rotate-z

[omgitsraven]

Also, if we're proposing alternate methods: I'm still kind of partial to the idea of just doing a low resolution pass on the default bounds, and bringing in the auto bounds to fit around whatever turns up, plus a margin... the only complication might be expanding that margin if higher-resolution passes reveal details that come too close to the existing margins (I don't know if it would be possible to render only the new area, or if it would necessitate repeating the whole render every time that it realises the margins were too tight...)

[mkeeter]

While doing more experiments with interval math, I found yet another way that bounds tracking was incorrect. I've decided to remove it entirely (7520c6c), rather than leaving a half-baked implementation in the codebase. It's in the Git history for folks to dig up, if anyone else wants to take up the fight.