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

> #local ScreenLoc_1 = Get_Screen_XY(SphereLoc_1);
> sphere {SphereLoc_1, 0.1 pigment {Cyan}}

Having used the old screen.inc, and just giving the code here a cursory look - I
would say yes.
All of that stuff just seems to be his scene code for placing the spheres at the
corners of that rotated cube.
The only important thing is the macro call.

Post a reply to this message

I added another, simpler sample scene to the wiki article.


Mike

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> For ages I have been using Norbert Kern's
> position_finder.pov macro from 2006
>
>
http://news.povray.org/povray.binaries.scene-files/attachment/%3Cweb.4478509041a06b1c9bff7e8b0%40news.povray.org%3E/p
osition_finder.pov.txt
>

For anyone who's interested, here's the link to Norbert's original post (which
took me awhile to find)...

http://news.povray.org/povray.binaries.images/thread/%3Cweb.44784f2141a06b1c9bff7e8b0%40news.povray.org%3E/?ttop=423977
&toff=3700

It's not very detailed, unfortunately.

Thomas, I've been playing around with his code, and I see where some
improvements can be made. One of the problems I've come across is that the code
itself seems to be built around a 'backward'-facing camera (i.e., the camera
position and look_at point resulting in a -z look_at direction.) With a regular
forward-facing camera, the code produces some odd results (and fixing things is
apparently not just a simple matter of tweaking only one thing.) But I'm
continuing to work at it...and to find some way to improve it's accuracy (which
I suspect is due to whatever particular camera angle is used-- it *seems* to be
more accurate with a 'zoom' angle rather than wide-angle.) It's quite a
'magical' piece of code otherwise.

Post a reply to this message

On 9/1/2018 9:54 PM, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> For ages I have been using Norbert Kern's
>> position_finder.pov macro from 2006
>>
>>
http://news.povray.org/povray.binaries.scene-files/attachment/%3Cweb.4478509041a06b1c9bff7e8b0%40news.povray.org%3E/p
> osition_finder.pov.txt
>>
> 
> For anyone who's interested, here's the link to Norbert's original post (which
> took me awhile to find)...
> 
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.44784f2141a06b1c9bff7e8b0%40news.povray.org%3E/?ttop=423977
> &toff=3700
> 
> It's not very detailed, unfortunately.
> 
> Thomas, I've been playing around with his code, and I see where some
> improvements can be made. One of the problems I've come across is that the code
> itself seems to be built around a 'backward'-facing camera (i.e., the camera
> position and look_at point resulting in a -z look_at direction.) With a regular
> forward-facing camera, the code produces some odd results (and fixing things is
> apparently not just a simple matter of tweaking only one thing.) But I'm
> continuing to work at it...and to find some way to improve it's accuracy (which
> I suspect is due to whatever particular camera angle is used-- it *seems* to be
> more accurate with a 'zoom' angle rather than wide-angle.) It's quite a
> 'magical' piece of code otherwise.
> 

Could you provide a sample where the script fails? I tried a +z to -z 
camera direction, as well as a wide angle, and the numbers seemed okay.


Mike

Post a reply to this message

On 2-9-2018 3:54, Kenneth wrote:
> Thomas, I've been playing around with his code, and I see where some
> improvements can be made. One of the problems I've come across is that the code
> itself seems to be built around a 'backward'-facing camera (i.e., the camera
> position and look_at point resulting in a -z look_at direction.) With a regular
> forward-facing camera, the code produces some odd results (and fixing things is
> apparently not just a simple matter of tweaking only one thing.) But I'm
> continuing to work at it...and to find some way to improve it's accuracy (which
> I suspect is due to whatever particular camera angle is used-- it *seems* to be
> more accurate with a 'zoom' angle rather than wide-angle.) It's quite a
> 'magical' piece of code otherwise.
> 

You are right. Over time, I have "improved" on the code, one of the 
improvements being the possibility to use true 2D screen coordinates 
instead of percentages. Also that "facing" problem is more or less 
tackled I think, although I regularly have cases where it does not work. 
However, It mostly works and I light a candle to Saint Norbert each 
time. :-)

Anyway, find here my version attached.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'utf-8' (8 KB)

On 2-9-2018 8:41, Thomas de Groot wrote:
> Anyway, find here my version attached.
> 

I see (too late, sorry) that for my version you may need the following 
macro too, but only for the testing of the position finder, otherwise 
not. And you can replace that by your own stuff of course.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'utf-8' (12 KB)

Mike Horvath <mik### [at] gmailcom> wrote:
>
> Could you provide a sample where the script fails? I tried a +z to -z
> camera direction, as well as a wide angle, and the numbers seemed okay.
>

If you can pull up Norbert's original pristine file, add these test objects to
the scene (they're independent of his code-- they're just origin markers to see
what's going on)...

union{
cylinder{0,.4*x .012} // X
cylinder{0,.4*y .012} // Y
cylinder{0,.4*z .012} // Z
text{ttf "cyrvetic.ttf" "+ X" 0.1, 0 rotate 90*x scale .15
     translate <.4,.03,0>} // " + X"
text{ttf "cyrvetic.ttf" "+ Y" 0.1, 0 scale .15
     translate <-.1,.4,0>} // " + Y"
text{ttf "cyrvetic.ttf" "+ Z" 0.1, 0 rotate 90*x scale .15
     translate <-.1,.03,.45>} // "+ Z"
     translate .32*y
     pigment{rgb <.2,.2,1>}
   }

Now set his x_pos and y_pos variables to...
#declare x_pos = 20;
#declare y_pos = 90;

Now, run his code, with no no other changes. (Note that his camera is facing -z
by default, not the usual +z.) In the render, the 'positive' x-axis direction is
still facing to the right, when it should be to the left. (It's like the render
has been 'mirrored.') He does include a 'mirror' variable within the macro-- a
switch from +1 to -1 -- which will fix that-- but it also flips his on-screen
text (next to the arrow,) so don't use it.

Now, change his camera to a forward-looking one. Try this...
#declare cam_loc = <-.5,1.8,-3>;
#declare lookat  = <.1,0.2,2>;

In this render, the axis markers look correct, the arrow's text looks correct--
but the arrow is actually on the wrong side of the screen now (left to right).
The x_pos of 20 should put it on the left, but it's now on the right.

Most of this behavior requires only minor fixes (some of which I've managed to
figure out, in a quick-and-dirty way) but I'm still testing things.

And I haven't yet taken a look at Thomas's newer code, to see what goodies he
has come up with...

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 2-9-2018 3:54, Kenneth wrote:
> > Thomas, I've been playing around with [Norbert's] code, and I see where some
> > improvements can be made...
>
> You are right. Over time, I have "improved" on the code, one of the
> improvements being the possibility to use true 2D screen coordinates
> instead of percentages. Also that "facing" problem is more or less
> tackled I think, although I regularly have cases where it does not work.
> However, It mostly works and I light a candle to Saint Norbert each
> time. :-)
>
> Anyway, find here my version attached.
>

hey, I think I've figured out most of the needed changes-- after a marathon
coding session ;-)  I still haven't taken a look at your own code (yet!) ; I
first wanted to see what I could come up with. I'll probably post my version
(along with some needed instructions on how to use it), but I'll do it
elsewhere, so as not to hi-jack this thread any further.

It will be fun to compare the two independent approaches we've come up with.

Post a reply to this message

On 4-9-2018 1:13, Kenneth wrote:
> 
> It will be fun to compare the two independent approaches we've come up with.
> 

I am looking forward to it. My version is just cosmetic stuff so I 
expect yours to be fundamentally better.

-- 
Thomas

Post a reply to this message

On 9/2/2018 3:43 AM, Kenneth wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>>
>> Could you provide a sample where the script fails? I tried a +z to -z
>> camera direction, as well as a wide angle, and the numbers seemed okay.
>>
> 
> If you can pull up Norbert's original pristine file, add these test objects to
> the scene (they're independent of his code-- they're just origin markers to see
> what's going on)...
> 

Oh, I wasn't sure if you were talking about Norbert's script or 
"screen.inc".


Mike

Post a reply to this message