POV-Ray : Newsgroups : povray.tools.general : Norbert Kern's 'Position-Finder' code-- redux Server Time
29 Mar 2024 05:46:45 EDT (-0400)
  Norbert Kern's 'Position-Finder' code-- redux (Message 14 to 23 of 23)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
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

From: Kenneth
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
Date: 27 Sep 2018 00:10:01
Message: <web.5bac571cbb085d6ca47873e10@news.povray.org>
"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

From: Thomas de Groot
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
Date: 27 Sep 2018 02:43:37
Message: <5bac7c19$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
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]
> //=======================================
> // 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

From: Kenneth
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
Date: 27 Sep 2018 14:30:07
Message: <web.5bad2103bb085d6ca47873e10@news.povray.org>
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

From: Bald Eagle
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
Date: 27 Sep 2018 15:05:00
Message: <web.5bad293ebb085d6cc437ac910@news.povray.org>
"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

From: Stephen
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
Date: 27 Sep 2018 15:30:00
Message: <5bad2fb8$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
Date: 28 Sep 2018 02:27:26
Message: <5badc9ce$1@news.povray.org>
On 27-9-2018 21:29, Stephen wrote:
> 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/
> 

Thanks! That is very useful!

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
Date: 28 Sep 2018 03:30:47
Message: <5badd8a7@news.povray.org>
On 27-9-2018 20:29, Kenneth wrote:
> 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!!

Ouch! glad it is solved! I should have mentioned the change in aspect 
ratio. One of the things I tested was if widely different aspect ratio's 
influenced the outcome, but no.

Something I thought about this night: would the height_field resolution 
influence the trace? compared to a primitive object? Answer: no, it does 
not.

Next, after I restored the lineation on the height_field, I found 
something for your thoughts. It appears, at least in my test file, that 
the shift is /only/ along the z-axis, and furthermore, that the shift 
approximates 200 pov units. Is that chance? Is it significant? I have no 
idea (yet).

The restored height_field looks like this:

//start code
height_field {
     function 500,500 {pattern {bozo scale 0.08}}
     smooth
     translate <-0.5, 0, -0.5>
     texture {
       pigment {
         average
         pigment_map {
           [1.0 rgb <0.5, 1, 0.3>]
           [0.6 gradient x frequency 100
                color_map {
                  [0.07 rgb -0.3]
                  [0.07 rgb <0.7, 1, 0.7>]
                }
              ]
           [0.6 gradient z frequency 100
                color_map {
                  [0.07 rgb -0.3]
                  [0.07 rgb <0.7, 1, 0.7>]
                }
              ]
         }
       }
       finish {ambient 0 diffuse 0.5}
     }
     scale HF_scale
     translate -HF_scale.y*y
     scale <1, 0.5, 1>
   }
//end code

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

I did, and the results are certainly better when using the zoom effect.

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

Me too...


-- 
Thomas


Post a reply to this message

From: Stephen
Subject: Re: Norbert Kern's 'Position-Finder' code-- redux
Date: 28 Sep 2018 04:12:57
Message: <5bade289$1@news.povray.org>
On 28/09/2018 07:27, Thomas de Groot wrote:
> On 27-9-2018 21:29, Stephen wrote:

>>
>> 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/
>>
> 
> Thanks! That is very useful!
> 

I have been using it for a couple of years and it is probably my most 
used utility. In Pov you might need to change he message pane, font and 
size for the OCR to work properly in English. I have not tried using any 
of the other languages or translation functions.



-- 

Regards
     Stephen


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

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