POV-Ray : Newsgroups : povray.binaries.images : Doctor John - FieldCam conundrum Server Time: 28 Nov 2020 13:59:24 GMT
  Doctor John - FieldCam conundrum (Message 1 to 10 of 29)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Thomas de Groot
Subject: Doctor John - FieldCam conundrum
Date: 16 Nov 2020 07:48:48
Message: <5fb22ee0@news.povray.org>
I need the help of a Matrix Master.

I am a regular user of Doctor John's FieldCam macro which enables 
slanting architecture to look straight. It simulates the professional 
cameras where this adjustment can be done through the lenses.

The macro works perfectly... as long as your scene camera is situated 
about the origin of the Y-axis. Recently, I have been working on scenes 
where the camera is situated at about y=170.00, and strange things 
happen: the camera is moved upwards and forwards, the more so as 
elevation gets greater.

To illustrate this, I have attached a little test scene and an image 
showing the problem. H is the value for the elevation of the scene 
elements along the Y-axis.

I can correct this by adding a translate after the "NoFall" transform in 
the camera code, but I assume that this could better be done within the 
"NoFall" matrix. I have not the slightest idea how to do this.

Thanks for any help.

-- 
Thomas


Post a reply to this message


Attachments:
Download 'dj_fieldcam_test.pov.txt' (7 KB)
Download 'dj_fieldcam_testx.jpg' (66 KB)

Preview of image 'dj_fieldcam_testx.jpg'
dj_fieldcam_testx.jpg


 

From: BayashiPascal
Subject: Re: Doctor John - FieldCam conundrum
Date: 16 Nov 2020 13:35:08
Message: <web.5fb27f25ed460f77108b22750@news.povray.org>
Hi Thomas,
I have never used Doctor John's macro but a quick look at it make me think it is
not supposed to work if the Y coordinates of you camera location and look_at do
not have the same value.

Changing your script as follow:

#case (2)
  #declare CamHeight    = 1;
  #declare CamLoc       = <2000.0, H+CamHeight, -2400.0>;
  #declare CamLookAt    = <2000-100, H+CamHeight, -2400+100>;
#end

and testing with the same H values as you example and FC on gives me correct
images (as far as I understand), cf attachment.
I also don't know if you really need to have a look_at at a different height...

I hope this will help you.



Thomas de Groot <tho### [at] degrootorg> wrote:
> I need the help of a Matrix Master.
>
> I am a regular user of Doctor John's FieldCam macro which enables
> slanting architecture to look straight. It simulates the professional
> cameras where this adjustment can be done through the lenses.
>
> The macro works perfectly... as long as your scene camera is situated
> about the origin of the Y-axis. Recently, I have been working on scenes
> where the camera is situated at about y=170.00, and strange things
> happen: the camera is moved upwards and forwards, the more so as
> elevation gets greater.
>
> To illustrate this, I have attached a little test scene and an image
> showing the problem. H is the value for the elevation of the scene
> elements along the Y-axis.
>
> I can correct this by adding a translate after the "NoFall" transform in
> the camera code, but I assume that this could better be done within the
> "NoFall" matrix. I have not the slightest idea how to do this.
>
> Thanks for any help.
>
> --
> Thomas


Post a reply to this message


Attachments:
Download 'test.png' (1255 KB)

Preview of image 'test.png'
test.png


 

From: BayashiPascal
Subject: Re: Doctor John - FieldCam conundrum
Date: 16 Nov 2020 13:50:07
Message: <web.5fb28346ed460f77108b22750@news.povray.org>
Sorry, after sending my previous message and looking at yours again I think I
have misunderstood what this macro does.
Sorry for the useless post...


Thomas de Groot <tho### [at] degrootorg> wrote:
> I need the help of a Matrix Master.
>
> I am a regular user of Doctor John's FieldCam macro which enables
> slanting architecture to look straight. It simulates the professional
> cameras where this adjustment can be done through the lenses.
>
> The macro works perfectly... as long as your scene camera is situated
> about the origin of the Y-axis. Recently, I have been working on scenes
> where the camera is situated at about y=170.00, and strange things
> happen: the camera is moved upwards and forwards, the more so as
> elevation gets greater.
>
> To illustrate this, I have attached a little test scene and an image
> showing the problem. H is the value for the elevation of the scene
> elements along the Y-axis.
>
> I can correct this by adding a translate after the "NoFall" transform in
> the camera code, but I assume that this could better be done within the
> "NoFall" matrix. I have not the slightest idea how to do this.
>
> Thanks for any help.
>
> --
> Thomas


Post a reply to this message

From: jr
Subject: Re: Doctor John - FieldCam conundrum
Date: 16 Nov 2020 15:05:01
Message: <web.5fb294b3ed460f77a8a81eb0@news.povray.org>
hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> I need the help of a Matrix Master.

that disqualifies me immediately.  :-)  however, I did write a simple calculator
UI to help me see how a change to the matrix affects a point.  maybe it and or
the thread will be of use.

<http://news.povray.org/povray.binaries.misc/thread/%3Cweb.5c226659252b677e48892b50%40news.povray.org%3E/>

one pitfall: the range of (matrix) values is limited to range -10.0 to 10.0.  if
you need larger values, edit the script in line 11.


regards, jr.


Post a reply to this message

From: Bald Eagle
Subject: Re: Doctor John - FieldCam conundrum
Date: 16 Nov 2020 22:15:01
Message: <web.5fb2f942ed460f771f9dae300@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> wrote:

> I am a regular user of Doctor John's FieldCam macro which enables
> slanting architecture to look straight. It simulates the professional
> cameras where this adjustment can be done through the lenses.

I think it's actually accomplished using the adjustable film plane of the view
camera.
The 3-book series on negative, print, and camera by Ansel Adams ought to
describe it fully and clearly.
<hint> One might think there are PDF's of those available...   ;) </hint>

> The macro works perfectly... as long as your scene camera is situated
> about the origin of the Y-axis. Recently, I have been working on scenes
> where the camera is situated at about y=170.00, and strange things
> happen: the camera is moved upwards and forwards, the more so as
> elevation gets greater.

Is this a custom version that you edited yourself, or a later version of the
original?
All I found was this:
http://news.povray.org/povray.text.scene-files/thread/%3Cweb.3e0c736a1f1273cdb29393de0%40news.povray.org%3E/

I'm puzzled by this:
#local VCorr = pow(vlength(CD), 2)/pow(HypoXZ, 2);
and its use in the matrix.  Seems to be some long-winded way to compute y^2 or a
multiple of it....

Maybe try
#local VCorr = CP.y;       ?    Totally guessing.

> To illustrate this, I have attached a little test scene and an image
> showing the problem. H is the value for the elevation of the scene
> elements along the Y-axis.

I don't really understand what I'm looking at in the scene, nor how the macro
corrects the one column and not the others...

> I can correct this by adding a translate after the "NoFall" transform in
> the camera code, but I assume that this could better be done within the
> "NoFall" matrix. I have not the slightest idea how to do this.

shear matrix:
http://www.f-lohmueller.de/pov_tut/trans/trans_450e.htm

The matrix just ... "corrects" the basis vectors of the world space that the
camera uses.

If you look at the thread that jr references:
http://news.povray.org/povray.binaries.misc/thread/%3Cweb.5c226659252b677e48892b50%40news.povray.org%3E/

we explain that the POV-Ray matrix keyword uses a proper 3x3 mathematical matrix
with an additional 1x3 translation matrix "bolted on"to the bottom.

So for
ABC
DEF
GHI

you have row-wise definitions of the basis vectors i, j, k (x, y, z) of the
world space.

So
ABC = <1, 0, 0> = x
DEF = <0, 1, 0> = y
GHI = <0, 0, 1> = z

and then you tack on a translate <x, y, z> to the bottom of that.

So, quick and dirty answer, to address moving your correctional translation to
the matrix would be (I think)

matrix <1, 0, 0, 0, 1, 0, 0, 0, 1, 0, -CP.y, 0>

Doctor John has some mathematical hocus pocus going in with his squared terms,
and what assumptions he makes and why is currently beyond my ken, but perhaps at
some point when I return to having the time and energy to muck around with
POV-Ray stuff, I will puzzle it out.

I'm not sure what the Vcorr does, but I guess it is doing it... wrong?

That's all I've got - for now.

-Bill


Post a reply to this message

From: Thomas de Groot
Subject: Re: Doctor John - FieldCam conundrum
Date: 17 Nov 2020 07:32:52
Message: <5fb37ca4@news.povray.org>
Op 16/11/2020 om 14:48 schreef BayashiPascal:
> Sorry, after sending my previous message and looking at yours again I think I
> have misunderstood what this macro does.
> Sorry for the useless post...
> 

LOL! No Problem; your attention to this is nonetheless appreciated.

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: Doctor John - FieldCam conundrum
Date: 17 Nov 2020 07:34:38
Message: <5fb37d0e@news.povray.org>
Op 16/11/2020 om 16:03 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I need the help of a Matrix Master.
> 
> that disqualifies me immediately.  :-)  however, I did write a simple calculator
> UI to help me see how a change to the matrix affects a point.  maybe it and or
> the thread will be of use.
> 
>
<http://news.povray.org/povray.binaries.misc/thread/%3Cweb.5c226659252b677e48892b50%40news.povray.org%3E/>
> 
> one pitfall: the range of (matrix) values is limited to range -10.0 to 10.0.  if
> you need larger values, edit the script in line 11.
> 

Frankly, I do not know what to do with this ;-}  A file with a .tk 
extension... what program runs this?

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: Doctor John - FieldCam conundrum
Date: 17 Nov 2020 08:03:18
Message: <5fb383c6@news.povray.org>
Op 16/11/2020 om 23:12 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> I am a regular user of Doctor John's FieldCam macro which enables
>> slanting architecture to look straight. It simulates the professional
>> cameras where this adjustment can be done through the lenses.
> 
> I think it's actually accomplished using the adjustable film plane of the view
> camera.
> The 3-book series on negative, print, and camera by Ansel Adams ought to
> describe it fully and clearly.
> <hint> One might think there are PDF's of those available...   ;) </hint>

In a dim, prehistoric past, I actually played a bit with a technical 
camera which could do this: it was a matter of sliding up and/or down 
the lens and/or the film plane indeed. Additionally, one could rotate 
those horizontally. Great toys for photographing (tall) architecture! 
But, back to topic.

> 
>> The macro works perfectly... as long as your scene camera is situated
>> about the origin of the Y-axis. Recently, I have been working on scenes
>> where the camera is situated at about y=170.00, and strange things
>> happen: the camera is moved upwards and forwards, the more so as
>> elevation gets greater.
> 
> Is this a custom version that you edited yourself, or a later version of the
> original?
> All I found was this:
>
http://news.povray.org/povray.text.scene-files/thread/%3Cweb.3e0c736a1f1273cdb29393de0%40news.povray.org%3E/

This is a custom version 2.0 (2005). I only added the #debug lines to 
understand what kind of info was generated.

> 
> I'm puzzled by this:
> #local VCorr = pow(vlength(CD), 2)/pow(HypoXZ, 2);
> and its use in the matrix.  Seems to be some long-winded way to compute y^2 or a
> multiple of it....
> 
> Maybe try
> #local VCorr = CP.y;       ?    Totally guessing.

I also was puzzled by VCorr, not understanding what it really does.
I shall try your guess later today.

> 
>> To illustrate this, I have attached a little test scene and an image
>> showing the problem. H is the value for the elevation of the scene
>> elements along the Y-axis.
> 
> I don't really understand what I'm looking at in the scene, nor how the macro
> corrects the one column and not the others...

 From left to right:
1 - a scene not using FC, camera pointing upwards, base level at y=0.0
2 - same scene using FC. The pillars are now straight as far as the 
observer is concerned. Base level still at y=0.0
3 - same scene, again using FC, but now with a base level of y=10.0
4 - idem, base level is y=20.0

Look again: all three pillars are corrected!

> 
>> I can correct this by adding a translate after the "NoFall" transform in
>> the camera code, but I assume that this could better be done within the
>> "NoFall" matrix. I have not the slightest idea how to do this.
> 
> shear matrix:
> http://www.f-lohmueller.de/pov_tut/trans/trans_450e.htm
> 
> The matrix just ... "corrects" the basis vectors of the world space that the
> camera uses.
> 
> If you look at the thread that jr references:
>
http://news.povray.org/povray.binaries.misc/thread/%3Cweb.5c226659252b677e48892b50%40news.povray.org%3E/
> 
> we explain that the POV-Ray matrix keyword uses a proper 3x3 mathematical matrix
> with an additional 1x3 translation matrix "bolted on"to the bottom.
> 
> So for
> ABC
> DEF
> GHI
> 
> you have row-wise definitions of the basis vectors i, j, k (x, y, z) of the
> world space.
> 
> So
> ABC = <1, 0, 0> = x
> DEF = <0, 1, 0> = y
> GHI = <0, 0, 1> = z
> 
> and then you tack on a translate <x, y, z> to the bottom of that.
> 
> So, quick and dirty answer, to address moving your correctional translation to
> the matrix would be (I think)
> 
> matrix <1, 0, 0, 0, 1, 0, 0, 0, 1, 0, -CP.y, 0>
> 
> Doctor John has some mathematical hocus pocus going in with his squared terms,
> and what assumptions he makes and why is currently beyond my ken, but perhaps at
> some point when I return to having the time and energy to muck around with
> POV-Ray stuff, I will puzzle it out.
> 
> I'm not sure what the Vcorr does, but I guess it is doing it... wrong?
> 
> That's all I've got - for now.
> 

Well, that is already a lot and thanks for that.  You gave me an idea 
for further testing, without understanding at all what I shall do, but 
at least it will give me some visual clues. Frankly, this is beyond my 
already feeble knowledge.

I shall be back later.

-- 
Thomas


Post a reply to this message

From: jr
Subject: Re: Doctor John - FieldCam conundrum
Date: 17 Nov 2020 08:40:00
Message: <web.5fb38b1ced460f77a8a81eb0@news.povray.org>
hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...
> Frankly, I do not know what to do with this ;-}  A file with a .tk
> extension... what program runs this?

the language is Tcl/Tk.  back when I used to use ActiveState's stuff on Windows,
from: <https://www.activestate.com/products/tcl/>

(then only one other thing needed - rename the script to a .tcl extension
because that's what MS Windows looks for)  hth.


regards, jr.


Post a reply to this message

From: jr
Subject: Re: Doctor John - FieldCam conundrum
Date: 17 Nov 2020 10:30:01
Message: <web.5fb3a61aed460f77a8a81eb0@news.povray.org>
just to correct some poor writing.


"jr" <cre### [at] gmailcom> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > ...
> > Frankly, I do not know what to do with this ;-}  A file with a .tk
> > extension... what program runs this?
>
> the language is Tcl/Tk.

the language is 'Tcl', short for tool command language.  'Tk' is short for
toolkit, essentially a bag of Tcl commands which provide the graphical (UI)
elements like buttons.

non-graphical stuff gets run/executed by 'tclsh' -- the Tcl shell, while UI
stuff gets executed by the 'wish' program -- the windowing shell.

> back when I used to use ActiveState's stuff on Windows,
> from: <https://www.activestate.com/products/tcl/>
>
> (then only one other thing needed - rename the script to a .tcl extension
> because that's what MS Windows looks for)  hth.

most people use '.tcl' as extension for both UI and terminal-only scripts (I
don't).  after a default installation, any 'something.tcl' can be double-clicked
to run (and you will probably never notice any difference to a compiled s/ware).


regards, jr.


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.