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]
> //=======================================
> // 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.

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

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

-- 
Thomas

Post a reply to this message