|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|