I just created a new tutorial about how to calculate very precise values 
for the 2D screen coordinates of objects in a POV-Ray render.

http://wiki.povray.org/content/HowTo:Output_2D_screen_coordinates#Sample_Scene

LMKWYT


Mike

Post a reply to this message

On 31-8-2018 4:39, Mike Horvath wrote:
> I just created a new tutorial about how to calculate very precise values 
> for the 2D screen coordinates of objects in a POV-Ray render.
> 
> http://wiki.povray.org/content/HowTo:Output_2D_screen_coordinates#Sample_Scene 
> 
> 
> LMKWYT
> 
> 
> Mike

Thank you indeed! Very useful. Noting it does exactly the opposite of 
what I generally do :-) For ages I have been using Norbert Kern's 
position_finder.pov macro from 2006, to get (with variable precision I 
must confess) a position somewhere on a 3D landscape or object, 
calculated from a 2D render of the scene. I then use the found 3D 
coordinates to place new objects in the scene.

http://news.povray.org/povray.binaries.scene-files/attachment/%3Cweb.4478509041a06b1c9bff7e8b0%40news.povray.org%3E/position_finder.pov.txt

-- 
Thomas

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:
> I just created a new tutorial about how to calculate very precise values
> for the 2D screen coordinates of objects in a POV-Ray render.
>

That is very cool! I'm already trying to think of other offbeat uses for it.

Just a suggestion (truly off the top of my head): Would it be possible in some
way to incorporate some of the complex-looking SCENE code (in your wiki example)
into an 'additional' #macro or .inc file, that could then 'call' the new
Screen.inc? (Assuming that those parts are 'generic' for any scene.) If I'm
correctly grasping your wiki example from a 'first look', there are currently
some required scene code entries like...

#local TempAngle = pi/2 - atan(1/cos(pi/4));
#local TempTrans = transform
{
 rotate  +x * 45
 rotate  +z * degrees(TempAngle)
 translate +y * sin(TempAngle)
 translate +y * 1/10
}

....and

#local SphereLoc_1 = vtransform(-x, TempTrans);  [etc.]

I'm wondering if this stuff could be 'hidden' from the user (within the
additional macro or inc file), so that the only actual scene code required would
be  something like...

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

Sorry if my idea seems too simplistic (or just dumb!), but it's my first thought
on seeing the wiki's example code and its 'apparent' complexity. Maybe I'm not
yet grasping which scene code elements are truly part of the 'main idea.'

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

*That* looks quite useful as well; thanks for the link. I must have missed it
way back in '06.

Post a reply to this message

On 8/31/2018 11:15 PM, Kenneth wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> I just created a new tutorial about how to calculate very precise values
>> for the 2D screen coordinates of objects in a POV-Ray render.
>>
> 
> That is very cool! I'm already trying to think of other offbeat uses for it.
> 
> Just a suggestion (truly off the top of my head): Would it be possible in some
> way to incorporate some of the complex-looking SCENE code (in your wiki example)
> into an 'additional' #macro or .inc file, that could then 'call' the new
> Screen.inc? (Assuming that those parts are 'generic' for any scene.) If I'm
> correctly grasping your wiki example from a 'first look', there are currently
> some required scene code entries like...
> 
> #local TempAngle = pi/2 - atan(1/cos(pi/4));
> #local TempTrans = transform
> {
>   rotate  +x * 45
>   rotate  +z * degrees(TempAngle)
>   translate +y * sin(TempAngle)
>   translate +y * 1/10
> }
> 
> ....and
> 
> #local SphereLoc_1 = vtransform(-x, TempTrans);  [etc.]
> 
> I'm wondering if this stuff could be 'hidden' from the user (within the
> additional macro or inc file), so that the only actual scene code required would
> be  something like...
> 
> #local ScreenLoc_1 = Get_Screen_XY(SphereLoc_1);
> sphere {SphereLoc_1, 0.1 pigment {Cyan}}
> 
> Sorry if my idea seems too simplistic (or just dumb!), but it's my first thought
> on seeing the wiki's example code and its 'apparent' complexity. Maybe I'm not
> yet grasping which scene code elements are truly part of the 'main idea.'
> 

I could replace the "hedgehog" with something simpler, such as a box or 
pyramid. Thanks for the suggestion!


Mike

Post a reply to this message

"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