I modified screen.inc so that it works with orthographic cameras as 
well. Simply add "yes" or "no" as a new parameter when calling the 
"Set_Camera" macro.

There are some glitches, however. In the demo scene, setting the 
"scaling" parameter to low values (i.e. below 1) causes artifacts when 
orthographic mode is turned on. Also, while the crosshairs are visible, 
the pigment/texture looks a lot different than when using a 
non-orthographic camera.

Anyone have any idea how to fix these?

Thanks.

Mike

Post a reply to this message

On 11/12/2009 10:07 PM, SharkD wrote:
> I modified screen.inc so that it works with orthographic cameras as
> well. Simply add "yes" or "no" as a new parameter when calling the
> "Set_Camera" macro.
>
> There are some glitches, however. In the demo scene, setting the
> "scaling" parameter to low values (i.e. below 1) causes artifacts when
> orthographic mode is turned on. Also, while the crosshairs are visible,
> the pigment/texture looks a lot different than when using a
> non-orthographic camera.
>
> Anyone have any idea how to fix these?
>
> Thanks.
>
> Mike

Forgot to attach the file.

Mike

Post a reply to this message

Attachments:
Download 'screen.inc.txt' (6 KB)

On 11/12/2009 10:08 PM, SharkD wrote:
> Forgot to attach the file.
>
> Mike

Slightly tweaked version. Also, the demo scene which I forgot to add 
earlier.

Mike

Post a reply to this message

Attachments:
Download 'screen.inc.txt' (6 KB) Download 'screen.pov.txt' (6 KB)

Update:

Includes the changes I made in my last post to enable the script to work 
with orthographic cameras. Also includes a new macro called 
"Get_Screen_XY" to return the 2D screen location of a set of 3D coordinates.

The lighting/material issues WRT the crosshairs and orthographic cameras 
remains unresolved.

Mike

Post a reply to this message

Attachments:
Download 'screen.pov.txt' (7 KB) Download 'screen.inc.txt' (6 KB)

"SharkD" <mik### [at] gmailcom> wrote in message 
news:4b00c2b6$1@news.povray.org...
> Update:
>
> Includes the changes I made in my last post to enable the script to work
> with orthographic cameras. Also includes a new macro called
> "Get_Screen_XY" to return the 2D screen location of a set of 3D 
> coordinates.
>
> The lighting/material issues WRT the crosshairs and orthographic cameras
> remains unresolved.
>
> Mike

Very cool, indeed... looking forward to trying it out. :D Thanks for the 
work.

Post a reply to this message

On 11/16/2009 9:13 AM, Captain Jack wrote:
> Very cool, indeed... looking forward to trying it out. :D Thanks for the
> work.

I know of one bug already. I've already fixed it and will upload it 
soon. Let me know if you notice any others.

Mike

Post a reply to this message

"SharkD" <mik### [at] gmailcom> wrote in message 
news:4b01c27b$1@news.povray.org...
> On 11/16/2009 9:13 AM, Captain Jack wrote:
>> Very cool, indeed... looking forward to trying it out. :D Thanks for the
>> work.
>
> I know of one bug already. I've already fixed it and will upload it soon. 
> Let me know if you notice any others.
>
> Mike

I'm setting up an animation now... my goal is to create a text file that 
lists, for each frame, the pixel position of an object I'm tracking in the 
scene. I'll try to get it  tested by tomorrow.

--
Jack

Post a reply to this message

OK, here's the latest version. I added support for specifying the camera 
direction, right and up vectors directly. Use the macro "Set_Camera_Alt" 
instead of "Set_Camera" if you want this. Please report any bugs you may 
encounter. I tested versus a series of scenes including ones with 
perspective projection, orthographic projection and even oblique 
projection. I also tested different aspect ratios and output sizes. I 
may have missed something however.

Mike

Post a reply to this message

Attachments:
Download 'screen.inc.txt' (8 KB)

On 11/17/2009 7:53 AM, SharkD wrote:
> OK, here's the latest version. I added support for specifying the camera
> direction, right and up vectors directly. Use the macro "Set_Camera_Alt"
> instead of "Set_Camera" if you want this. Please report any bugs you may
> encounter. I tested versus a series of scenes including ones with
> perspective projection, orthographic projection and even oblique
> projection. I also tested different aspect ratios and output sizes. I
> may have missed something however.
>
> Mike


Ooops. had some values reversed.

Mike

Post a reply to this message

Attachments:
Download 'screen.inc.txt' (8 KB)

"SharkD" <mik### [at] gmailcom> wrote in message 
news:4b02a514$1@news.povray.org...
> On 11/17/2009 7:53 AM, SharkD wrote:
>> OK, here's the latest version. I added support for specifying the camera
>> direction, right and up vectors directly. Use the macro "Set_Camera_Alt"
>
> Mike
>

I'm rendering an animation now where I'm tracking part of the object using 
the Get_Screen_XY function to build a file of screen coordinates. Once I get 
that run, I'll try importing the data into another program and comping the 
results. So far, it seems to be working fine and I haven't gotten any 
errors; looks great, Mike.

--
Jack

Post a reply to this message

Update.

Seems I was making things a lot harder than they needed to be. I also 
encountered further bugs. The new version of "Get_Screen_XY" is *a lot* 
simpler. The good news is that if you didn't have problems before (i.e. 
you were using "Set_Camera" and perspective projection instead of 
"Set_Camera_Alt" or orthographic projection), then you shouldn't notice 
a difference.

Mike

Post a reply to this message

Attachments:
Download 'screen.inc.txt' (8 KB)

"SharkD" <mik### [at] gmailcom> wrote in message 
news:4b035479$1@news.povray.org...
> Update.
>
> Seems I was making things a lot harder than they needed to be. I also
> encountered further bugs. The new version of "Get_Screen_XY" is *a lot*
> simpler. The good news is that if you didn't have problems before (i.e.
> you were using "Set_Camera" and perspective projection instead of
> "Set_Camera_Alt" or orthographic projection), then you shouldn't notice
> a difference.
>
> Mike
>

Cool... I hadn't read through the Get_Screen_XY macro yet, but I did write a 
scene to test it, which I've attached. The macro worked exactly as expected, 
with no errors. The animation itself is of a group of three balls connected 
by springs that float around the screen. I had the program create a text 
file giving the screen coordinates for the center of one of the spheres in a 
format that can be read by Particle Illusion. I Rendered the scene in POV, 
then I imported the text file into PI, then composited the whole thing over 
a background picture, and everything lined up exactly right with no error 
message generated at any point.

In my haste to slap together a test, I made a mistake somewhere in my math 
and the springs don't always line up where the spheres are. I didn't notice 
it until I was playing back the final animation, and it got late enough last 
night that I didn't go back and fix it. The important part was to test the 
macro, and it came through with flying colors.

I put a copy of the rendering up at YouTube, here: 
http://www.youtube.com/watch?v=LzgV8dALdIo.

--
Jack

Post a reply to this message

Attachments:
Download 'TargetTest.pov.txt' (11 KB)

On 11/18/2009 10:51 AM, Captain Jack wrote:
> I put a copy of the rendering up at YouTube, here:
> http://www.youtube.com/watch?v=LzgV8dALdIo.

Cool. I've been using it to render illustrations in POV-Ray, and then 
create markers and text on top of it in GeoGebra.

Mike

Post a reply to this message

"SharkD" <mik### [at] gmailcom> wrote in message 
news:4b04ad2d$1@news.povray.org...
> On 11/18/2009 10:51 AM, Captain Jack wrote:
>> I put a copy of the rendering up at YouTube, here:
>> http://www.youtube.com/watch?v=LzgV8dALdIo.
>
> Cool. I've been using it to render illustrations in POV-Ray, and then 
> create markers and text on top of it in GeoGebra.
>
> Mike

And, just for the sake of completeness if anyone else is reading this, I 
fixed the spring macro, using a macro from transforms.inc:

#macro Spring(Base_Point, Top_Point, Spring_Radius, Turns, Wire_Radius, 
Length_Scale)
    #local Length = vlength(Top_Point - Base_Point);
    #local Points = 4*Turns + 3;
    #local Arm_Delta = (Length/Length_Scale) / (4*Turns);
    #local Arm_Offset = -Arm_Delta;
    #local Arm_Rotation = 0;
    sphere_sweep {
        b_spline
        Points
        #local Counter = 0;
        #while (Counter < Points)
            , vrotate(Spring_Radius*x, Arm_Rotation*y) + Arm_Offset*y, 
Wire_Radius
            #local Arm_Offset = Arm_Offset + Arm_Delta;
            #local Arm_Rotation = mod(Arm_Rotation + 90, 360);
            #local Counter = Counter + 1;
        #end
        scale Length_Scale*y + (x + z)
        Point_At_Trans(Top_Point - Base_Point)
        translate Base_Point
        bounded_by {
            cylinder {
                -Wire_Radius*y,
                (Length+Wire_Radius)*y,
                Spring_Radius+Wire_Radius
                Point_At_Trans(Top_Point - Base_Point)
                translate Base_Point
                }
            }
        }
#end

Post a reply to this message

I am getting error messages like this:

File: /home/ellef/lang/pov-ray/inc//myScreen.inc  Line: 111
File Context (5 lines):
  #local val_3 = vinv_transform(Loc, Camera_Transform_All);
  <
Parse Error: Expected 'object or directive', < found instead


What am I doing wrong?


I am trying to add labels and help lines to geometrical figures (See
povray.newusers thread "Labels on geometrical figures").  It would be nice to do
that too entirely inside Pov-ray.

Post a reply to this message

On 8/17/2010 11:13 AM, Ellef Fange Gjelstad wrote:
>
> I am getting error messages like this:
>
> File: /home/ellef/lang/pov-ray/inc//myScreen.inc  Line: 111
> File Context (5 lines):
>    #local val_3 = vinv_transform(Loc, Camera_Transform_All);
>    <
> Parse Error: Expected 'object or directive',<  found instead
>
>
> What am I doing wrong?
>
>
> I am trying to add labels and help lines to geometrical figures (See
> povray.newusers thread "Labels on geometrical figures").  It would be nice to do
> that too entirely inside Pov-ray.
>
>
>

Please post the entire scene.

-- 
http://isometricland.com

Post a reply to this message

After some struggle, I have made a minimal example which works.  Thanks to
Captain Jack for TargetTest.pov (and of course to SharkD, this is a really cool
feature).

Maybe some might be interested in the "minimal" example, so I post it here.

So now, it is just to connect this to SVG, imageMagick and make, and we have a
general tool :)

Post a reply to this message

Attachments:
Download 'screenminimal.pov.txt' (2 KB)

After some struggle, I have made a minimal example which works.  Thanks to
Captain Jack for TargetTest.pov (and of course to SharkD, this is a really cool
feature).

Maybe some might be interested in the "minimal" example, so I post it here.

So now, it is just to connect this to SVG, imageMagick and make, and we have a
general tool :)

Post a reply to this message

On 8/18/2010 10:09 AM, Ellef Fange Gjelstad wrote:
> After some struggle, I have made a minimal example which works.  Thanks to
> Captain Jack for TargetTest.pov (and of course to SharkD, this is a really cool
> feature).
>
> Maybe some might be interested in the "minimal" example, so I post it here.
>
> So now, it is just to connect this to SVG, imageMagick and make, and we have a
> general tool :)

It would be cool if there were a library of macros that created 
SVG-equivalent shapes in POV. Might be a nice little project for someone 
who has the time.


-- 
http://isometricland.com

Post a reply to this message

Here's an updated version. It uses a new macro, Set_Camera_Orthographic, to
toggle orthographic mode on/off. Otherwise, the script will not be compatible
with old scenes made prior to this script.


Mike

Post a reply to this message

Attachments:
Download 'screen_new.inc.txt' (8 KB)

Hi,

"posfan12" <nomail@nomail> wrote:
> Here's an updated version. It uses a new macro, Set_Camera_Orthographic, to
> toggle orthographic mode on/off. Otherwise, the script will not be compatible
> with old scenes made prior to this script.

Thanks for your great work.

However, when I tried this version, I saw that the render was not the same when
simply switching from the regular screen.inc to screen_new.inc.

Is that expected?

Thanks.

Yannick

Post a reply to this message

This is a really cool feature which I'd like to use for an animation. Somehow it
does not work for me: the camera "zooms in" much more than using the normal
orthographic camera. The object positioning of text does not work either, as
shown in the standard screen.inc example attached.

What am I doing wrong. Or did something change?

Post a reply to this message

Attachments:
Download 'screentest.png' (105 KB)

Preview of image 'screentest.png'

On 03/11/2017 22:35, cbpypov wrote:
> This is a really cool feature which I'd like to use for an animation. Somehow it
> does not work for me: the camera "zooms in" much more than using the normal
> orthographic camera. The object positioning of text does not work either, as
> shown in the standard screen.inc example attached.
> 
> What am I doing wrong. Or did something change?
> 

You are right. You can only use screen.inc with the perspective camera.


Fake it. Move the camera further away and reduce the angle.


-- 

Regards
     Stephen

Post a reply to this message

>
> You are right. You can only use screen.inc with the perspective camera.
>
>
> Fake it. Move the camera further away and reduce the angle.
>
>
> --
>
> Regards
>      Stephen


Wasn't it just the objective of SharkD's file to actually make screen.inc
compatible with the orthographic camera? I.e. the issue of this thread?? A few
posts before some people state that it behaves as expected, but I can't seem to
get it to work.

It would be nice to have this feature, because I already have all the camera
positions of my animations and simply wanted to add a subtitle and some displays
in front of the camera. Due to the scientific background of the animation I'd
really prefer to have the orthographic cam.

Stephen, I tried your suggestion (without thinking, though) and just multiplied
the camera location vector by 10, and divided the angle by 10. It did not work
:) Is there a known mathematical way to fake the ortho-cam with my working
camera settings (i.e. a simple transformation that I can apply in the end)?

Thank you!

Post a reply to this message

On 04/11/2017 19:19, cbpypov wrote:
>>
>> You are right. You can only use screen.inc with the perspective camera.
>>
>>
>> Fake it. Move the camera further away and reduce the angle.
>>
>>
>> --
>>
>> Regards
>>       Stephen
> 
> 
> Wasn't it just the objective of SharkD's file to actually make screen.inc
> compatible with the orthographic camera? I.e. the issue of this thread?? A few
> posts before some people state that it behaves as expected, but I can't seem to
> get it to work.
> 

Oops! I forgot the beginnings of this thread.
That's what he said in the first post. But the third one with an 
attachment still says:

> // You can only use screen.inc with the perspective camera. Screen.inc
> // will automatically create the camera definition for you when it is
> // included.




> It would be nice to have this feature, because I already have all the camera
> positions of my animations and simply wanted to add a subtitle and some displays
> in front of the camera. Due to the scientific background of the animation I'd
> really prefer to have the orthographic cam.
> 
> Stephen, I tried your suggestion (without thinking, though) and just multiplied
> the camera location vector by 10, and divided the angle by 10. It did not work
> :) Is there a known mathematical way to fake the ortho-cam with my working
> camera settings (i.e. a simple transformation that I can apply in the end)?
> 

There will be a tangent in there some way.

https://en.wikipedia.org/wiki/Angle_of_view#Derivation_of_the_angle-of-view_formula

All those hard quantum sums, eh? ;-)




> Thank you!
> 


-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

>
> Oops! I forgot the beginnings of this thread.
> That's what he said in the first post. But the third one with an
> attachment still says:
>
> > // You can only use screen.inc with the perspective camera. Screen.inc
> > // will automatically create the camera definition for you when it is
> > // included.
>

No need to remember it: it's there, online, you can read it again ;) But I think
you copied these lines from its screen.inc attachment. BUT, these lines are
there because SharkD copied them from the original screen.inc and frogot to
delete them :D Maybe it's me: but I am sure this thread would not be here if
SharkD did not have tried to get ortho-cam to work. Moreover, his
reimplementation of Set_Camera would not have a new `orth` parameter:

    #macro Set_Camera(Location, LookAt, Angle, Ortho)

Right?

So, ... we are a bit at cross-purposes, i think. I attached examples of a
minimal scene. minimal_perspective.pov uses the normal camera, and using
screen.inc (minimal_screen.pov) gives identical results. When setting the
ortho-cam in the traditional way, I get the expected result (minimal_ortho.pov).
However, when using SharkD's screen.inc and setting `ortho=on`), the result is
way different (minimal_ortho_screen.pov). I think this is not how it is supposed
to work, i.e. minimal_ortho.png and minimal_ortho_screen.png are supposed to be
identical, but they are not.

>
> There will be a tangent in there some way.
>
> https://en.wikipedia.org/wiki/Angle_of_view#Derivation_of_the_angle-of-view_formula
>
> All those hard quantum sums, eh? ;-)
>

I see, it should be simple ;) I tried it, see minimal_ortho_fake.pov. But it is
still wrong :/

Does anyone see a fix for SharkD's approach? Or do you see where my mistake in
the fake version is?

Thanks :)

Post a reply to this message

Attachments:
Download 'minipov.zip' (176 KB)

Reposting this so I can pick it up in thunderbird.

(It came through the first time blank.)


"cbpypov" <nomail@nomail> wrote:
> Stephen <mca### [at] aolcom> wrote:
>
> >
> > Oops! I forgot the beginnings of this thread.
> > That's what he said in the first post. But the third one with an
> > attachment still says:
> >
> > > // You can only use screen.inc with the perspective camera. Screen.inc
> > > // will automatically create the camera definition for you when it is
> > > // included.
> >
>
> No need to remember it: it's there, online, you can read it again ;) But I think
> you copied these lines from its screen.inc attachment. BUT, these lines are
> there because SharkD copied them from the original screen.inc and frogot to
> delete them :D Maybe it's me: but I am sure this thread would not be here if
> SharkD did not have tried to get ortho-cam to work. Moreover, his
> reimplementation of Set_Camera would not have a new `orth` parameter:
>
>     #macro Set_Camera(Location, LookAt, Angle, Ortho)
>
> Right?
>
> So, ... we are a bit at cross-purposes, i think. I attached examples of a
> minimal scene. minimal_perspective.pov uses the normal camera, and using
> screen.inc (minimal_screen.pov) gives identical results. When setting the
> ortho-cam in the traditional way, I get the expected result (minimal_ortho.pov).
> However, when using SharkD's screen.inc and setting `ortho=on`), the result is
> way different (minimal_ortho_screen.pov). I think this is not how it is supposed
> to work, i.e. minimal_ortho.png and minimal_ortho_screen.png are supposed to be
> identical, but they are not.
>
> >
> > There will be a tangent in there some way.
> >
> >
https://en.wikipedia.org/wiki/Angle_of_view#Derivation_of_the_angle-of-view_formula
> >
> > All those hard quantum sums, eh? ;-)
> >
>
> I see, it should be simple ;) I tried it, see minimal_ortho_fake.pov. But it is
> still wrong :/
>
> Does anyone see a fix for SharkD's approach? Or do you see where my mistake in
> the fake version is?
>
> Thanks :)

Post a reply to this message

On 05/11/2017 09:09, Stephen wrote:
> Reposting this so I can pick it up in thunderbird.
> 
> (It came through the first time blank.)
> 
> 
> "cbpypov" <nomail@nomail> wrote:
>> Stephen <mca### [at] aolcom> wrote:
>>
>>>
>>> Oops! I forgot the beginnings of this thread.
>>> That's what he said in the first post. But the third one with an
>>> attachment still says:
>>>
>>>> // You can only use screen.inc with the perspective camera. Screen.inc
>>>> // will automatically create the camera definition for you when it is
>>>> // included.
>>>
>>
>> No need to remember it: it's there, online, you can read it again ;) But I think
>> you copied these lines from its screen.inc attachment. BUT, these lines are
>> there because SharkD copied them from the original screen.inc and frogot to
>> delete them :D Maybe it's me: but I am sure this thread would not be here if
>> SharkD did not have tried to get ortho-cam to work. Moreover, his
>> reimplementation of Set_Camera would not have a new `orth` parameter:
>>
>>      #macro Set_Camera(Location, LookAt, Angle, Ortho)
>>
>> Right?
>>

Hands up for posting without validating. :-(


>> So, ... we are a bit at cross-purposes, i think. I attached examples of a
>> minimal scene. minimal_perspective.pov uses the normal camera, and using
>> screen.inc (minimal_screen.pov) gives identical results. When setting the
>> ortho-cam in the traditional way, I get the expected result (minimal_ortho.pov).
>> However, when using SharkD's screen.inc and setting `ortho=on`), the result is
>> way different (minimal_ortho_screen.pov). I think this is not how it is supposed
>> to work, i.e. minimal_ortho.png and minimal_ortho_screen.png are supposed to be
>> identical, but they are not.
>>

You are right. I imported a couple of the scenes into Bishop3D, to get a 
visual representation of the cameras.
Adjusting the Up and Right Vectors of the orthogonal camera until the 
"look at" areas coincided. The angle I read back was 66.67. Substituting 
that into  minimal_ortho_screen.pov it was out by a factor of 2. an 
angle of 66.67/2 gave me a very similar image to minimal_perspective.pov


I conclude that there is something not right with the way that 
screen_ortho.inc converts angle into the the other vectors.

Finding what is beyond me.I would be still at it when the cows came home.



>>>
>>> There will be a tangent in there some way.
>>>
>>>
https://en.wikipedia.org/wiki/Angle_of_view#Derivation_of_the_angle-of-view_formula
>>>
>>> All those hard quantum sums, eh? ;-)
>>>
>>
>> I see, it should be simple ;) I tried it, see minimal_ortho_fake.pov. But it is
>> still wrong :/
>>

I had a quick look at it and it is beyond me. I'm afraid.



-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
>
> Hands up for posting without validating. :-(
>

Sorry, I cannot really follow what you mean ... did I do something wrong? :(

>
> You are right. I imported a couple of the scenes into Bishop3D, to get a
> visual representation of the cameras.
> Adjusting the Up and Right Vectors of the orthogonal camera until the
> "look at" areas coincided. The angle I read back was 66.67. Substituting
> that into  minimal_ortho_screen.pov it was out by a factor of 2. an
> angle of 66.67/2 gave me a very similar image to minimal_perspective.pov
>
>
> I conclude that there is something not right with the way that
> screen_ortho.inc converts angle into the the other vectors.
>
> Finding what is beyond me.I would be still at it when the cows came home.
>

Glad we're talking about the same things now :) Cool that you can do such things
with Bishop3D! I may have a look at what it is capable of.

However, maybe it was not really beyond you. I just had a look at SharkD's code,
and (again without actually thinking very much) I just found two little bugs.
There was just a factor of 2 missing here and there :D It now works in gives
exactly the results without the screen.inc. Hope you like it :)

JUST A SHORT question beyond that... using the screen.inc camera setting method
it seems that I cannot rotate the camera anymore, but need to use the sky-vector
instead. How do I do this? :)

Thanks for your help.
Best,
Carlo

Post a reply to this message

Attachments:
Download 'screen_ortho.inc.txt' (8 KB)

"cbpypov" <nomail@nomail> wrote:
>
> JUST A SHORT question beyond that... using the screen.inc camera setting method
> it seems that I cannot rotate the camera anymore, but need to use the sky-vector
> instead. How do I do this? :)

Found it myself :) I have to use vaxis_rotate on the camera location instead of
the sky vector. In my case I have to rotate around the y axis by the desired
degrees.

So it seems that everything is working now for me...

Post a reply to this message

from SharkD originally...
> > Update:

> > ...Also includes a new macro called
> > "Get_Screen_XY" to return the 2D screen location of a set of 3D coordinates.

Captain Jack replied in 2009...
> Cool... I hadn't read through the Get_Screen_XY macro yet, but I did write a
> scene to test it, which I've attached. The macro worked exactly as expected,
> with no errors. The animation itself is of a group of three balls connected
> by springs that float around the screen. I had the program create a text
> file giving the screen coordinates for the center of one of the spheres in a
> format that can be read by Particle Illusion. I Rendered the scene in POV,
> then I imported the text file into PI, then composited the whole thing over
> a background picture, and everything lined up exactly right with no error
> message generated at any point.

That Particle Illusion animation looks VERY good (I haven't gotten around to
trying  out that particular Rune(?) code yet, though.) It makes me wonder if
SharkD's original Get_Screen_XY macro (or any of its subsequent updates or
fixes) can successfully track an object with the camera actually moving around--
or maybe with just pan and tilt. (The animation example is with a fixed camera;
and SharkD didn't specifically mention camera motion.)  I haven't yet tried out
the macro or looked at his various code updates-- which apparently still have
some problems, it seems-- but *if* it could, it would make a really nice
camera-tracking package. Well, at least for tracking an animated moving-camera
POV-Ray rendered scene.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> That Particle Illusion animation looks VERY good (I haven't gotten around to
> trying  out that particular Rune(?) code yet, though.) It makes me wonder if
> SharkD's original Get_Screen_XY macro (or any of its subsequent updates or
> fixes) can successfully track an object with the camera actually moving around--
> or maybe with just pan and tilt. (The animation example is with a fixed camera;
> and SharkD didn't specifically mention camera motion.)  I haven't yet tried out
> the macro or looked at his various code updates-- which apparently still have
> some problems, it seems-- but *if* it could, it would make a really nice
> camera-tracking package. Well, at least for tracking an animated moving-camera
> POV-Ray rendered scene.
>

Hey Kenneth! Somehow I do not exactly know what you are talking about :) With my
small fixes SharkD's code works perfectly for me and it does just fine in
keeping e.g. text fixed in front of the camera while moving it. But somehow, I
do not see your point: (1) in a single POV-Ray render the camera is always
static, right? (2) SharkD's code doesn't make _any_ assumption about the camera
position, so how should it *know* where the camera is? Since it is agnostic, it
_must_ work in an animation, too ... did I miss something?

Post a reply to this message

On 05/11/2017 18:07, cbpypov wrote:
> Stephen <mca### [at] aolcom> wrote:
>>
>> Hands up for posting without validating. :-(
>>
> 
> Sorry, I cannot really follow what you mean ... did I do something wrong? :(
> 

What I meant was that I posted without checking that it was correct.

>>
>> You are right. I imported a couple of the scenes into Bishop3D, to get a
>> visual representation of the cameras.
>> Adjusting the Up and Right Vectors of the orthogonal camera until the
>> "look at" areas coincided. The angle I read back was 66.67. Substituting
>> that into  minimal_ortho_screen.pov it was out by a factor of 2. an
>> angle of 66.67/2 gave me a very similar image to minimal_perspective.pov
>>
>>
>> I conclude that there is something not right with the way that
>> screen_ortho.inc converts angle into the the other vectors.
>>
>> Finding what is beyond me.I would be still at it when the cows came home.
>>
> 
> Glad we're talking about the same things now :) Cool that you can do such things
> with Bishop3D! I may have a look at what it is capable of.
> 

It is free and a bit limited. But it has its usages. I am sure Blender 
would be just as useful.

> However, maybe it was not really beyond you. 

I would have to walk back almost 50 years to my last trig class.




-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
>
> I would have to walk back almost 50 years to my last trig class.
>

I see :) But in the end it wasn't as hard as expected...

Here are some more fixes (attached). The scaling of Screen_Object was broken for
ortho-cam.

Best,
Carlo

Post a reply to this message

Attachments:
Download 'screen_ortho.inc.txt' (8 KB)

On 5-11-2017 22:32, cbpypov wrote:
> Stephen <mca### [at] aolcom> wrote:
>>
>> I would have to walk back almost 50 years to my last trig class.
>>
> 
> I see :) But in the end it wasn't as hard as expected...
> 
> Here are some more fixes (attached). The scaling of Screen_Object was broken for
> ortho-cam.
> 
> Best,
> Carlo
> 

Good work!

For completeness sake I would suggest to add a comment line at the top, 
stating the different changes to the original screen.inc made by SharkD 
(with the tinkerer's name, date, and where to find eventual discussions 
of the issues, where possible) and those made by yourself. Future 
generations will thank you for that :-)

-- 
Thomas

Post a reply to this message

On 06/11/2017 08:03, Thomas de Groot wrote:
> On 5-11-2017 22:32, cbpypov wrote:
>> Stephen <mca### [at] aolcom> wrote:
>>>
>>> I would have to walk back almost 50 years to my last trig class.
>>>
>>
>> I see :) But in the end it wasn't as hard as expected...
>>
>> Here are some more fixes (attached). The scaling of Screen_Object was 
>> broken for
>> ortho-cam.
>>
>> Best,
>> Carlo
>>
> 
> Good work!
> 

Yes good work.


> For completeness sake I would suggest to add a comment line at the top, 
> stating the different changes to the original screen.inc made by SharkD 
> (with the tinkerer's name, date, and where to find eventual discussions 
> of the issues, where possible) and those made by yourself. Future 
> generations will thank you for that :-)
> 

And to add to what Thomas said. It might be a good idea to put it in its 
own thread. So it doesn't get lost in the depths of this one.


-- 

Regards
     Stephen

Post a reply to this message

"cbpypov" <nomail@nomail> wrote:

>
> Hey Kenneth! Somehow I do not exactly know what you are talking about :) With my
> small fixes SharkD's code works perfectly for me and it does just fine in
> keeping e.g. text fixed in front of the camera while moving it. But somehow, I
> do not see your point: (1) in a single POV-Ray render the camera is always
> static, right? (2) SharkD's code doesn't make _any_ assumption about the camera
> position, so how should it *know* where the camera is? Since it is agnostic, it
> _must_ work in an animation, too ... did I miss something?

Hmm; I think I'm beginning to see your point (and correct me if I'm wrong): An
animation with a moving camera is still just a series of discrete static images
strung together, each with its own 'static' camera position for that frame-- and
the code does work successfully on individual images with a 'static' camera
(which is the *only* camera position being rendered at the moment.) So the code
apparently doesn't need to know or even care about where the *camera* will be
for the next frame.

I need to take a closer look at your code and try it out; I didn't realize that
it's camera-agnostic.

Thanks for nudging me to think more clearly about this ;-)

Post a reply to this message

On 06/11/2017 11:34, Kenneth wrote:
> "cbpypov" <nomail@nomail> wrote:
> 
>>
>> Hey Kenneth! Somehow I do not exactly know what you are talking about :) With my
>> small fixes SharkD's code works perfectly for me and it does just fine in
>> keeping e.g. text fixed in front of the camera while moving it. But somehow, I
>> do not see your point: (1) in a single POV-Ray render the camera is always
>> static, right? (2) SharkD's code doesn't make _any_ assumption about the camera
>> position, so how should it *know* where the camera is? Since it is agnostic, it
>> _must_ work in an animation, too ... did I miss something?
> 
> Hmm; I think I'm beginning to see your point (and correct me if I'm wrong): An
> animation with a moving camera is still just a series of discrete static images
> strung together, each with its own 'static' camera position for that frame-- and
> the code does work successfully on individual images with a 'static' camera
> (which is the *only* camera position being rendered at the moment.) So the code
> apparently doesn't need to know or even care about where the *camera* will be
> for the next frame.
> 

Going from memory. You are right. The parameters for the macro are 
calculated each frame.

StephenS devised a method to return them in Bishop3D. So they could be 
used in additional code.


-- 

Regards
     Stephen

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> For completeness sake I would suggest to add a comment line at the top,
> stating the different changes to the original screen.inc ....

And while you're at it, maybe make a note of a version number, and save the file
with that version number as a suffix or part of the filename after and
underscore or something - so that upon downloading into a directory, it's easily
distinguishable from the other 9 "screen.inc" files I have saved over the years.
Optionally, or in addition to that, include the date of the revision first, in
European format - so that it's easily sorted and the latest revision "rises to
the top".

:)

Post a reply to this message

"cbpypov" <nomail@nomail> wrote:

> Here are some more fixes (attached). The scaling of Screen_Object was broken for
> ortho-cam.

Carlo,

Thanks very much for looking through the screen.inc code and finding those
problems and fixing them.

I think I had noticed some anomalies when I was working out the visible camera
view frustum

http://news.povray.org/povray.binaries.images/thread/%3Cweb.587ce3fc782d1af2c437ac910%40news.povray.org%3E/?mtop=415328


but I never got around to pursuing and identifying any bugs that might have been
in there.

We're always very appreciative of anyone who can make improvements and fixes to
the collection of tools that we have   :)

I hope the first few frames of your animation are coming out well, and the final
result makes a big impression!

Post a reply to this message

Am 06.11.2017 um 15:35 schrieb Bald Eagle:

> Optionally, or in addition to that, include the date of the revision first, in
> European format - so that it's easily sorted and the latest revision "rises to
> the top".

Most European countries traditionally use DMY ordering for dates, which
isn't any better for sorting than US format; the European format is just
more self-consistent.

When dates are to be sorted alphabetically, ISO format works best (YMD;
more precisely, YYYY-MM-DD).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Most European countries traditionally use DMY ordering for dates, which
> isn't any better for sorting than US format; the European format is just
> more self-consistent.
>
> When dates are to be sorted alphabetically, ISO format works best (YMD;
> more precisely, YYYY-MM-DD).

Ah.  I mistakenly thought "European format" was the ISO format.

YYYY-MM-DD_(2.0.0)_Screen.inc

might be a good format,

or maybe, since one is likely to search for screen*.inc, then perhaps

Screen_YYYY-MM-DD_(2.0.0)_.inc

Post a reply to this message

To all,

oh, I am so sorry I did not see all your replies ... I posted the file at


http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.5a00344aecd2fa6f80db62550%40news.povray.org%3E/

and thought you might respond there. Now when I saw there is still no post of
anyone, I came back here and couldn't believe my eyes :D

So, to catch up a bit, thanks for all those nice words! It's a pleasure to help
with this minimum contribution, ... especially after I received so much of your
help. Since I will use this code now for a larger scene I'll see if I notice any
further bugs. Til now it is working out well.

I'm sorry that I, for the above reasons, missed some of your ideas of how to
format the file/filename. May I post it again with these corrections?

I'll post the final animation when it's done. But it may take time because I'll
do this after I handed in my dissertation (at 2017-11-30 [ISO-format :D]).

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Hmm; I think I'm beginning to see your point (and correct me if I'm wrong): An
> animation with a moving camera is still just a series of discrete static images
> strung together, each with its own 'static' camera position for that frame-- and
> the code does work successfully on individual images with a 'static' camera
> (which is the *only* camera position being rendered at the moment.) So the code
> apparently doesn't need to know or even care about where the *camera* will be
> for the next frame.
>
> I need to take a closer look at your code and try it out; I didn't realize that
> it's camera-agnostic.
>
> Thanks for nudging me to think more clearly about this ;-)

Hey Kenneth,

I did not expect to receive this from you and especially not to make you really
think on this :D ... I hope this does not sound arrogant in any way (sometimes
its difficult to weigh such fragile phrases in a language which is foreign to
me; but at least it is not meant to sound arrogant in any way :) ) ... but it is
maybe because I am a physicist that this seems somehow natural to me. [<- this
sentence is far to long]. However, the way in which you reformulated what I said
appears just correct to me. I did not see anything in POV-Ray that could
distinguish between a `static` and an `animated` render. So POV-Ray itself is
agnostic for that in the first place. It follows that SharkD's code could only
deviate from this fact if it made any "assumption" on a -- say -- default camera
position. Which it does not :) --- q.e.d. :D

Best,
Carlo

Post a reply to this message

hi,

On 06/11/2017 17:42, Bald Eagle wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> When dates are to be sorted alphabetically, ISO format works best (YMD;
>> more precisely, YYYY-MM-DD).
> Ah.  I mistakenly thought "European format" was the ISO format.
> YYYY-MM-DD_(2.0.0)_Screen.inc
> might be a good format,> or maybe, since one is likely to search for screen*.inc,
then perhaps
> Screen_YYYY-MM-DD_(2.0.0)_.inc

if the file is to be useful on platforms other than Windows, a file name
without parentheses would be better, and the version number would
presumably be specific to a given release date, so

  screen-2.0.0.inc

would suffice, or, with a date instead

  screen-20171106.inc


regards, jr.

Post a reply to this message

jr <cre### [at] gmailcom> wrote:

> if the file is to be useful on platforms other than Windows, a file name
> without parentheses would be better, and the version number would
> presumably be specific to a given release date, so
.....


True, I know the version AND date are redundant - I was just thinking about
looking through a directory, and having the date "float" the filename to the
top.   But I suppose if they're sorted by date anyway...

I was just ruminating, and figured people would format their revisions however
they wanted anyway.   The key point was to vary the filename so all the
different revisions were differentiable.

Post a reply to this message

"cbpypov" <nomail@nomail> wrote:

> ... I hope this does not sound arrogant in any way (sometimes
> its difficult to weigh such fragile phrases in a language which is foreign to
> me; but at least it is not meant to sound arrogant in any way :) ) ... but it is
> maybe because I am a physicist that this seems somehow natural to me.

No need to worry; your command of English is quite good!

'Camera tracking' is very interesting to me; years ago, I modified Rune's
'Illusion Inc' POV-Ray include file in order to match POV-Ray animation to video
(from my Sony camera). Unfortunately, the resulting animations (and the scene
files) are on a hard disk that failed-- which I hope to 'resurrect' at some
point.

Last night, I came across an interesting BBC news item, about Microsoft's
experiments with real-time camera-tracking and 'augmented reality.' It's really
fascinating...

http://www.bbc.com/news/av/technology-41747005/inside-microsoft-s-new-mixed-reality-capture-studio

Post a reply to this message

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

>
> 'Camera tracking' is very interesting to me; years ago, I modified Rune's
> 'Illusion Inc' POV-Ray include file in order to match POV-Ray animation to video
> (from my Sony camera). Unfortunately, the resulting animations (and the scene
> files) are on a hard disk that failed-- which I hope to 'resurrect' at some
> point.
>

I just remembered that I posted one of the animations to the newsgroups, years
ago. (It was an old-style .AVI file, compressed using the 'Xvid'
codec/compressor, so I don't know if will play on all machines.) Here's the
link...

http://news.povray.org/povray.binaries.animations/thread/%3Cweb.52fd51fbee845476c2d977c20%40news.povray.org%3E/?ttop=41
5656&toff=50

Post a reply to this message

hi,

On 06/11/2017 21:10, Bald Eagle wrote:
> True, I know the version AND date are redundant - I was just thinking about
> looking through a directory, and having the date "float" the filename to the
> top.   ...

not sure about Windows but if you want to have the most recent files
shown first, using the 'ls' command you'd need to use an option switch
to make it sort in reverse order.

regards, jr.

Post a reply to this message

Am 07.11.2017 um 09:05 schrieb jr:
> hi,
> 
> On 06/11/2017 21:10, Bald Eagle wrote:
>> True, I know the version AND date are redundant - I was just thinking about
>> looking through a directory, and having the date "float" the filename to the
>> top.   ...
> 
> not sure about Windows but if you want to have the most recent files
> shown first, using the 'ls' command you'd need to use an option switch
> to make it sort in reverse order.

Nice idea, but there's a catch: All it can sort by is file creation or
last modification time. Which may happen to be the same as the time the
file was originally conceived by the author, but it may just as well be
something entirely different, depending on the toolchain that eventually
placed it on your file system.

Also, no operating system (well, none commonly used anyway) or file
management tool can sort by file name first /and/ timestamp second.
Because you can't have multiple files with the same name but different
timestamps.

Post a reply to this message

hi,

On 07/11/2017 10:26, clipka wrote:
> Am 07.11.2017 um 09:05 schrieb jr:
>> On 06/11/2017 21:10, Bald Eagle wrote:
>>> True, I know the version AND date are redundant - I was just thinking about
>>> looking through a directory, and having the date "float" the filename to the
>>> top.   ...
>> not sure about Windows but if you want to have the most recent files
>> shown first, using the 'ls' command you'd need to use an option switch
>> to make it sort in reverse order.
> Nice idea, but there's a catch: All it can sort by is file creation or
> last modification time. ...

and last access, ie 'ls -lt' or 'ls -ltc' vs 'ls -ltu'.

> ... Which may happen to be the same as the time the
> file was originally conceived by the author, but it may just as well be
> something entirely different, depending on the toolchain that eventually
> placed it on your file system.

very true.  the onus (on *NIX like machines) is on the user to be
specific in their requests.  the relevant commands (cp, scp, rsync) all
require an explicit '-a' (archive) or '-p' (preserve) option to keep
dates and permissions straight.  (not a problem though since the BASH
provides an "alias" command, so one can forget about "not forgetting" :-))

not sure about Windows (again), whenever I save a file from an
attachment in a newsgroup, say, the date/time stamp is of the local
creation.  how do you work around this?

> Also, no operating system (well, none commonly used anyway) or file
> management tool can sort by file name first /and/ timestamp second.
> Because you can't have multiple files with the same name but different
> timestamps.

also true, but not the point.  including an ISO date/time in the file
name to "float" it to the top requires reversing the sort order to get
descending dates (that's all I wrote).

regards, jr.

Post a reply to this message