POV-Ray : Newsgroups : povray.binaries.animations : CHROMADEPTH code tests-- animation : Re: CHROMADEPTH code tests-- animation Server Time
26 Apr 2024 19:39:35 EDT (-0400)
  Re: CHROMADEPTH code tests-- animation  
From: Bald Eagle
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

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