POV-Ray : Newsgroups : povray.tools.general : Norbert Kern's 'Position-Finder' code-- redux : Re: Norbert Kern's 'Position-Finder' code-- redux Server Time
28 Feb 2024 06:51:17 EST (-0500)
  Re: Norbert Kern's 'Position-Finder' code-- redux  
From: Kenneth
Date: 26 Sep 2018 18:10:00
Message: <web.5bac01adbb085d6ca47873e10@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> wrote:
> On 26-9-2018 8:32, Thomas de Groot wrote:
> > Something else though, troubles me from even before your work. There are
> > scenes where the results from the trace are significantly away from the
> > initial screen position given to the macro...
> >
>
> I have got a test scene where the problem is demonstrated...

Yes, I've noticed as well that the found translation doesn't always agree with
the 'point-of-interest' that's chosen. I think the problem is based on the given
camera angle. In my earlier tests, I tried to include a slight 'fudge factor'
value to correct for this-- but found that the value needed to change
dynamically (in a way that I couldn't figure out.) It *may* be because screen
size vs. camera angle is not a 'linear' relationship(?), although I haven't
really investigated that, nor as to how Norbert's code is actually using cam_ang
in his math. As a practical solution, my *own* fix for this position problem is
to simply change the found translation vector values until things look correct!
:-P

BTW, I noticed a slight mistake in your code:
[Given]
//=======================================
// TEST ROD
// ======================================
//Rod at position given by:
//#declare screen_x_position = 260;
//#declare screen_y_position = 850;
cylinder {<0,0,0>, <0,100,0>,5 pigment {rgb <1,1,0>}
translate <-2426.313, -269.700, -1300.118>
}

..... but the actual translation that's returned from those screen percentages is
translate <-2315.395, -298.978, -1668.753>

There's still a position error, but not quite as large.

As an experiment to see the effect of a changing camera angle, try this (but
first make your rod object a little taller--
cylinder {<0,0,0>, <0,500,0>,5

Then,
CamAng (or cam_ang) = 15;

ROD translation:
translate <-2180.222, -99.162, -876.054>

Now, try to choose the screen coordinates of the rod on your Landscape
(screen_x_position and screen_y_position.) My own visual attempt is at the
screen precentages 126,873-- which places the arrow almost exactly where it's
supposed to go  :-)

But now, change CamAng to 80 (leaving the rod where it is), and repeat the
trial. (Hopefully, you can still see the rod!) My best guess for the new screen
percentages is 442,558-- and there's now a slight offest in the arrow position.

As a practical solution to the offset problem, it's probably best to use more of
a 'zoom' camera angle to initially choose a point-of-interest and to place the
object.

(BTW: Gille's macro doesn't appear to interfere in any way with the
position-finder macro or vice-versa, so no worries there. Neither macro depends
on the other, as they are different as to their purposes, so both can be used at
the same time-- as you have been doing, of course.)


Post a reply to this message

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