POV-Ray : Newsgroups : povray.binaries.animations : CHROMADEPTH code tests-- animation Server Time
24 Jun 2021 15:46:17 EDT (-0400)
  CHROMADEPTH code tests-- animation (Message 11 to 14 of 14)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Bald Eagle
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 06:55:01
Message: <web.5a90004a54892b7e5cafe28e0@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> I'm still mighty curious about why the use of min_extent and max_extent (as used
> or derived from the moving 'MAIN camera' location) 'flip' their meaning of
> 'near' and 'far', depending on the relative locations of camera and object. (I'm
> simply using my L_1/L_2 equation to gauge that-- it seems like an accurate and
> simple-enough test, as it's just the ratio of min_extent/max_extent measured
> from the camera position-- which *should* never go past 1.0.) Given that the
> found min and max points are simply coordinates in space, why doesn't, say,
> min_extent *always* pick the 'closest' bounding-box corner to the camera? Yet it
> appears that the 'near' and 'far' relationship never changes for an object, like
> it's sealed in stone the moment the object is made (the coordinates apparently
> relative to the origin at <0,0,0>). Or else min_extent and max_extent aren't
> behaving consistently.

The bounding box - and all other coordinates in pov-ray - are referenced to the
origin.   Nothing to do with the camera at all.  Ever.

So when you do your near / far / camera triangle, of course you "flip" the near
and far - you've moved the camera to a point where that's true.

I do believe you're going to have problems with trace, especially with more
complicated objects.
Near and far ought to create a spread for the color map that covers the whole
object, which is the point.   Better a little too big, than too small.


Post a reply to this message

From: Kenneth
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 07:25:01
Message: <web.5a90075954892b7ea47873e10@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> The bounding box - and all other coordinates in pov-ray - are referenced to the
> origin.   Nothing to do with the camera at all.  Ever.
>
> So when you do your near / far / camera triangle, of course you "flip" the near
> and far - you've moved the camera to a point where that's true.
>

Yeah; I had a weird locked-in notion in my head that the min_extent/max_extent
coordinates *changed* as I moved the camera(!). I was confusing/conflating that
with vlength.

Duh. Just goes to show that concentrating solely on a single subject for days
can be... detrimental to mental functioning :-P

But I still think trace() will work; I just need to try it and see.


Post a reply to this message

From: clipka
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 13:43:12
Message: <5a9060c0$1@news.povray.org>
Am 23.02.2018 um 09:53 schrieb Kenneth:

> Given that the
> found min and max points are simply coordinates in space, why doesn't, say,
> min_extent *always* pick the 'closest' bounding-box corner to the camera?

Because it always picks the corner with the lowest absolute x,y,z
values, regardless of camera location.

Thus if the camera is in the negative x,y,z octant relative to the
object, then min_extent happens to be the nearest corner.

If on the other hand the camera is in the positive x,y,z octant relative
to the object, then max_extent is the nearest corner.

And if the camera is in any other octant, yet another corner may be the
nearest one.

For instance, if the camera is in the +x,-y,-z octant, then the nearest
corner is at

    <max_extent(Obj).x,min_extent(Obj).y,min_extent(Obj).z>


Post a reply to this message

From: Kenneth
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 14:45:00
Message: <web.5a906e8e54892b7ea47873e10@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 23.02.2018 um 09:53 schrieb Kenneth:
>
> > Given that the
> > found min and max points are simply coordinates in space, why doesn't, say,
> > min_extent *always* pick the 'closest' bounding-box corner to the camera?
>
> Because it always picks the corner with the lowest absolute x,y,z
> values, regardless of camera location.
[snip]


If I had been using my brain like I *should* have, that sentence would have been
something like...

"
...why doesn't, say, VLENGTH *always* pick the 'closest' bounding-box corner to
the camera?" ... which would have made no sense anyway ;-) Duh. Definitely a
major faux-pas of the ol' brain.

All clear now.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.