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