POV-Ray : Newsgroups : povray.tools.general : Norbert Kern's 'Position-Finder' code-- redux Server Time
12 Jun 2024 14:32:33 EDT (-0400)
  Norbert Kern's 'Position-Finder' code-- redux (Message 21 to 23 of 23)  
<<< Previous 10 Messages Goto Initial 10 Messages
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.