In writing this post to the v4.0 forum:

http://news.povray.org/povray.pov4.discussion.general/thread/%3C67471126%241%40news.povray.org%3E/

I discovered weird differences in results between using the wood pattern 
directly within a normal and wrapping it in pigment_pattern{} or 
function{pattern{}}.

In other words, the following:

normal {
   wood
   rotate*90
}

Results in behavior different than either:

#declare Fn = function {
   pattern {
     wood
     rotate x*90
   }
}
...
normal { Fn(x,y,z) }

     or

normal {
   pigment_pattern {
     wood
     color_map {
       [0 rgb 0]
       [1 rgb 1]
     }
     rotate x*90
}

In the attached image the left column is using one of the wood {} 
wrapped forms. The middle column uses 'wood' directly in the normal{}.
The right column showing a 4x multiple of differences which should not 
exist. No AA used. The image results are from v3.8 beta 2, but this 
issue exists in the yuqk fork too.

The top row is just the wood base normal. The bottom row showing the 
wood based normal used in a slope map{}.

Real life keeping me busy over the next few days, but I plan to dig into 
this when I get some time. My guess at the moment is it is some 
numerical difference near values of 0 and/or 1, but we'll see.

Bill P.

Post a reply to this message

Attachments:
Download 'wrappedvsrawwoodinnormal.jpg' (145 KB)

Preview of image 'wrappedvsrawwoodinnormal.jpg'

On 11/27/24 08:00, William F Pokorny wrote:
> Real life keeping me busy over the next few days, but I plan to dig into 
> this when I get some time. My guess at the moment is it is some 
> numerical difference near values of 0 and/or 1, but we'll see.

What is going on popped into my head 10 minutes ago. The following does 
produce the same result as normal{ wood rotatex*90 } :

     #declare Fn = function {
         pattern {  // This {} enables value modifiers
             wood
           //rotate x*90
         }
     }
     normal {
         Fn(x,y,z)
         rotate x*90  // Moved the rotation here
     }

Where I had coded this:

     #declare Fn = function {
         pattern {  // This {} enables value modifiers
             wood
             rotate x*90
         }
     }
     normal {
         Fn(x,y,z)
     }

In the top the rotate happens in normal{} context. With the bottom 
encoding it happens in the pre-compiled function{ pattern{} } context.

The normal{} value sampling - in being only a pyramid  of 4 samples - is 
asymmetric. It sees the wood pattern's value not-rotated in one case and 
rotated in the other and we get different perturbed normal results.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/27/24 08:00, William F Pokorny wrote:
> > Real life keeping me busy over the next few days, but I plan to dig into
> > this when I get some time. My guess at the moment is it is some
> > numerical difference near values of 0 and/or 1, but we'll see.
>
> What is going on popped into my head 10 minutes ago. The following does
> produce the same result as normal{ wood rotatex*90 } :
>
>      #declare Fn = function {
>          pattern {  // This {} enables value modifiers
>              wood
>            //rotate x*90
>          }
>      }
>      normal {
>          Fn(x,y,z)
>          rotate x*90  // Moved the rotation here
>      }
>
> Where I had coded this:
>
>      #declare Fn = function {
>          pattern {  // This {} enables value modifiers
>              wood
>              rotate x*90
>          }
>      }
>      normal {
>          Fn(x,y,z)
>      }
>
> In the top the rotate happens in normal{} context. With the bottom
> encoding it happens in the pre-compiled function{ pattern{} } context.
>
> The normal{} value sampling - in being only a pyramid  of 4 samples - is
> asymmetric. It sees the wood pattern's value not-rotated in one case and
> rotated in the other and we get different perturbed normal results.
>
> Bill P.

So... Is there still no chance to create tangent space normal maps macros since
most recent fixes?

Post a reply to this message

On 11/29/24 06:20, Mr wrote:
> So... Is there still no chance to create tangent space normal maps macros since
> most recent fixes?

Probably not... :-)

I don't know is my actual answer. I have doubts I've changed mapping 
capability enough in yuqk to do much new over what POV-Ray can do.

When I have a little more time I'll have to search the web and the 
newsgroups for exactly what you mean by "tangent space normal maps macro".

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/29/24 06:20, Mr wrote:
> > So... Is there still no chance to create tangent space normal maps macros since
> > most recent fixes?
>
> Probably not... :-)
>
> I don't know is my actual answer. I have doubts I've changed mapping
> capability enough in yuqk to do much new over what POV-Ray can do.
>
> When I have a little more time I'll have to search the web and the
> newsgroups for exactly what you mean by "tangent space normal maps macro".
>
> Bill P.

This is the first result and does seem relevant:
https://learnopengl.com/Advanced-Lighting/Normal-Mapping

Crossfingers! Anyway, thanks a lot for ALL the work you are doing, very much
appreciated, please keep having fun !

Post a reply to this message

On 11/30/24 05:52, Mr wrote:
> This is the first result and does seem relevant:
> https://learnopengl.com/Advanced-Lighting/Normal-Mapping

Thank you for the reference!

Bill P.

Post a reply to this message