POV-Ray : Newsgroups : povray.binaries.animations : CHROMADEPTH code tests-- animation Server Time
29 Mar 2024 03:47:06 EDT (-0400)
  CHROMADEPTH code tests-- animation (Message 5 to 14 of 14)  
<<< Previous 4 Messages Goto Initial 10 Messages
From: Mike Horvath
Subject: Re: CHROMADEPTH code tests-- animation
Date: 22 Feb 2018 22:32:44
Message: <5a8f8b5c$1@news.povray.org>
On 2/22/2018 9:43 PM, Bald Eagle wrote:
> So, just calculate all 8 distances and use min() and max().
> 
> 
> 

This is what I was thinking too.


Mike


Post a reply to this message

From: Kenneth
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 03:15:04
Message: <web.5a8fcd2c54892b7ea47873e10@news.povray.org>
Mike Horvath <mik### [at] gmailcom> wrote:
>
> 2. The color map should go a) red white blue or b) red yellow green cyan
> blue. What you currently have breaks the effect.
>

Yes, definitely true. For the tests I've been running, though, I've instead used
what I call my 'experimental color_map'-- it's in the code I posted. It helps me
to clearly see that the color_map's 'mid-point' is indeed corresponding to the
'middle' of the object. Sorry if that confused you.


Post a reply to this message

From: Kenneth
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 03:55:00
Message: <web.5a8fd4fe54892b7ea47873e10@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:

> > IMO, min_extent/max_extent mistakenly begin working in reverse at that
> > point, sensing the now-'far' point as  the 'near' one, for example. That
> > doesn't seem right.
>
> Maybe you need to define a _relative_ "min" and "max" based on the
> distances of the corners from the camera.   Then I think it should all
> work out.

Yep, that sounds like the trick to use. Thanks.

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.


Post a reply to this message

From: Kenneth
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 04:35:00
Message: <web.5a8fdf0454892b7ea47873e10@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, after looking over the animation for a bit more, and considering what
> you're probably actually trying to do:
>
> 1.  I'm not actually clear on how you're working out all that color map and
> scaling math.
> I think I'd find the distance to the farthest corner (not necessarily
> max_extent) and the nearest corner.  Divide both distances by farthest corner
> distance.   That gives you 1 and less than 1.
> define color map, and then scale back up by distance to the farthest corner.
> I think that should give you that thin shell of varying color extending from
> nearest corner to farthest corner.

Well, that's exactly what min_extent and max_extent are *supposed* to do (along
with my code for creating the scaled-up thin shell.) :-/ Although, it's not
clear to me as to how to get the near and far corners of an object without using
those functions to begin with. Some fancy vector math, I'm guessing?

>
> 2. You're not really looking for "which" corner is nearest or farthest,
> programmatically, you're looking for the largest and smallest distances.
>
> So, just calculate all 8 distances and use min() and max().

I do see what you're getting at. But there remains that little thorny problem of
too much extra space between object and bounding-box, when the object happens to
be rotated. (See the orthographic camera views I posted in Mike H's thread.)
That space still slightly throws off an accurate gauge of the object's spatial
volume-- with a correspondingly inaccurate color_map 'spread.'

HOWEVER... your suggestion has given me another idea-- and I'm surprised at
myself for not having thought of it already: To use POV-Ray's trace() function
to find the *exact* outer-surface-size of the object-- the trace 'shoot-from'
origin being the 'MAIN camera' position-- then again from 180-degrees
'antipodal'(?) to that line of sight. Maybe 20-40 trace rays....and using the
bounding-box coordinates as simply a way to restrict the tracing volume, to be
efficient. From those found points, it's an easy matter of finding the object's
spatial extent and its center location--then the color_map spread should
*exactly* cover the object.

I'll try to code that up and see...


Post a reply to this message

From: Kenneth
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 05:20:00
Message: <web.5a8fea2554892b7ea47873e10@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

>
> ...But there remains that little thorny problem of
> too much extra space between object and bounding-box, when the object happens to
> be rotated. (See the orthographic camera views I posted in Mike H's thread.)
> That space still slightly throws off an accurate gauge of the object's spatial
> volume-- with a correspondingly inaccurate color_map 'spread.'
>

Actually, as I look at those images again, I see that the extra space is not in
the 'Main camera'-to-object direction (well, maybe a tiny bit is) but rather in
directions +/- 90-degrees to that-- to the 'sides'. As far as my code goes (and
the chromadepth idea itself), the extra 'side' space doesn't matter; the
bounding-box volume and associated color_map spread are only important along the
camera-to-object line of sight.


Post a reply to this message

From: Kenneth
Subject: Re: CHROMADEPTH code tests-- animation
Date: 23 Feb 2018 06:25:01
Message: <web.5a8ff94554892b7ea47873e10@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I'm still mighty curious about why the use of min_extent and max_extent
> (as usedor derived from the moving 'MAIN camera' location) 'flip' their
>  meaning of 'near' and 'far', depending on the relative locations of
> camera and object...

Duh. I just realized my conceptual flaw (after *days* of thinking about it the
wrong way!) Various comments here and in the other thread may have pointed the
way, but I didn't grasp it.

1) Given: The min_extent and max_extent coordinates are *just* coordinates in
space-- the bounding-box corners-- which never change (unless I rotate the
object of course, or change its position).

2) I'm using vlength to find those coordinates-- from the changing 'MAIN camera'
position

3) Those found vlengths *NATURALLY* change, depending on where the origin of
vlength is (the 'MAIN camera' position) in relation to the never-changing
bounding-box corners.

4) It's my particular use of the *difference* between the two vlengths (and the
resulting L_1/L_2 equation) that causes the color_map to sometimes squash down
too much-- depending solely on the position of the 'MAIN camera' (which is also
the center of the spherical pigment.) The color spread just happens to look
correct at most times, but that's ... pure luck. The *difference* in vlengths
(from camera position) to the two bounding-box corners can indeed shrink to
almost nothing in some cases.  Part 4 of my animation test clearly shows this --
except that I didn't see what it truly meant!

5) Even with the camera/pigment placed at <0,0,0>, there are still *slight*
flaws with the resulting color_map spread on an object-- unless the object
itself is 'centered' along two of the three default x/y/x axes. The reason for
this is because of 2) and 3). For an object centered at, say, <13,26,50>, the
'MAIN camera' needs to be at <13,26,0> (or some other z-position)-- because this
is the only relationship whereby the found vlengths (the difference between
them, that is) is accurate, as far as scaling the spherical pigment to exactly
extend between object boundaries (or rather, between bounding-box corners.)

I think the trace() idea will easily solve these problems.


Post a reply to this message

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 4 Messages Goto Initial 10 Messages

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