POV-Ray : Newsgroups : povray.binaries.images : adding a 'normal' to a camera-- some notes Server Time
28 Mar 2024 15:58:46 EDT (-0400)
  adding a 'normal' to a camera-- some notes (Message 11 to 12 of 12)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 11 Feb 2022 14:45:00
Message: <web.6206bb0dac36aa6b4cef624e6e066e29@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I'm not an official developer, but I did look some at the camera normal
> mechanism while implementing a 'micro' normal block pattern in my povr
> branch...
>
> [snip]
>
> I think the code is more or less working as intended - but it can
> certainly get complicated depending on what you want to do.
>

Sorry for the long delay, I needed to wrap my mind around your very useful
comments and to run some more tests.

This camera-normal stuff is indeed weird, and certainly not as simple to fix as
I thought. In my earlier 16:9 images using a gradient x+y normal, I did not
immediately grasp that the scale 'fix' only worked for the normal pattern
itself, not for its 'effect': the normal is correct at 45-deg, but the 'smeared
out' effect is still 'stretched' and not at 45-deg. And I  happened to have my
camera aimed exactly into +z -- which is another factor that affected the result
(the only partially 'correct' result, actually).

I've posted another series of tests here. In all cases, the 'fix' of
            scale <image_height/image_width, 1 1>
has been applied, and the camera is always looking directly into +z (unless
otherwise noted) at an ambient 1.0 sphere at location <0,0,0>. The sphere itself
is always centered in the renders. No light_sources. The radial and gradient x+y
patterns are simple 2-D, although they extend infinitely into z; the spherical
pattern is the only 3-D one I used.  With a *fully* 3-D pattern like bumps, the
visual result is just too difficult to figure out.

Some interesting observations:

In image A3 -- using the gradient x+y pattern and where the camera has been
rotated 75*y--there is a strange perspective effect of the normal! That's...odd,
because the sphere itself is still centered in the image. The other patterns
show this effect as well, more or less.  The camera's 'angle' setting seems to
be the cause; it exaggerates this perspective at higher values ('wide-angle').

In image C1 using a spherical pattern, I would have expected the effect's
'lobes' to all look equally extended and angled (perhaps at 45-deg multiples?).
But that's not the case. It seems that the pattern produces 'preferential' lobe
directions and lobe extent.

Purely from visual tests, I have come up with some ad hoc 'rules' to help when
applying a normal to a camera-- although I cannot say that these rules apply in
*all* cases:

1)  When using  the 'scale fix', the pattern itself always looks correct no
matter what the camera position or look_at point is. In other words, the pattern
is always centered and correctly 'stuck to the camera lens', and with its own
correct aspect ratio. *That's* good, at least. But this does not correct the
'effect' of the normal.

2) My guess at the moment is that the used normal pattern is taken from an
infinitely thin x/y 'slice', perhaps at the origin(?)-- based on an animation
test of the spherical pattern (using frequency 36) and translating it in z. The
resulting 'slice' moves in space as the pattern moves. BTW, I *think* this
pattern is centered on the camera by default.

3) Changing the camera's 'angle' value does not affect the size of the pattern
itself-- which is interesting!-- but instead changes the bump_size effect. In
other words, given an angle of 67 and bump_size of 0.5, when the angle is
reduced ('zooming in'), the given bump_size needs to be reduced as well, to
produce  what looks like the same effect or nearly so.  Unfortunately, the two
values do not have a strictly linear relationship.

4) The only way to get a truly undistorted/expected result from a camera normal
is to render a *square* 1:1 image, AND to aim the camera exactly into +z. It
does not matter where the camera is in space, just so it always points in +z.
Obviously, this is not an ideal situation when constructing a scene, or when you
want to use a different aspect ratio-- but the idea would be to simply crop the
square render later, to whatever aspect ratio you want.

BTW, I tried another test with the gradient x+y normal:
rotating the camera by 75*y, but also pre-rotating the normal itself by the same
amount to possibly 'align' both things, to see if that would correct everything.
Unfortunately, no; it screws-up the 45-angle of the normal, whether or not the
'scale fix' is used.


Post a reply to this message


Attachments:
Download 'camera_normal_problem_comp_2_kenw.png' (462 KB)

Preview of image 'camera_normal_problem_comp_2_kenw.png'
camera_normal_problem_comp_2_kenw.png


 

From: William F Pokorny
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 12 Feb 2022 02:23:49
Message: <62076085@news.povray.org>
On 2/11/22 14:42, Kenneth wrote:
> Sorry for the long delay, I needed to wrap my mind around your very useful
> comments and to run some more tests.
> 
> This camera-normal stuff is indeed weird, and certainly not as simple to fix as
> I thought.

No worries - this our hobby - we play when able. ...And, I cannot count 
the number of times I've mumbled to myself, "...not as simple to fix as 
I thought." :-)

Aside: I find your images here appealing.

---
I'll start by saying I'm sure I don't see or understand all that can 
happen when apply a normal block to the camera. That said, I think your 
general rules more or less correct.

(2) - Whether the pattern is centered or not will depend on the pattern. 
Internally the coordinates any pattern sees from the camera are 
-0.5,-0.5,0 to +0.5,+0.5,0.0.

(3) - Yes. The camera direction vector is effectively the raw normal 
into the normal pattern. (I've wondered whether there are any AA induced 
distortions when perturb camera rays with a normal{}. We, there, are 
twiddling with ray directions)

(4) - Yes. Similarly, beyond the simplest user defined functional camera 
set ups, figuring out how to set up a camera in a way which behaves in 
an understandable across all possible transformations is difficult.

Aside: Unsure I mentioned it. There is an odd check in the normal.cpp 
code whether a valid intersection exists. I initially took it to be an 
unneeded conditional and added an assert to see if it ever tripped while 
rendering. Camera normal{} and kaboom. Then had a reason for the 
conditional and also served notice the perturbed normal information is 
getting back to the camera direction rays by a somewhat different means 
than usual.

Bill P.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

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