 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmail com> wrote:
> Awesome! Let us know when you figure out why the fudge factor is needed.
> If you flip over the disc you'll see that the second fudge factor is too
> small. You need to set it to + 1.65 instead of + 1.44.
>
>
Thanks. Yeah, that doesn't surprise me at all! And in some of the tests I ran by
rotating the object, the L_1/L_2 equation-- the min_extent and max_extent --
actually exceeded 1.0. Meaning, the far bounding_box corner was being sensed as
closer to the camera than the near one(!) That made no sense, but it's
*probably* precision-errors, due to some of the values becoming really small
(when the camera/object distance is large.)
Currently, I can live with the fudge factors-- they're at least somewhat easy to
fiddle with, until I figure out what's happening-- but they make no sense. And
neither did any of the other fudgy things I tried. That kind of arbitrary stuff
really bugs me.
I'll hopefully awake one morning with an 'A-HA' epiphany, and it will all be
clear. But don't hold your breath :-P
I have a sneaking feeling that, with a *complex* object made of lots of parts,
its bounding_box corner locations may throw off the 'centerline' location of
the color_map. Requiring more fudge factors, maybe... :-O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmailcom> wrote:
> // This script assumes the depth effect is *linear* from near to far,
> which may not be the case.
I've been thinking about that as well. My opinion is that it's NOT linear-- that
the RED/BLUE 'mix' should not be equal across the model (and/or that the
mid-point 'mix line' should not extend exactly to the mid-point of the model or
of a larger entire scene.) The analogy I thought of was the visual effect of
looking through binoculars at distant objects: The 3-D effect is reduced there;
objects at different distances look kind of like flat planes, because our eyes
are only _____ inches apart (not much parallax.) And MUCH more of a 3-D effect
looking at closer objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/19/2018 8:50 PM, Kenneth wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>
>> // This script assumes the depth effect is *linear* from near to far,
>> which may not be the case.
>
> I've been thinking about that as well. My opinion is that it's NOT linear-- that
> the RED/BLUE 'mix' should not be equal across the model (and/or that the
> mid-point 'mix line' should not extend exactly to the mid-point of the model or
> of a larger entire scene.) The analogy I thought of was the visual effect of
> looking through binoculars at distant objects: The 3-D effect is reduced there;
> objects at different distances look kind of like flat planes, because our eyes
> are only _____ inches apart (not much parallax.) And MUCH more of a 3-D effect
> looking at closer objects.
>
Well, you can see this effect in POV-Ray too if you change the camera's
angle parameter.
https://commons.wikimedia.org/wiki/File:Camera_focal_length_distance_house_animation.gif
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-2-2018 17:13, Kenneth wrote:
> So, I finally coded-up my idea, and it does indeed put the 'center' color of the
> color_map across the center of the object. That part works, at least. But the
> color pattern's 'limits' on the object have a problem: the color spread doesn't
> extend all the way across. So far, after several days of trying to figure out
> why, I still don't have a clue. I tried changing *every* parameter in the code,
> but no luck-- although there's probably a hidden 'clue' in those trials.
>
> So, I had to resort to some fudge-factors as well :-/
As far as I know from docs and/of previous discussions, min_extent and
max_extent do not give the /exact/ extent of the object. So, I am not
really surprised you need a fudge factor...
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/20/2018 2:43 AM, Thomas de Groot wrote:
> On 19-2-2018 17:13, Kenneth wrote:
>> So, I finally coded-up my idea, and it does indeed put the 'center'
>> color of the
>> color_map across the center of the object. That part works, at least.
>> But the
>> color pattern's 'limits' on the object have a problem: the color
>> spread doesn't
>> extend all the way across. So far, after several days of trying to
>> figure out
>> why, I still don't have a clue. I tried changing *every* parameter in
>> the code,
>> but no luck-- although there's probably a hidden 'clue' in those trials.
>>
>> So, I had to resort to some fudge-factors as well :-/
>
> As far as I know from docs and/of previous discussions, min_extent and
> max_extent do not give the /exact/ extent of the object. So, I am not
> really surprised you need a fudge factor...
>
LDraw models all have bounding boxes defined during the conversion
process. I will try and see if I still need any fudge factors after
plugging those values in instead of min_extent and max_extent.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/20/2018 4:50 AM, Mike Horvath wrote:
> On 2/20/2018 2:43 AM, Thomas de Groot wrote:
>> On 19-2-2018 17:13, Kenneth wrote:
>>> So, I finally coded-up my idea, and it does indeed put the 'center'
>>> color of the
>>> color_map across the center of the object. That part works, at least.
>>> But the
>>> color pattern's 'limits' on the object have a problem: the color
>>> spread doesn't
>>> extend all the way across. So far, after several days of trying to
>>> figure out
>>> why, I still don't have a clue. I tried changing *every* parameter in
>>> the code,
>>> but no luck-- although there's probably a hidden 'clue' in those trials.
>>>
>>> So, I had to resort to some fudge-factors as well :-/
>>
>> As far as I know from docs and/of previous discussions, min_extent and
>> max_extent do not give the /exact/ extent of the object. So, I am not
>> really surprised you need a fudge factor...
>>
>
> LDraw models all have bounding boxes defined during the conversion
> process. I will try and see if I still need any fudge factors after
> plugging those values in instead of min_extent and max_extent.
>
>
> Mike
I attached the macros I created based on your code. However, it still
requires some labor on the user's part, since the camera could be
located anywhere, and not necessarily closest to the minimum extent or
farthest from the maximum extent, etc. There needs to be some way to
automatically determine which of the bounding box's 8 corners is the
closest and which is the farthest from the camera.
Mike
Post a reply to this message
Attachments:
Download 'utf-8' (2 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
>
> As far as I know from docs and/of previous discussions, min_extent and
> max_extent do not give the /exact/ extent of the object. So, I am not
> really surprised you need a fudge factor...
>
I assumed that a really simple object like my cylinder wouuld have a
well-defined, close-fitting bounding box. The strange thing is, I still don't
fully understand why the color_map spread on the object is so narrow (when not
using the fudge factors). I keep thinkling that my code has a conceptual error
somewhere-- but if so, I haven't yet found it. In theory, it should be doing
what I want it to do.
My own first thoughts were about a possible bounding-box error as well. But that
seems kind of strange, the reason being that the color_map 'spread boundaries'
actually increases across more of the object-- a wider color_map appearance--the
closer the object is to the camera position. I would think that the spread would
remain constant, *if* the bounding-box error was constant as well. Which keeps
leading me back to wondering if there's a conceptual error... ;-/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmailcom> wrote:
>
> I attached the macros I created based on your code. However, it still
> requires some labor on the user's part, since the camera could be
> located anywhere, and not necessarily closest to the minimum extent or
> farthest from the maximum extent, etc. There needs to be some way to
> automatically determine which of the bounding box's 8 corners is the
> closest and which is the farthest from the camera.
>
Hmm, an interesting thought.
I've always assumed that finding vlength to the min_extent/max_extent
bounding-box positions would never fail to return the proper spatial
coordinates, regardless of what 'orientation' the object was in, relative to the
vlength 'shoot-from' position. In other words (AFAIU) the object itself has
'set' bounding box corner values for the particular spatial location that it's
at-- values relative to the origin at <0,0,0> (and which can naturally *change*
depending on the object's rotation, for example-- i.e., the corners shift
around.) And that there's always *some* set of distinct nearest-corner and
farthest-corner values, *as referenced to the vlength shoot-from position*, not
the origin. My assumption is that the vlength/min_extent/max_extent combination
would *always* pick out what IT sees as the nearest corner and farthest corner,
relative to itself (not relative to the <0,0,0> origin.)
If I'm wrong about any of this, then my code concept is wrong as well, in a
strangely subtle way.
I do recall past discussions in 'the old days' that there were some problems
with bounding boxes not being translated (rotated?) correctly when the object
itself was; but that was fixed, ASAIK.
The answer to all this may be buried in my #debug messages-- all the various
values returned-- but it looks like some vector analysis is required to tease
out an answer. Ugh.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't have time at the moment to sift through your code or write any of my
own, but I'll make a few observations and [hopefully helpful] comments.
First, make sure your camera position and object-camera line of sight are
normalized to be along a primary axis.
Then the bounding box, pattern alignment, and distance calculations are easy to
calculate, code, and align properly.
Once you have done that, apply your pattern and then UNdo it - which will shift
the pattern along with the object.
Truly a place where "letting POV-Ray do the heavy lifting" for the vector math
and matrix transforms is strongly advisable.
finding the nearest part of the bounding box ought to be as simple as min (a, b,
c, d, e, f, g, h) where a-h are distances from the camera to the bb corners.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> finding the nearest part of the bounding box ought to be as simple as min (a, b,
> c, d, e, f, g, h) where a-h are distances from the camera to the bb corners.
Nice idea. I did it another way-- making a semi-transparent box object using the
min_extent/max_extent coordinates, with the box superimposed on my disc object.
I'm running some visual tests at the moment-- and those corner coordinates ARE
part of the problem, especially if the object happens to be pre-rotated. I'm
sifting through the results, and will report back.
What it looks like so far is that, if I (pre-)rotate the object before being
translated, the ''near' and 'far' bounding_box corners are actually rotating
along with the object-- i.e., their 'near' and 'far' relationship appears to be
reversing! (Or vlength is choosing the wrong corner?) My L_1/L_2 equation and
its #debug message bear this out. If that is expected behavior, it's a surprise
to me. Very mysterious.
Meanwhile, I did another test with my code to make sure the idea itself-- with
the various scalings and transformations-- is sound. (I made some visible sphere
objects that 'mimic' the location of camera and object, and the distance between
them.) It looks like the code itself is working exactly the way I intended.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
