 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> wrote:
>
> Using your 'scale 2' camera, what it looks like is that the focal_blur's
> focal_point of <0,0,0> (the focal 'plane')is actually shifting to <0,0,-5>. In
> other words, it's keeping the same original 5-unit distance from the CAMERA--
> not scaling to 2*5 = 10-units. That's what I see from a simple test, anyway.
.... and changing the focal_point to <0,0,5> does indeed bring the focal plane
back to the original <0,0,0>.
Although, for a camera position that's not just <0,0,0> but something like
<3,13,-9>, it appears that the interplay between scaled camera and 'new' focal
plane gets much more complicated.
But I tried something weird, which seems to work(!) ...
The initial simple test:
original camera position: <0,0,-5>
original focal_point: <0,0,0>
With scale 2:
new camera position: <0,0,-10>
new focal_point set to: <0,0,5>
Now, with a more complicated camera position:
original camera position: <3,13,-9>
original focal point: <0,0,0>
With scale 2:
new camera position: <...? ...> (I'm too lazy to figure it out)
new focal_point set to: <-13,-3,9>
That appears to bring the original 'focal plane' of <0,0,0> back into sharp
focus! (Although, that plane is always perpendicular or orthogonal(?) to the
camera view.) The math for the new focal_point looks to be quite simple as well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/11/2018 11:11 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
>>
>> Using your 'scale 2' camera, what it looks like is that the focal_blur's
>> focal_point of <0,0,0> (the focal 'plane')is actually shifting to <0,0,-5>. In
>> other words, it's keeping the same original 5-unit distance from the CAMERA--
>> not scaling to 2*5 = 10-units. That's what I see from a simple test, anyway.
>
> .... and changing the focal_point to <0,0,5> does indeed bring the focal plane
> back to the original <0,0,0>.
>
> Although, for a camera position that's not just <0,0,0> but something like
> <3,13,-9>, it appears that the interplay between scaled camera and 'new' focal
> plane gets much more complicated.
>
> But I tried something weird, which seems to work(!) ...
>
> The initial simple test:
> original camera position: <0,0,-5>
> original focal_point: <0,0,0>
>
> With scale 2:
> new camera position: <0,0,-10>
> new focal_point set to: <0,0,5>
>
> Now, with a more complicated camera position:
> original camera position: <3,13,-9>
> original focal point: <0,0,0>
>
> With scale 2:
> new camera position: <...? ...> (I'm too lazy to figure it out)
> new focal_point set to: <-13,-3,9>
>
> That appears to bring the original 'focal plane' of <0,0,0> back into sharp
> focus! (Although, that plane is always perpendicular or orthogonal(?) to the
> camera view.) The math for the new focal_point looks to be quite simple as well.
>
>
>
>
>
>
Thanks! That means:
#local NewCameraFocalPoint = -1 * OldCameraLocation *
(NewCameraScale - 1);
But is this only true if the OldCameraFocalPoint is <0,0,0>? What
happens when the OldCameraFocalPoint is <5,20,-1>?
Would it be more intuitive if the focal point location automatically
scaled scaled with the camera position? E.g.
#local NewCameraFocalPoint = OldCameraFocalPoint * NewCameraScale;
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmailcom> wrote:
> Thanks! That means:
>
> #local NewCameraFocalPoint = -1 * OldCameraLocation *
> (NewCameraScale - 1);
>
> But is this only true if the OldCameraFocalPoint is <0,0,0>? What
> happens when the OldCameraFocalPoint is <5,20,-1>?
Off the top of my head, I would imagine that it's just a matter of adding or
subtracting the correct differences in values, kind of like my scale 2 example.
I haven't tested that idea though. (I'm also not totally sure if your equation
can work with an odd scaling factor of, say, 4.7 rather than 2 or 3 or 4. Maybe
it can!)
BTW: Having three active newsgroup threads, all generally about the same topic,
is kind of confusing; I'm not sure where to post follow-ups now. In future, it
would be best to have only one (or maybe an extra one for posting actual code,
if it happens to be quite long), and let the comments roll in. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think you need to look at it from the perspective of points, or vectors and
how they behave when scaled.
You have your camera position at a non-origin position, and then you scale it.
So it MOVES.
I'd say the same goes with the look_at point.
Try using a vector transform on a "point" and see if the scaling transform on
two vectors defined to be your camera position and look_at points give you
results that make sense.
#declare MyTransform = transform { scale { ... } }
#declare Foo2 = vtransform(Foo1,MyTransform);
from:
http://news.povray.org/povray.newusers/thread/%3Cweb.56d370be14d864ee5e7df57c0%40news.povray.org%3E/?ttop=418731&toff=5
0
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/12/2018 8:34 AM, Bald Eagle wrote:
> I think you need to look at it from the perspective of points, or vectors and
> how they behave when scaled.
>
> You have your camera position at a non-origin position, and then you scale it.
> So it MOVES.
> I'd say the same goes with the look_at point.
>
> Try using a vector transform on a "point" and see if the scaling transform on
> two vectors defined to be your camera position and look_at points give you
> results that make sense.
>
> #declare MyTransform = transform { scale { ... } }
> #declare Foo2 = vtransform(Foo1,MyTransform);
>
> from:
>
http://news.povray.org/povray.newusers/thread/%3Cweb.56d370be14d864ee5e7df57c0%40news.povray.org%3E/?ttop=418731&toff=5
> 0
>
>
Yes, look at the code I posted in p.t.s-f. That's why I posted it.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-02-10 à 19:47, Mike Horvath a écrit :
> What effect does scaling a camera have on focal_blur?
>
> I have two cameras, and they should both produce the same result. But
> they don't.
>
>
>
> // focal blur camera
> camera {
> location <0,0,-5>
> look_at <0,0,0>
> right x*image_width/image_height
> up y
> aperture 1.0 // [0...N] larger is narrower depth of field
> (blurrier)
> blur_samples 10 // number of rays per pixel for sampling
> focal_point <0,0,0> // point that is in focus <X,Y,Z>
> confidence 0.95 // [0...<1] when to move on while sampling
> (smaller is less accurate)
> variance 1/200 // [0...1] how precise to calculate (smaller
> is more accurate)
> scale 2
> }
>
> /*
> // focal blur camera
> camera {
> location <0,0,-10>
> look_at <0,0,0>
> right x*image_width/image_height
> up y
> aperture 1.0 // [0...N] larger is narrower depth of field
> (blurrier)
> blur_samples 10 // number of rays per pixel for sampling
> focal_point <0,0,0> // point that is in focus <X,Y,Z>
> confidence 0.95 // [0...<1] when to move on while sampling
> (smaller is less accurate)
> variance 1/200 // [0...1] how precise to calculate (smaller
> is more accurate)
> }
> */
The amount of focal blur depends on the ratio between (1) the distance
between the camera's location and the focal point location and (2) the
actual aperture.
So, with everything else been the same, the second camera have twice the
focal length for the same aperture, resulting in half the focal blur or
twice the sharpness depth.
To get the same results, you need to scale the aperture by the same
amount as the rest of the camera use for the second camera :
aperture 2.0
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-02-10 à 22:36, Mike Horvath a écrit :
> I've been reading this
>
> https://en.wikipedia.org/wiki/Miniature_faking
>
> and have been wondering how to achieve the effect in POV-Ray. Obviously,
> there is no true scale in POV-Ray, so there's no need to "fake" the
> effect. But I don't know how to construct the correct camera.
>
> Any ideas?
>
>
> Mike
Use a larger aperture. Something like
vlength(Camera_Location, Focal_point)/4
If that's not enough, use a smaller divisor.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/12/2018 2:00 PM, Alain wrote:
> Le 18-02-10 à 19:47, Mike Horvath a écrit :
>> What effect does scaling a camera have on focal_blur?
>>
>> I have two cameras, and they should both produce the same result. But
>> they don't.
>>
>>
>>
>> // focal blur camera
>> camera {
>> location <0,0,-5>
>> look_at <0,0,0>
>> right x*image_width/image_height
>> up y
>> aperture 1.0 // [0...N] larger is narrower depth of field
>> (blurrier)
>> blur_samples 10 // number of rays per pixel for sampling
>> focal_point <0,0,0> // point that is in focus <X,Y,Z>
>> confidence 0.95 // [0...<1] when to move on while sampling
>> (smaller is less accurate)
>> variance 1/200 // [0...1] how precise to calculate (smaller
>> is more accurate)
>> scale 2
>> }
>>
>> /*
>> // focal blur camera
>> camera {
>> location <0,0,-10>
>> look_at <0,0,0>
>> right x*image_width/image_height
>> up y
>> aperture 1.0 // [0...N] larger is narrower depth of field
>> (blurrier)
>> blur_samples 10 // number of rays per pixel for sampling
>> focal_point <0,0,0> // point that is in focus <X,Y,Z>
>> confidence 0.95 // [0...<1] when to move on while sampling
>> (smaller is less accurate)
>> variance 1/200 // [0...1] how precise to calculate (smaller
>> is more accurate)
>> }
>> */
>
> The amount of focal blur depends on the ratio between (1) the distance
> between the camera's location and the focal point location and (2) the
> actual aperture.
>
> So, with everything else been the same, the second camera have twice the
> focal length for the same aperture, resulting in half the focal blur or
> twice the sharpness depth.
>
> To get the same results, you need to scale the aperture by the same
> amount as the rest of the camera use for the second camera :
> aperture 2.0
>
>
> Alain
You're wrong, and Kenneth already figured out why up-thread.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/12/2018 2:02 PM, Alain wrote:
> Le 18-02-10 à 22:36, Mike Horvath a écrit :
>> I've been reading this
>>
>> https://en.wikipedia.org/wiki/Miniature_faking
>>
>> and have been wondering how to achieve the effect in POV-Ray.
>> Obviously, there is no true scale in POV-Ray, so there's no need to
>> "fake" the effect. But I don't know how to construct the correct camera.
>>
>> Any ideas?
>>
>>
>> Mike
>
> Use a larger aperture. Something like
> vlength(Camera_Location, Focal_point)/4
>
> If that's not enough, use a smaller divisor.
Yeah, I got it working. But it doesn't look as good in POV-Ray as it
does in photography. I'll post some test renders soon.
MIke
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/11/2018 06:56 PM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
>>
>> ..for a technique using a not yet adopted parser change which allowed
>> image_maps to be used directly in density {} blocks.
>>
> That is *definitely* an interesting and useful idea (as is your current
> workaround.) Any idea if this image_map thing is going to be included in a newer
> v3.8.x alpha or beta?
>
>
I've no idea. I've since closed the image_map specific pull request. As
a request it was submitted - as suggested - in place of another adding
image_maps and pigment_maps to density { }. I myself use the latter
branch with both enhancements and maintaining the image_map one was
always extra work for me as I 'git re-based' my branches over time.
In general, I've pruned back on the github pull requests I leave sitting
in the queue though I still publish any branches I think reasonably
solid that others building their own POV-Ray might find useful.
Having a lot of pull requests backed up on github itself becomes a
burden to the build test machines, it slows me down on re-basing and it
generates a lot of email noise especially for the most connected
developers.
Aside: I am sometimes frustrated by the pace at which changes are
adopted - while also understanding it. We must have knowledgeable gate
keepers and planners for the code base and they have only so much time.
Christoph, especially, has often enough saved me from my own ignorance
or improved upon an idea and my actual implementation. We need the pinch
point, the bottleneck for change - and to reasonably pace change given
many have development code efforts running alongside the master branch.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
