POV-Ray : Newsgroups : povray.binaries.images : adding a 'normal' to a camera-- some notes Server Time
29 Mar 2024 10:50:26 EDT (-0400)
  adding a 'normal' to a camera-- some notes (Message 3 to 12 of 12)  
<<< Previous 2 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 7 Jan 2022 13:05:00
Message: <web.61d87fb7ac36aa6b4cef624e6e066e29@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> wrote:
>
> That is interesting indeed. I guess you could use the camera 'right' for
> the normal, like:
>
> scale <image_height/image_width,1,1>
>

Yes indeed, that does work-- and it didn't occur to me, duh.

I originally tried a bunch of permutations of the 'right' vector itself-- among
other things-- because I could not easily figure out what the basis of the
distortion was (until I decided to use the gradient x+y idea as a tester.) Then
it became obvious.

I need to remember that image_height and image_width are actual *values* that
can be used in a scene. ;-)


Post a reply to this message

From: Kenneth
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 7 Jan 2022 14:20:00
Message: <web.61d8909fac36aa6b4cef624e6e066e29@news.povray.org>
I just tried an orthographic camera, and I get the same distortion results
(needing the same corrections as before.)

And just for fun, here's the same scene + orthographic camera, but using the
bumps pattern for the normal.

Sophisticated art! :-P

-----
BTW, has anyone heard of a relatively new way of selling art called NFT's
("non-fungible tokens")? It uses block-chain computer technology to 'sell' the
exclusive ownership of digital art, via Bitcoin or whatever. (Well, 'art' is not
the proper word... because most of the stuff looks like simplistic crap.)
Nevertheless, millionaires are being minted overnight from this phenomenon.

What a crazy world.


Post a reply to this message


Attachments:
Download 'camera_normal_using_bumps_jpeg.jpg' (174 KB)

Preview of image 'camera_normal_using_bumps_jpeg.jpg'
camera_normal_using_bumps_jpeg.jpg


 

From: Cousin Ricky
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 7 Jan 2022 16:20:00
Message: <web.61d8ae2aac36aa6b60e0cc3d949c357d@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> -----
> BTW, has anyone heard of a relatively new way of selling art called NFT's
> ("non-fungible tokens")? It uses block-chain computer technology to 'sell' the
> exclusive ownership of digital art, via Bitcoin or whatever. (Well, 'art' is not
> the proper word... because most of the stuff looks like simplistic crap.)
> Nevertheless, millionaires are being minted overnight from this phenomenon.
>
> What a crazy world.

Just a way to make money off other people who have more money than they know
what to do with (yet, still can't stand the thought of paying more taxes), and
think that throwing their money away will add some kind of meaning to their
futile, empty souls.

https://youtu.be/hoCPiXFIH1M

Pathetic.


Post a reply to this message

From: Kenneth
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 7 Jan 2022 18:30:00
Message: <web.61d8cbb8ac36aa6b4cef624e6e066e29@news.povray.org>
"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > What a crazy world.
>
> Just a way to make money off other people who have more money than they know
> what to do with (yet, still can't stand the thought of paying more taxes), and
> think that throwing their money away will add some kind of meaning to their
> futile, empty souls.
>
> https://youtu.be/hoCPiXFIH1M
>
> Pathetic.

Meanwhile, the world's power grid has to keep pumping out more and more
electrons just to satisfy the ravenous urge to make money from block-chain tech.
If I had *my* way, every Bitcoin miner et al would be required to build a
'green' power-generating station in his back yard.


Post a reply to this message

From: Mr
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 8 Jan 2022 07:30:00
Message: <web.61d982f9ac36aa6bb26de31b6830a892@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> The documentation at   '3.4.2.4 Camera Ray Perturbation'  does not mention this,
> nor does the example scene 'camera2' that is referenced there.  I had always
> thought that a  camera normal was independent of the actual IMAGE aspect ratio,
> or would automatically compensate for it; but not so. I tested only the
> perspective camera; I don't know what happens with the other types.
>
> An 'un-corrected' camera normal is meant only for a *square* 1:1 rendered image.
> That makes sense of course, because any normal or pattern is intrinsically 1:1:1
> in 3-D space. But when used in a CAMERA, a scaling has to be added to keep the
> normal's pattern correct re: a chosen aspect ratio.
>
> This 'extra' distortion is not obvious when using, for example, a bumps pattern
> for the normal. So I set up a  test scene with a strict 45-degree gradient x+y
> normal, where the resulting aspect-ratio distortion is obvious. (I added the
> white lines later, in an image-editing app.)
>
> -----
> #version 3.8;
> global_settings{assumed_gamma 1.0}
> #default{finish{ambient .4 emission 0 diffuse 0}}
>
> camera {
>   perspective
>   location  <0, 0, -20>
>   look_at   <0, 0,  0>
>   right     x*image_width/image_height
>   // direction z
>   // angle 67
>
>   normal{
>   gradient x+y // a 45-degree pattern
>   sine_wave
>   scale .1
>   bump_size .4
>   / /scale <3/4,1,1> // for 4/3 render
>   // OR...
>   // scale <9/16,1,1> // for 16/9 render
>   // -- etc. --
>   }
> }
>
> #declare S = seed(21);
> #for(i,1,100)
> sphere{0,1
>  pigment{rgb <.1 + .9*rand(S),.1 + .9*rand(S),.1 + .9*rand(S)>}
>  translate <-15 + 30*rand(S), -10 + 20*rand(S),0>
>  }
> #end


If this was to be added to that section of the docs (by some superior autority
than me), how would you rephrase all of this in the most concise simplified
caveat warning apposition to fit in ? maybe something like :

"All camera rays will be perturbed using this one unit sized pattern. "

?


Post a reply to this message

From: Kenneth
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 8 Jan 2022 15:15:00
Message: <web.61d9f068ac36aa6b4cef624e6e066e29@news.povray.org>
"Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> If this was to be added to that section of the docs (by some superior authority
> than me), how would you rephrase all of this in the most concise simplified
> caveat warning apposition to fit in ? maybe something like :
>
> "All camera rays will be perturbed using this one-unit sized pattern. "
>
> ?

Maybe something like this (or to add to your statement)?

"When used in a camera, the normal pattern will be distorted horizontally,
depending on your render's aspect ratio. To correct for this, an inverse-scaling
of the normal is required in x. For example:
scale <image_height/image_width, 1  1>"

[Thanks, Thomas]


Post a reply to this message

From: Mr
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 12 Jan 2022 05:45:00
Message: <web.61deb111ac36aa6b34c7846e6830a892@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> >
> > If this was to be added to that section of the docs (by some superior authority
> > than me), how would you rephrase all of this in the most concise simplified
> > caveat warning apposition to fit in ? maybe something like :
> >
> > "All camera rays will be perturbed using this one-unit sized pattern. "
> >
> > ?
>
> Maybe something like this (or to add to your statement)?
>
> "When used in a camera, the normal pattern will be distorted horizontally,
> depending on your render's aspect ratio. To correct for this, an inverse-scaling
> of the normal is required in x. For example:
> scale <image_height/image_width, 1  1>"
>
> [Thanks, Thomas]

Finally, before we consider documenting it like that, could maybe some developer
confirm that this is really the intended behaviour and not a bug ? Thanks.


Post a reply to this message

From: William F Pokorny
Subject: Re: adding a 'normal' to a camera-- some notes
Date: 23 Jan 2022 06:54:45
Message: <61ed4205$1@news.povray.org>
On 1/12/22 05:44, Mr wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> "Mr" <m******r******at_hotmail_dot_fr> wrote:
>>>
>>> If this was to be added to that section of the docs (by some superior authority
>>> than me), how would you rephrase all of this in the most concise simplified
>>> caveat warning apposition to fit in ? maybe something like :
>>>
>>> "All camera rays will be perturbed using this one-unit sized pattern."
>>>
>>> ?
>>
>> Maybe something like this (or to add to your statement)?
>>
>> "When used in a camera, the normal pattern will be distorted horizontally,
>> depending on your render's aspect ratio. To correct for this, an inverse-scaling
>> of the normal is required in x. For example:
>> scale <image_height/image_width, 1  1>"
>>
>> [Thanks, Thomas]
> 
> Finally, before we consider documenting it like that, could maybe some developer
> confirm that this is really the intended behaviour and not a bug ? Thanks.
> 

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.

With camera normal blocks, any other coordinate manipulation and too 
with user defined (function defined) cameras, the internal coordinates 
are all in 2d x,y unit blocks. Meaning the x and y coordinates run from 
-0.5 to 0.5 for both x and y not matter any camera or distortion 
particulars. Further, z is always 0.0.

Whether and how you might need to adjust an incoming normal pattern 
depends not only on the aspect size, but on the particular pattern.

For example, povr's new 'normal { micro 0.005 }' needs no adjustments 
because the x and y inputs are only used to create unique seeds which 
then create the 3d perturbation vectors.

If instead we were using one of the tiling patterns, and we wanted to 
align the 'repeating tile' we'd need to worry about not only potential 
scaling (perhaps of both the tiling pattern and for the camera aspect 
ratio), but we'd need to align the pattern - in a 0-1 unit square) with 
the camera's internal -+0.5 unit square.

What about patterns in x,z - well those would need to be rotated into 
the camera's x,y unit space for starters.

I think the code is more or less working as intended - but it can 
certainly get complicated depending on what you want to do.

Bill P.


Post a reply to this message

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 2 Messages Goto Initial 10 Messages

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