I sometimes use a 'normal' block in a camera statement, for interesting and
un-planned effects.  While playing around with that, I noticed that my renders
looked... different... depending on the aspect-ratio that I chose -- like 4:3
vs. 16:9.  After eliminating other possibilities, it occurred to me that the
problem was due to the aspect ratio's scaling of the normal pattern.  The normal
itself has to  have a *reciprocal* scaling applied (in x) to account for the
aspect ratio-- even with a typical 4:3 render. Otherwise, the normal is
'distorted'.

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

Post a reply to this message

Attachments:
Download 'camera_normal_comp.jpg' (376 KB)

Preview of image 'camera_normal_comp.jpg'

Op 07/01/2022 om 03:49 schreef Kenneth:
[snip]
> 
> -----
> #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

That is interesting indeed. I guess you could use the camera 'right' for 
the normal, like:

scale <image_height/image_width,1,1>

Don't you think?

-- 
Thomas

Post a reply to this message

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

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'

"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

"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

"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

"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

"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

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