 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
These were originally just tests for myself, but they looked interesting enough
to post. ;-) (Thanks to Mike Horvath for giving me the idea to work on this
stuff.)
This 3-part animation relates to the 'chromadepth' discussion at ...
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5a8edc2ab61f5657c437ac910%40news.povray.org%3E/
The code I posted there makes use of an object's bounding-box (the automatic
bounding mechanism that's behind-the-scenes of POV-Ray.). Min-extent and
max_extent are used to get the corner coordinates of that box. My code has a
subtle flaw, although it does what it's supposed to do ' most of the time'.
This video shows that flaw-- and the bounding-box behavior as well.
If you're not familiar with the comments there, this video probably makes no
sense ;-) But I'll try to explain:
The main object in the scene is a flattened cylinder.
Next, I made a spherical-pattern pigment. The pigment has a constantly changing
scale, AND a constantly changing index list of its colors; both of those changes
are derived from finding the bounding-box coordinates of the object-- as
measured from what I call the 'MAIN camera' in the video, not the <0,0,0>
origin-- and used as scaling factors. The spherical pigment is also centered on
that camera. This way, no matter where the camera is, it always looks at the
object AND it applies the changing pigment to that object-- so that the
'important' part of the pigment always exactly covers the object in the right
way (more or less!), no matter where.
One problem with my code is, the bounding-box coordinates naturally (but
unfortunately) *change*, if the object is rotated. I didn't forsee that.
Another is that the meaning of which coordinate is 'near' or 'far' can CHANGE,
depending on where those coordinates are measured from when using min_entent and
max_extent. My code didn't take that into account. (But I think it's easy to
fix.)
But the biggest problem shows up in part 4 of the video. It's not an easy one to
explain,: basically, as the camera viewing axis approaches a right angle to an
imaginary 'plane' between the two bounding-box corners, the difference in
camera-distance to those two points begins dropping to zero- (then 'reverses',
as to which point was originally 'near' or 'far.') That's a more subtle and
not-so-easily fixed flaw in my code :-/ 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.
In the video:
These renders were made with a *separate* camera, at a different location from
the 'MAIN camera', to show what's going on. The white line represents the
line-of-site between MAIN camera and object. The blue box shows the bounding-box
volume. The two small spheres show its min_extent/max_extent coordinates--
yellow for min, black for max-- and apparently they *remain* min and max no
matter what. Overlayed is a simple sphere that has the identical MAIN spherical
pigment applied to it as to the cylinder object-- and likewise applied *from*
the MAIN camera position. I included it to show the pigment's color_map
'limits'-- the white to either side of the 'important' blue and red colors.
There are also geen 'slicing planes' that come in when things go awry, to show
the incorrect extent of the color_map's important colors on the object, and how
they shrink down.
Part 1: The 'MAIN camera (and pigment) location is fixed; the main object moves
away from it. Everything works OK, no matter how great the distance is between
them.
Part 2: Same exact test, but now the object is rotating. This shows the changing
bounding-box size-- and how it affects the spread of the color_map (in my code,
that is.) So far, it all still works reasonable well.
Part 3) The most interesting one. The MAIN camera/pigment is now moving around.
The object has been pre-rotated into a good position to show the effects--as
they go awry. ;-)
Post a reply to this message
Attachments:
Download 'chromadepth_with_bounding_box.mp4.mpg' (3467 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A couple of comments.
1. I should have mentioned this earlier, but Chromadepth are actually
pretty crappy glasses. They are blurry and the 3D effect is not that
great. Stereoscopic glasses are much better if you can create images
that small. Anaglyph glasses might be better too.
2. The color map should go a) red white blue or b) red yellow green cyan
blue. What you currently have breaks the effect.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> wrote:
> One problem with my code is, the bounding-box coordinates naturally (but
> unfortunately) *change*, if the object is rotated. I didn't forsee that.
> Another is that the meaning of which coordinate is 'near' or 'far' can CHANGE,
> depending on where those coordinates are measured from when using min_entent and
> max_extent. My code didn't take that into account. (But I think it's easy to
> fix.)
#declare S = min(L_1,L_2)/max(L_1/L_2);
> But the biggest problem shows up in part 4 of the video. It's not an easy one to
> explain,: basically, as the camera viewing axis approaches a right angle to an
> imaginary 'plane' between the two bounding-box corners, the difference in
> camera-distance to those two points begins dropping to zero- (then 'reverses',
> as to which point was originally 'near' or 'far.') That's a more subtle and
> not-so-easily fixed flaw in my code :-/ 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.
I worked out some code to determine what octant I was in, and it was a lot of
lines of code, but not very complex.
Let me know if you need me to dig that out - I don't think you need it though.
> In the video:
The two small spheres show its min_extent/max_extent coordinates--
> yellow for min, black for max-- and apparently they *remain* min and max no
> matter what.
Yes, obviously - that is the expected behaviour.
> Part 2: Same exact test, but now the object is rotating. This shows the changing
> bounding-box size-- and how it affects the spread of the color_map (in my code,
> that is.) So far, it all still works reasonable well.
Yes, very nice - maybe something to code up as a separate project for inclusion
in a distro as a demo scene to show how bounding boxes work.
> Part 3) The most interesting one. The MAIN camera/pigment is now moving around.
> The object has been pre-rotated into a good position to show the effects--as
> they go awry. ;-)
Calculate relative min and max, and I think it'll work out fine. There might
not even be any weird "jumps" - though I'll bet a graph of distance to min and
max would be interesting.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
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().
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
