POV-Ray : Newsgroups : povray.binaries.images : Doctor John - FieldCam conundrum Server Time
29 Mar 2024 07:37:34 EDT (-0400)
  Doctor John - FieldCam conundrum (Message 11 to 20 of 29)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 9 Messages >>>
From: Bald Eagle
Subject: Re: Doctor John - FieldCam conundrum
Date: 17 Nov 2020 16:15:00
Message: <web.5fb43cc4ed460f771f9dae300@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> wrote:
> The macro works perfectly... as long as your scene camera is situated
> about the origin of the Y-axis.

For the moment, just disregard my other suggestions/guesses.

Just get rid of the VCorr term in the matrix.
I have no idea what that's for, but it seems to be the source of the problem.

Do a few fast, simple [but extreme] renders and see what you think.


Post a reply to this message

From: Cousin Ricky
Subject: Re: Doctor John - FieldCam conundrum
Date: 17 Nov 2020 16:40:27
Message: <5fb4434b$1@news.povray.org>
On 2020-11-16 6:12 PM (-4), Bald Eagle wrote:
> 
> 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/

Doctor John posted this version in 2009:

   https://news.povray.org/4aa8db4e$1@news.povray.org

As these camera shift macros and discussions have been sitting on my 
computer completely uncomprehended for years, I cannot say whether the 
"Corrected silly mathematical error in vertical scaling" addresses 
Thomas's concerns.


Post a reply to this message

From: Bald Eagle
Subject: Re: Doctor John - FieldCam conundrum
Date: 17 Nov 2020 19:25:01
Message: <web.5fb4697aed460f771f9dae300@news.povray.org>
Cousin Ricky <ric### [at] yahoocom> wrote:

> Doctor John posted this version in 2009:
>
>    https://news.povray.org/4aa8db4e$1@news.povray.org

Ah, excellent.   I needed different search terms.

> As these camera shift macros and discussions have been sitting on my
> computer completely uncomprehended for years, I cannot say whether the
> "Corrected silly mathematical error in vertical scaling" addresses
> Thomas's concerns.

Well me neither, but I figured it was a good place to start.  I've made some
sort of sense of all of the stuff Doctor John did, and so understand the WHY and
resulting output of what he does, and a little over half of the HOW.

The thing I do NOT understand is the purpose of the VCorr term or the meaning of
it's defining equation.

This is what I've got so far:

#local VCorr = pow(vlength(CamDirVec), 2) / pow(HypoXZ, 2);
  // HypoXZ / CamDirVec = adjacent / hypotenuse = cos (theta)
  // CamDirVec / HypoXZ = the inverse of the above, which is 1/cos (theta) = sec
(theta)
  // Squaring numerator and denominator is the same as squaring the fraction
  // so it looks like he's [erroneously?] calculating the secant squared of
theta

But maybe there's some trigonometric identity or other way of approaching the
meaning of the terms that sheds some light on what's going on....


Post a reply to this message

From: Thomas de Groot
Subject: Re: Doctor John - FieldCam conundrum
Date: 18 Nov 2020 02:56:33
Message: <5fb4d3b1@news.povray.org>
Op 17/11/2020 om 22:12 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> The macro works perfectly... as long as your scene camera is situated
>> about the origin of the Y-axis.
> 
> For the moment, just disregard my other suggestions/guesses.
> 
> Just get rid of the VCorr term in the matrix.
> I have no idea what that's for, but it seems to be the source of the problem.
> 
> Do a few fast, simple [but extreme] renders and see what you think.
> 
> 

#declare NoFall =
transform {
   matrix < 1,     0,      0,
           ShearX, 1, ShearZ,
            0,     0,      1,
            0,     0,      0>
}

Better (the camera stays at the correct altitude) but is still shifted 
increasingly in the view direction. At least, it shows that, as 
suspected, VCorr did not serve any purpose. Interestingly, in its first 
version, John did not have a VCorr at all!

Using a cube as a proxy camera, shifted an arbitrary value in front of 
the camera to make it visible, I can show what happens. The red, 
transparant, box is the proxy of the "real" camera; the yellow box is 
the proxy of the "real" camera, shifted along the line of view after the 
application of the NoFall transform. The distance between the cubes 
increases with the height of the camera for y>0.

 From this, it is easy to write a quick-and-dirty correction to be added 
/after/ the NoFall transform in the camera definition:

//start code
   FieldCam (CamLoc, CamLookAt)
   #local ProxyCam =
   box {
     <-1, -1, -1>, <1, 1, 1>
     translate CamLoc
     transform {NoFall}
   }
   #local MinBox = min_extent(ProxyCam);
   #local MaxBox = max_extent(ProxyCam);
   #local MidPoint = ((MaxBox-MinBox)/2) + MinBox;
   #local CamLoc_corr = CamLoc - MidPoint;

#declare Camera =
#if (FC)
camera {
   perspective
   location  CamLoc
   sky       CamSky
   up        CamSky
   direction z*CamZoom
   right     x*AspectRatio
   angle     CamAng
   transform {NoFall}
   translate CamLoc_corr
   look_at   CamLookAt
}
#else
camera {
   perspective
   location  CamLoc
   sky       CamSky
   up        CamSky
   direction z*CamZoom
   right     x*AspectRatio
   angle     CamAng
   look_at   CamLookAt
}
#end

camera {Camera}
//end code

But this is not as elegant as finding a way to do this already in the 
macro ;-)

-- 
Thomas


Post a reply to this message


Attachments:
Download 'dj_fieldcam_test.png' (255 KB)

Preview of image 'dj_fieldcam_test.png'
dj_fieldcam_test.png


 

From: Thomas de Groot
Subject: Re: Doctor John - FieldCam conundrum
Date: 18 Nov 2020 03:03:20
Message: <5fb4d548$1@news.povray.org>
Op 17/11/2020 om 11:29 schreef jr:
> 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.
> 

OK, thanks for this. I shall pospone a bit any further incursion into 
this domain as I do not want to clutter up my system with things I am 
pretty sure I shall only use once. ;-)

No problem. I try to avoid matrix stuff editing as much as possible, but 
now I have at least to get an understanding of it...

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: Doctor John - FieldCam conundrum
Date: 18 Nov 2020 03:08:39
Message: <5fb4d687$1@news.povray.org>
Op 17/11/2020 om 22:40 schreef Cousin Ricky:
> On 2020-11-16 6:12 PM (-4), Bald Eagle wrote:
>>
>> 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/

>>
> 
> Doctor John posted this version in 2009:
> 

> 
> As these camera shift macros and discussions have been sitting on my 
> computer completely uncomprehended for years, I cannot say whether the 
> "Corrected silly mathematical error in vertical scaling" addresses 
> Thomas's concerns.

Hey! That is a version I did not know, apparently adapted also for use 
with Moray. Otherwise, the code is identical to version 2. Thanks for this!

-- 
Thomas


Post a reply to this message

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

Thomas de Groot <tho### [at] degrootorg> wrote:
> > > the language is 'Tcl', ...
>
> OK, thanks for this. I shall pospone a bit any further incursion into
> this domain as I do not want to clutter up my system with things I am
> pretty sure I shall only use once. ;-)

no sweat.  am pretty sure that you could set up a spreadsheet (Bald Eagle
probably got one already :-)), with little fuss.


regards, jr.


Post a reply to this message

From: Jörg "Yadgar" Bleimann
Subject: Re: Doctor John - FieldCam conundrum
Date: 18 Nov 2020 07:16:38
Message: <5fb510a6$1@news.povray.org>
Hi(gh)!

On 16.11.20 08:48, Thomas de Groot 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.

Hmmm, falling lines would be also an issue when in February another 
another architectural photography season for my OpenCologne POV-Ray 
project starts... in my part of the world, February to (early) April is 
the best time in year for taking pictures of urban architecture, as 
trees are still bare (and thus do not obscure the facades much), but on 
the other hand, daylight lasts already long enough for extensive photo 
sessions (as long as storms would not prevent them)! And, hopefully, 
Covid-19 is not so much a threat anymore...

My digital cameras (even the relatively sophisticated Panasonic Lumix 
DMC-LZ100) are no able to correct for falling lines... but perhaps this 
macro can do that with the photos?

See you in Khyberspace!

Yadgar

Now playing: Der goldene Ball (Zara-Thustra) - German neo-Wagnerian 
symphonic pop!


Post a reply to this message

From: Bald Eagle
Subject: Re: Doctor John - FieldCam conundrum
Date: 18 Nov 2020 07:30:00
Message: <web.5fb51332ed460f771f9dae300@news.povray.org>
I'll try to look at this at some point to quantify the shift - it dependent upon
the cam loc, the look_at point, or both?

My thought is that the transform is a _scaling_ and so as we know, that can
shift things that are not AT the origin...

What happens if you shift the camera to the origin, apply the transform, and
then shift it back?


Post a reply to this message

From: Bald Eagle
Subject: Re: Doctor John - FieldCam conundrum
Date: 18 Nov 2020 17:20:00
Message: <web.5fb59db0ed460f771f9dae300@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

> What happens if you shift the camera to the origin, apply the transform, and
> then shift it back?

Well, it definitely has an effect.

First I tried location <0, 0, 0> applying the transform, and then translate
CamLoc, but I just got a blue render (sky)

Then I did

#if (FC)
 camera {
  //FieldCam (CamLoc, CamLookAt)
  FieldCam2 (CamLoc, CamLookAt)
  perspective
  location  CamLoc
  sky       CamSky
  up        CamSky
  direction z*CamZoom
  right     x*AspectRatio
  angle     CamAng
  translate -CamLoc
  transform {NoFall}
  translate CamLoc
  look_at   CamLookAt
 }

That lets me see the columns and seems to change the camera position as well.

replacing VCorr with 1 changes the camera position such that the columns are no
longer visible...


Juggling some things, so that's all I was able to play with for now.


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 9 Messages >>>

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