POV-Ray : Newsgroups : povray.general : image based normal maps? Server Time
28 Mar 2024 20:44:44 EDT (-0400)
  image based normal maps? (Message 11 to 20 of 30)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Thomas de Groot
Subject: Re: image based normal maps?
Date: 20 Jan 2019 07:07:13
Message: <5c446471$1@news.povray.org>
On 20-1-2019 9:33, ingo wrote:
> in news:5c442a26$1@news.povray.org Thomas de Groot wrote:
> 
>> However, Bald Eagle's
>>
>>       function {
>>         NormalMap(x,y,z).red +
>>         NormalMap(x,y,z).green +
>>         NormalMap(x,y,z).blue
>>       } 1.5
>>
>> gives a much better result and thus may be preferred.
>>
> 
> .gray and .hf = 0.3 * red + 0.59 * green + 0.11 * blue, so yes there's
> quite a difference to be expected.
> 
> ingo
> 

Ah! I didn't know that!

-- 
Thomas


Post a reply to this message

From: clipka
Subject: Re: image based normal maps?
Date: 20 Jan 2019 09:43:19
Message: <5c448907$1@news.povray.org>
Am 20.01.2019 um 13:07 schrieb Thomas de Groot:
> On 20-1-2019 9:33, ingo wrote:
>> in news:5c442a26$1@news.povray.org Thomas de Groot wrote:
>>
>>> However, Bald Eagle's
>>>
>>>       function {
>>>         NormalMap(x,y,z).red +
>>>         NormalMap(x,y,z).green +
>>>         NormalMap(x,y,z).blue
>>>       } 1.5
>>>
>>> gives a much better result and thus may be preferred.
>>>
>>
>> .gray and .hf = 0.3 * red + 0.59 * green + 0.11 * blue, so yes there's
>> quite a difference to be expected.

To be precise, it is 0.297, 0.589 and 0.114, respectively.


Post a reply to this message

From: Bald Eagle
Subject: Re: image based normal maps?
Date: 20 Jan 2019 11:40:06
Message: <web.5c44a37be20dd126765e06870@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> wrote:
> On 20-1-2019 9:33, ingo wrote:


> > .gray and .hf = 0.3 * red + 0.59 * green + 0.11 * blue, so yes there's
> > quite a difference to be expected.
> >
> > ingo
> >
>
> Ah! I didn't know that!
>
> --
> Thomas

I remember that from the LOOOOOOONG thread back at:

http://news.povray.org/povray.advanced-users/thread/%3Cweb.577e597b5ff2a8e65e7df57c0%40news.povray.org%3E/?mtop=409379

(See post by Mssr Grimbert at bottom of pg 1)


Post a reply to this message

From: Thomas de Groot
Subject: Re: image based normal maps?
Date: 21 Jan 2019 02:47:37
Message: <5c457919$1@news.povray.org>
On 20-1-2019 17:36, Bald Eagle wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> On 20-1-2019 9:33, ingo wrote:
> 
> 
>>> .gray and .hf = 0.3 * red + 0.59 * green + 0.11 * blue, so yes there's
>>> quite a difference to be expected.
>>>
>>> ingo
>>>
>>
>> Ah! I didn't know that!
>>
>> --
>> Thomas
> 
> I remember that from the LOOOOOOONG thread back at:
> 
>
http://news.povray.org/povray.advanced-users/thread/%3Cweb.577e597b5ff2a8e65e7df57c0%40news.povray.org%3E/?mtop=409379
> 
> (See post by Mssr Grimbert at bottom of pg 1)
> 
> 

Ah, yes. Like with the oren-nayar feature, I had that little bell 
ringing feebly at the back of my mind, but was unable to localise it, 
deeming it an early start of senility... :-)

note: I am not going to re-read that loooooooong thread...

-- 
Thomas


Post a reply to this message

From: ingo
Subject: Re: image based normal maps?
Date: 21 Jan 2019 05:05:13
Message: <XnsA9DE70C929BF2seed7@news.povray.org>
in news:5c457919$1@news.povray.org Thomas de Groot wrote:

> note: I am not going to re-read that loooooooong thread...
> 
> 

It's in the docs, but not where you expect it. 
http://wiki.povray.org/content/Reference:File_Output_Options

Should appear in a few more places imo, like:
http://wiki.povray.org/content/Reference:Color_Expressions#Dot_Item_Access
_for_Colors

And it appears that .hf = (Red + Green/255)*0.996093 not the same as .gray 
as I thought.

http://wiki.povray.org/content/Documentation:Tutorial_Section_3.2
#Noise_and_pigment_functions
The only appearence of .hf I could find,

ingo


Post a reply to this message

From: Thomas de Groot
Subject: Re: image based normal maps?
Date: 21 Jan 2019 07:00:58
Message: <5c45b47a$1@news.povray.org>
On 21-1-2019 11:05, ingo wrote:
> in news:5c457919$1@news.povray.org Thomas de Groot wrote:
> 
>> note: I am not going to re-read that loooooooong thread...
>>
>>
> 
> It's in the docs, but not where you expect it.
> http://wiki.povray.org/content/Reference:File_Output_Options
> 
Indeed; I did not look there at all.

> Should appear in a few more places imo, like:
> http://wiki.povray.org/content/Reference:Color_Expressions#Dot_Item_Access
> _for_Colors
> 
Probably, in explaining how .grey/.gray is calculated. That seems to be 
missing.

> And it appears that .hf = (Red + Green/255)*0.996093 not the same as .gray
> as I thought.
> 
> http://wiki.povray.org/content/Documentation:Tutorial_Section_3.2
> #Noise_and_pigment_functions
> The only appearence of .hf I could find,
> 
Where also the value of .grey/.gray is given.

.hf is typically used in height_field functions like, e.g.:
height_field {function HF_res, HF_res {F_HF_01(x,y,z).hf}}

Contrary to what is said in the docs, .hf does not generate a warning 
(any more).

-- 
Thomas


Post a reply to this message

From: Kenneth
Subject: Re: image based normal maps?
Date: 21 Jan 2019 07:10:00
Message: <web.5c45b59fe20dd126cd98345b0@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Glad to see ole' Kenneth Walker is keeping his Northern namesake on his toes
> with the speedy competition.   ;)

Hey, cousin!  :-P
>
> Try some of this out, and see what you think:
>
[snip]
>
> box {<0, 0, 0>, <1, 1, 0.1>
>   texture {pigment {Blue*0.5} finish {specular 0.4}}
>      //normal {function { BumpMap (x, y, z).gray}}
>      normal {
>       function {
>       BumpMap (x, y, z).red +
>       BumpMap (x, y, z).green +
>       BumpMap (x, y, z).blue}
>      }
> }

I've been working with your code for the last day-- it's a great way to split up
the color channels of the image function for use. Nice! I haven't yet figured
out how to use the individual channels to apply three separate normal patterns
though (in a normal_map)--- because I got sidetracked: There's something really
strange going on here (or at least unexpected)-- not with your code, but with
the basic act of transforming an image_map (OR one of POV-Ray's built-in
patterns) into a function.

I've included a test scene below, to show the interesting normals behavior; I
didn't use an image_map for the normal, but rather a bozo pattern (although the
same strange effect happens with a continuous-tone color photo and bump_map,
from testing.) Bozo by default uses the three primary colors, which I wanted.
The red arrows show the direction of the single light source, with the light
just raking the box surfaces.

When rendering the code, the box on the left shows a 'typical' applied normals
pattern (no function or bump_map.) The center box takes the bozo pattern and
turns it into a function (using .gray). The right-most box is the function
again, but uses your 'split color channels' idea (with just a single color
channel in use.)

Some observations:
There's a fundamental difference in appearance between box 1 and boxes 2 and 3.
The normals produced from the function are... layered(?), or *something*. It's
as if there are no 'blends' between the three color channels' normals-- unlike
the smooth blend in the left box. I don't know if this is expected behavior or
not.

But the strangest thing is that the *function's* normals react to the light
only in 90-degree quadrants. In other words, with the light at 45-degrees up and
to the right, the normals are a BLEND of two strict 90-degree effects
superimposed, one horizontal, the other vertical, with no 'blend' inbetween.
(This is more easily seen in an animation, with the light tracing an arc from
horizon to horizon.)

BTW, I discovered something interesting about your three added color channels
        BumpMap (x, y, z).red +
        BumpMap (x, y, z).green +
        BumpMap (x, y, z).blue}

By using the color-to-grayscale formula posted earlier-- the three RGB values,
as multipliers-- your construction can be turned back into the simpler .gray
appearance of the 'combined' color channels:

        BumpMap (x, y, z).red*0.297 +
        BumpMap (x, y, z).green*0.589 +
        BumpMap (x, y, z).blue}*0.114

Fun, eh?
Anyway, I'm still thinking about the function strangeness, so here's the code
test...
------------------------
// render as 16/9 ratio

#version 3.7; // or 3.71 or 3.8
global_settings{assumed_gamma 1.0}
#default{finish{ambient 0.1 emission 0 diffuse 0.7 specular 0.4}}

camera {
  perspective
  location  <0, .8, -20>
  look_at   <0, .5,  0>
  right     x*image_width/image_height
  angle 10
}

#declare LIGHT_POS = <100, 0, -15>;
#declare LIGHT_TRANSFORM = transform{rotate 45*z} // or for animation,
// rotate 180*clock*z, 200 frames

// a SINGLE light
light_source {
  0*x
  color rgb <1,1,1>
  translate LIGHT_POS
  transform{LIGHT_TRANSFORM}
}

#declare ARROW =
merge{
cylinder{.001*LIGHT_POS,0.0055*LIGHT_POS,0.006}
cone{0.0012*LIGHT_POS,0.025,<0,0,0>,0.0001}
    pigment{rgbt <10,0,0,0.85>}
    no_shadow
    }

//----------------
// box 1
// USING A BUILT-IN PATTERN AND NO BUMP_MAP.
box {<0, 0, 0>, <1, 1, 0.1>
  pigment {rgb 0.5}
  normal {bozo bump_size 20 scale 0.15}
  translate -1.6*x
}

object{ARROW
transform{LIGHT_TRANSFORM}
translate <-1.1,0.5,-0.1>
}

//----------------
// box 2
#declare NORM_FUNCTION = function{pigment{bozo scale .15}}
box {<0, 0, 0>, <1, 1, 0.1>
  pigment {rgb .5}
      normal {function {NORM_FUNCTION (x,y,z).gray} bump_size 1.0}
      translate -.5*x
}

object{ARROW
transform{LIGHT_TRANSFORM}
translate <1.1,.5,-.1>
}

//----------------
// box 3 -- (using the same BumpMap function as box 2)
box {<0, 0, 0>, <1, 1, 0.1>
  pigment {rgb .5}
      normal {
      function {
      // Use the respective multipliers for these three, instead of
      // 'full' intensity:
      /*
      NORM_FUNCTION (x, y, z).red*0.297 +
      NORM_FUNCTION (x, y, z).green*0.589 +
      NORM_FUNCTION (x, y, z).blue*0.114
      */

      // OR... used *separately* and at full intensity...
      NORM_FUNCTION (x, y, z).red
     // +
     // NORM_FUNCTION (x, y, z).green
     // +
     // NORM_FUNCTION (x, y, z).blue
               }
             }
     translate .6*x
}

object{ARROW
transform{LIGHT_TRANSFORM}
translate <0,.5,-.1>
}


Post a reply to this message

From: Bald Eagle
Subject: Re: image based normal maps?
Date: 21 Jan 2019 09:10:02
Message: <web.5c45d275e20dd126765e06870@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> Some observations:
> There's a fundamental difference in appearance between box 1 and boxes 2 and 3.
> The normals produced from the function are... layered(?), or *something*. It's
> as if there are no 'blends' between the three color channels' normals-- unlike
> the smooth blend in the left box. I don't know if this is expected behavior or
> not.


Well, this is usually the point where either clipka jumps in with an inside-out
explanation, since he has the big picture of the source code in his head and can
translate, summarize, and put it in proper order and context.

Or I go digging in the source and try to puzzle out the bits.

But my first instinct is that since there a different ways to create a normal
from an image, they are all implemented under the hood differently.
Sort of like the way you can have 2 different heighfields - one "sharp" and
abrupt - and the other smoothed.

I also don't know what would happen if the box were > 1x1, if there were some
sort of interpolation.  Or conversely if the image were scaled smaller and
applied to a 1x1 box.

If you want smoothing, then perhaps the simplest first experiment to try is:

"But how about if we want a smooth blend of patterns all the way through? That
is where a new feature called average can come in very handy. Average works with
pigment, normal, and texture maps, although the syntax is a little bit
different, and when we are not expecting it, the change can be confusing. Here
is a simple example. We use our standard includes, camera and light source from
above, and enter the following object.

  plane { -z, 0
    pigment { White }
    normal {
      average
      normal_map {
        [1, gradient x ]
        [1, gradient y ]
      }
    }
  }
"

You may have to write a function to use for the weights of the different
channels, but it's something to play with.


What I was thinking about initially was:

NORMAL:
  normal {
    IMAGE_PATTERN [Bump_Size]
    normal_map { NORMAL_MAP_BODY }
    }

{And here, 3.4.7.4.2 employs "irregardless".  :|   For shame. }


Post a reply to this message

From: clipka
Subject: Re: image based normal maps?
Date: 21 Jan 2019 10:33:06
Message: <5c45e632$1@news.povray.org>
Am 21.01.2019 um 13:05 schrieb Kenneth:

> There's a fundamental difference in appearance between box 1 and boxes 2 and 3.
> The normals produced from the function are... layered(?), or *something*. It's
> as if there are no 'blends' between the three color channels' normals-- unlike
> the smooth blend in the left box. I don't know if this is expected behavior or
> not.

The "plateau" effect is indeed to be expected: When using a pattern in a 
`normal` statement, the "raw" pattern is interpreted as a height value. 
When instead using a pattern in a pigment (as you do in NORM_FUNCTION), 
the pattern value is first translated into a colour value according to a 
colour map, and then the three channels of the colour value are 
translated (as per your function definition) into a scalar again, and 
then /that/ value is used as the height value.

Now if the pigment has no colour map associated, then "raw" pattern 
value is interpreted as a greyscale value, and the subsequent 
translation from colour to scalar simply un-does the operation. But some 
patterns - and `bozo` is one of them - have default colour maps associated.

In the case of `bozo` this colour map has some ranges of "raw" pattern 
values where the colour (and thus the height value computed from it) 
remains constant, which correspond to the "plateaus".


> But the strangest thing is that the *function's* normals react to the light
> only in 90-degree quadrants. In other words, with the light at 45-degrees up and
> to the right, the normals are a BLEND of two strict 90-degree effects
> superimposed, one horizontal, the other vertical, with no 'blend' inbetween.
> (This is more easily seen in an animation, with the light tracing an arc from
> horizon to horizon.)

This, too, can be explained:

When plugging in a pattern into a normal, the normal is computed by 
first sampling the pattern at four points in 3D space, from that 
computing the gradient of the pattern in 3D space, and from that 
computing how to perturb the normal. The four samples are always taken 
at fixed offsets relative to the intersection points, distributed in a 
tetrahedral arrangement.

If you have a pattern with plateaus, and the distance between those 
plateaus (the slope regions) are narrow compared to the dimensions of 
the sampling tetrahedron, the four sampling points will frequently all 
end up on one of the plateaus, and you'll end up with a very limited set 
of possible computed gradient directions (and hence resulting normal 
orientations).


With a pattern that has at least /some/ slope regions, you can work 
around this by increasing the scaling factor in the pigment inside the 
function by some factor Q, and compensating by scaling the normal by the 
inverse of that factor, 1/Q.

With `bozo` you're out of luck though: Its default colour map consists 
exclusively of plateaus, and the slopes are infinitely narrow. So as you 
increase the precision of the normal computations, the slopes will 
eventually vanish entirely, and you'll end up with a seemingly flat 
surface (because perturbed normals don't cast shadows). So the only way 
around this is to override the pattern's default colour map.


Post a reply to this message

From: clipka
Subject: Re: image based normal maps?
Date: 21 Jan 2019 10:34:17
Message: <5c45e679$1@news.povray.org>
Am 21.01.2019 um 15:08 schrieb Bald Eagle:

> Well, this is usually the point where either clipka jumps in with an inside-out
> explanation, since he has the big picture of the source code in his head and can
> translate, summarize, and put it in proper order and context.

=:-D


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

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