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)