|
 |
On 1/12/22 05:44, Mr wrote:
> "Kenneth" <kdw### [at] gmail com> 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
|
|
