POV-Ray : Newsgroups : povray.tools.general : Norbert Kern's 'Position-Finder' code-- redux : Re: Norbert Kern's 'Position-Finder' code-- redux Server Time
26 Feb 2024 20:28:21 EST (-0500)
  Re: Norbert Kern's 'Position-Finder' code-- redux  
From: Thomas de Groot
Date: 27 Sep 2018 03:14:23
Message: <5bac834f$1@news.povray.org>
On 27-9-2018 0:09, Kenneth wrote:
> 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

Yep! That was my practical solution too! :-) Still, I do not quite 
understand /why/ this happens though. My naive reasoning would tell me 
it should not, but then of course, what do I know about the deeper 
arcane workings of ray-tracing?

> BTW, I noticed a slight mistake in your code:
> [Given]
> //=======================================
> // ======================================
> //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.

That is bizarre because I literally copied the translation values from 
the screen. So there seems to be a slight difference between computers 

> 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.

I am going to do this homework thoroughly...

> (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.)

I thought you would be interested. It is very helpful to me as I 
regularly automatically trace large number of objects (like trees) on my 
landscapes. It helps to sift out all those positions falling outside of 
the screen.


Post a reply to this message

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