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