On 25-9-2018 22:12, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>>> I like it! I really do, and I shall replace my own version with yours.
> 
>>>
>>> I may re-instate my 'kludge' fixes for some of the remaining traced 'normal'
>>> behavior...
> 
> I've just come across another subtle flaw in the code-- NOT normal-related--
> that's probably been there since my *early* experiments. I  may have introduced
> it with my own fixes, I don't know. Basically, *sometimes* the arrow or 'new'
> object suddenly flips from one side of the preview render to the other. But it
> happens only with certain juxtapositions of camera and lookat point, and their
> positions relative to the x/y plane at the origin. It's strange that I didn't
> see this flaw previously,  even after 100-plus tests of the code! (All my
> previsous tests just happened to avoid this situation, amazingly.)
> 
> Luckily, I've been able to deduce the 'rules' that govern this behavior, so I'll
> add a fix for it-- as soon as I figure out how ;-)
> 

That is strange and I have no clue - nor experience - about this.

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 shall try to get a demo 
scene together where this is demonstrated.

-- 
Thomas

Post a reply to this message

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 shall try to get a demo 
> scene together where this is demonstrated.
> 

I have got a test scene where the problem is demonstrated. I attach it 
here, together with a slightly changed version of your position finder 
and Gilles Tran's Visibility Test macro (which might be necessary). This 
last one I often use to get the right zoom value for the camera in order 
to calculate traces exactly within the visible screen scene. If I make 
myself understood... I don't think however, from my testing, that that 
influences the issue at hand in any way.

I am curious to learn what you think.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'islaytest.7z.zip' (6 KB)

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> I have got a test scene where the problem is demonstrated. I attach it
> here, together with a slightly changed version of your position finder
> and Gilles Tran's Visibility Test macro...

Thanks! I will investigate this. Gille's macro is also new to me-- so
double-thanks for bringing it to my attention :-)

My many code trials have been real brain-twisters; sometimes one 'fix'
introduces yet another problem. At times, I've had to step away from the code to
regain my sanity ;-) But it's *slowly* improving as I continue work on it.

Post a reply to this message

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

"Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > 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.... It *may* be because screen
> size vs. camera angle is not a 'linear' relationship(?)...

Sorry if that sounded confusing; 'screen size' was the wrong phrase. What I
meant was, there may be a non-linear relationship between camera angle and the
resulting view in a render or screen preview-- meaning, as the angle value goes
higher (more wide-angle), the camera view takes in a larger portion of the
scene, but the change may not follow a strictly linear relationship to the
changing angle. (The change in the 'visual' distance between two objects, vs.
the
real POV-ray distance there.) I've never tested this; it would be interesting
to construct a plot of distance values (as seen in the preview render,
horizontally for example) with the camera angle changing all the way from 1 to
90(!)

Post a reply to this message

On 27-9-2018 6:09, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>>
>>> 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.... It *may* be because screen
>> size vs. camera angle is not a 'linear' relationship(?)...
> 
> Sorry if that sounded confusing; 'screen size' was the wrong phrase. What I
> meant was, there may be a non-linear relationship between camera angle and the
> resulting view in a render or screen preview-- meaning, as the angle value goes
> higher (more wide-angle), the camera view takes in a larger portion of the
> scene, but the change may not follow a strictly linear relationship to the
> changing angle. (The change in the 'visual' distance between two objects, vs.
> the
> real POV-ray distance there.) I've never tested this; it would be interesting
> to construct a plot of distance values (as seen in the preview render,
> horizontally for example) with the camera angle changing all the way from 1 to
> 90(!)
> 

You have brought a couple of interesting things to my attention. I have 
scratched my head a lot in the past without results, so now I am going 
to test this again: My next week-end seems booked ;-)

-- 
Thomas

Post a reply to this message

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

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 27-9-2018 0:09, Kenneth wrote:
> > Thomas de Groot <tho### [at] degrootorg> wrote:

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

Well, I discovered why we arrived at different values: It was a really simple
and dumb mistake I made. I've been running your code tests at 800X600
resolution; I didn't notice that your own tests used 1280X640. Uh, that does
make a difference :-)  Using your aspect ratio, my values now agree with yours.
Duh. Sorry for the confusion-- and I'm glad it turned out to be so simple!!
> >
> > As an experiment to see the effect of a changing camera angle, try this...

Well, those values are now wrong as well :-O  Although, it would still be useful
for you to run two renders with vastly different camera angle values, to see how
the found translation value gets more accurate at 'telephoto/zoom' settings.

BTW, Norbert's position-finder code also #debugs the found rotation/translation
values to the message pane. My own (Windows) set-up for *using* those values is
to go there, then EDIT/COPY PANE, then paste the contents into Windows' Wordpad
or Notepad. Then, I re-copy the two values and simply paste them into my scene
code. (Instead of copying them by eye from the preview render.) It's fast and
foolproof.

Meanwhile, I continue working...

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> BTW, Norbert's position-finder code also #debugs the found rotation/translation
> values to the message pane. My own (Windows) set-up for *using* those values is
> to go there, then EDIT/COPY PANE, then paste the contents into Windows' Wordpad
> or Notepad. Then, I re-copy the two values and simply paste them into my scene
> code. (Instead of copying them by eye from the preview render.) It's fast and
> foolproof.


I had the idea that it would be a handy feature to be able to write directly to
the clipboard from POV-Ray.
Not sure how much that would take under-the-hood to do...

Post a reply to this message

On 27/09/2018 19:29, Kenneth wrote:
>   My own (Windows) set-up for*using*  those values is
> to go there, then EDIT/COPY PANE, then paste the contents into Windows' Wordpad
> or Notepad. Then, I re-copy the two values and simply paste them into my scene
> code. (Instead of copying them by eye from the preview render.) It's fast and
> foolproof.


There is a nice little TRS utility called Capture2Text that selects a 
portion of your screen then OCR's the text and copies it to the 
clipboard. I find it very handy.

http://capture2text.sourceforge.net/

-- 

Regards
     Stephen

Post a reply to this message