hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > The test (using version 2 of bounder.inc) for quartic objects is
> > > interesting. Using the Lemniscate object the BB seems to be infinite and
> > > the test is considered optimal. See image attached.
> > I see the BB change in size when the object is aligned, no idea(s).
> > interesting.
>
> I guess add some #debug output, and maybe show some or all of the trace ()
> tests, coloring them red or green according to if they "hit" or not.  Show each
> successive BB with a different color, and that would help show what was going on
> and give a better idea.

I'd play with something like that, no doubt, but won't put effort into (cf my
"rant" in an earlier reply to Thomas).

the 'Bounder' does not use 'trace()' though, it's all 'inside()' testing.

> I would imagine that if POV-Ray can see and render the object, then the macro
> ought to give sensible results.

agree, provided the object is amenable to 'inside()' testing.

ideally, I'd like a developer who knows POV-Ray's 'inside()' inside out (pun
intended) to chime in, giving us POV-Ray's "perspective" of processing an object
using 'inside()'.

> Given an infinite (or sufficiently large) object along one axis, perhaps a
> bounding rectangle (a cross-section of the infinitely long BB) could be shown /
> reported.

I'm more inclined[*] to provide a list of unsuitable object types, then the onus
is on the user to avoid things like the "Lemniscate"s reported by Thomas.

[*] currently.

> Maybe after the SVD adventure, we coulld throw some function {} foo in there and
> do a semi-transparent isosurface as a representation, which would allow
> "infinite" objects to be easily displayed (by 'scaling' one axis to 0)

again, nice but who'd write the code?

> Just some early-morning thoughts.

(one hand on keyboard, the other cradling the first cup of coffee, no doubt
:-))


regards, jr.

Post a reply to this message