clipka <ano### [at] anonymousorg> wrote:
> Am 21.01.2019 um 13:05 schrieb Kenneth:
>
> 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".
>
> ...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)...

Yeah, I had an intuition that bozo's  flat RGB colors and sharp color borders
were at least one of the reasons for the 'plateaus' (plateux?), but I didn't
know how to put my fuzzy thoughts into words. You're much better at explanations
than I am ;-)

I'm still digesting your info, it's admittedly above my head at the moment (on a
higher plateau!)

My initial tests were actually with a continuous-tone color photo (as the
normals pattern), along with a bump_map-- then as a function normal instead, to
compare the two (which also showed the plateau difference.) THEN I chose bozo as
an 'in-built substitute' for using the color photo, to show the absolute
worst-case scenario. I wanted a *color* pattern rather than something grayscale
like bumps; but alas, POV's color patterns all have sharp color borders (bozo,
hexagon, etc.). I guess I could have made my own more 'continuous' color
pattern, but that didn't occur to me yesterday(!)

Anyway, I'm still a bit perplexed about the normals difference between the
following two constructs (using a continuous-tone color photo of your choice):

1)
box {<0, 0, 0>, <1, 1, 0.1>
pigment {rgb .5}
normal {bump_map {jpeg "my color photo.jpg" interpolate 2} bump_size 10}  }
....

and 2)
#declare NORM_FUNCTION =
function {pigment {image_map {jpeg "my color photo.jpg" interpolate 2} }}

box {<0, 0, 0>, <1, 1, 0.1>
pigment {rgb .5}
normal {function { NORM_FUNCTION (x, y, z).gray} bump_size 1.0}
....

The normals on box 1) look nice-- the 'expected' embossed appearance. Box 2)
shows the plateau effect (and the 90-deg 'quadrant' behavior)-- although it will
probably be more difficult to see when using a typical 'busy' photo. This is
what originally made me think that the image-to-FUNCTION process was the sole
cause.

But now I'm wondering if box 1's normals *also* have the plateaus and 90-deg
quadrants, just on a much smaller scale that can't readily be seen?

Your detailed explanation probably describes the reason(s) for the difference,
but I'm not yet grasping it...

Post a reply to this message

I just got done fiddling with an idea.
First, I'm curious how an internal/predefined function like f_noise3d still need
functions.inc .

Second - here's a noise-based normal function,
S is scale of the pattern
D is a small delta shift for the 3x3 sampling grid

0.01 seems to be where things shift from one weird version to another.
large values give some interesting repeating "ghosts" almost like a repeat warp,
and small values give closer to the native function (D=0) which has very well
defined "rings" which are much softer at D=0.1

Just thought I'd throw this in here to play with and perhaps clipka can explain
what the "rings" are.


#declare BumpMap = function {f_noise3d (x, y, z)};
#declare S=5;
#declare D = 0.01;

#declare CenterWeight = 8/9;
#declare EdgeWeight = 1/9;

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 {
      average
      normal_map {

      #for (Y, -D, D, D)
       #for (X, -D, D, D)
        [select (Y*X, EdgeWeight, CenterWeight, EdgeWeight) function { BumpMap
((x-X)*S, (y-Y)*S, z)*3}]
       #end
      #end // end for Y
      }
     }
}

Post a reply to this message

Am 22.01.2019 um 00:13 schrieb Kenneth:

> Anyway, I'm still a bit perplexed about the normals difference between the
> following two constructs (using a continuous-tone color photo of your choice):
> 
> 1)
> box {<0, 0, 0>, <1, 1, 0.1>
> pigment {rgb .5}
> normal {bump_map {jpeg "my color photo.jpg" interpolate 2} bump_size 10}  }
> .....
> 
> and 2)
> #declare NORM_FUNCTION =
> function {pigment {image_map {jpeg "my color photo.jpg" interpolate 2} }}
> 
> box {<0, 0, 0>, <1, 1, 0.1>
> pigment {rgb .5}
> normal {function { NORM_FUNCTION (x, y, z).gray} bump_size 1.0}
> .....

In this case, the difference is due to another reason, namely that 
`bump_map` has a special implementation: Rather than sampling somewhat 
arbitrary points in the pattern, it adapts to the resolution of the 
image, and also samples in the image plane. It can't do the same trick 
in the function-based variant because it can't even tell that the 
function is based on an image.

Post a reply to this message

Am 22.01.2019 um 02:33 schrieb Bald Eagle:
> I just got done fiddling with an idea.
> First, I'm curious how an internal/predefined function like f_noise3d still need
> functions.inc.

POV-Ray knows a couple of inbuilt functions.
It doesn't know them by any name though, just by internal numbers.

There's a special syntax to assign names to those internal numbers, 
which is exactly what `functions.inc` is doing.


> Second - here's a noise-based normal function,
> S is scale of the pattern
> D is a small delta shift for the 3x3 sampling grid
> 
> 0.01 seems to be where things shift from one weird version to another.
> large values give some interesting repeating "ghosts" almost like a repeat warp,
> and small values give closer to the native function (D=0) which has very well
> defined "rings" which are much softer at D=0.1

My guess is that it's some interference between your oversampling of the 
normal and the normal's internal sampling.

BTW, while working on the parser source code I just noticed that there's 
a parameter to control the "resolution" of the internal sampling, called 
`accuracy`. It defaults to 0.02, which explains why it's at this order 
of magnitude that strange things kick in.

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
>
> ...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,

Thomas wrote:

>  .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}}

I knew I had seen  .hf  *somewhere* but didn't know where to look. Thanks, Ingo.

But it comes as a fascinating surprise (to me) that .gray and .hf use different
color-to-grayscale formulas...

   .gray to get the gray value of the color vector:
    gray value = Red*29.7% + Green*58.9% + Blue*11.4%

   .hf to get the height_field value of the color vector:
    hf value = (Red + Green/255)*0.996093

I don't think I've ever actually used  .hf (in either a height_field OR a
function)-- but I'm mostly curious as to why they are different. And/or the
historical significance of the .hf formula. AFAIU, the .gray formula is the de
facto standard in POV-Ray for internal color conversions; but is there something
'special' about height_field/FUNCTION use that requires a different formula?

Post a reply to this message

> BTW, while working on the parser source code I just noticed that there's
> a parameter to control the "resolution" of the internal sampling, called
> `accuracy`. It defaults to 0.02, which explains why it's at this order
> of magnitude that strange things kick in.

Nice.  I love it when all of these posts and experiments and collaborations and
under-the-hood investigations have their periodic coincidences.  :)

So many little thing to be learned even after all this time.

Can you comment on the sharp rings / elevation lines in the noise pattern?
(I can post a render in p.b.i. if needed)
It was unexpected, and I couldn't get rid of them by changing the [over]sampling
delta.  There's a soft, fluffy, smooth noise as the background - softer than
expected, actually, but then the rings were "WTH are _those_?"

Post a reply to this message

in news:web.5c46ee32e20dd126cd98345b0@news.povray.org Kenneth wrote:

> And/or the
> historical significance of the .hf formula

In the days of old, the red+green chanel of 8 bit images where (ab)used to 
store 16 bit grayscale values for use in hight_field,

ingo

Post a reply to this message

On 22-1-2019 12:26, ingo wrote:
> in news:web.5c46ee32e20dd126cd98345b0@news.povray.org Kenneth wrote:
> 
>> And/or the
>> historical significance of the .hf formula
> 
> In the days of old, the red+green chanel of 8 bit images where (ab)used to
> store 16 bit grayscale values for use in hight_field,
> 

Ah ha! of course! Now this makes me curious about subtle visual 
differences between height_field functions using .hf or .grey, because 
there should be some, shouldn't there? I shall investigate.

-- 
Thomas

Post a reply to this message

Le 19-01-22 à 05:19, Kenneth a écrit :
> ingo <ing### [at] tagpovrayorg> wrote:
>>
>> ...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,
> 
> Thomas wrote:
> 
>>   .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}}
> 
> I knew I had seen  .hf  *somewhere* but didn't know where to look. Thanks, Ingo.
> 
> But it comes as a fascinating surprise (to me) that .gray and .hf use different
> color-to-grayscale formulas...
> 
>     .gray to get the gray value of the color vector:
>      gray value = Red*29.7% + Green*58.9% + Blue*11.4%
> 
>     .hf to get the height_field value of the color vector:
>      hf value = (Red + Green/255)*0.996093
> 
> I don't think I've ever actually used  .hf (in either a height_field OR a
> function)-- but I'm mostly curious as to why they are different. And/or the
> historical significance of the .hf formula. AFAIU, the .gray formula is the de
> facto standard in POV-Ray for internal color conversions; but is there something
> 'special' about height_field/FUNCTION use that requires a different formula?
> 
> 
> 
> 
> 

.hf use the red as the upper, or most significative, 8 bits and green as 
the lower, or least significative, 8 bits of a 16 bits value to be used 
as a height field. The *0.996093 is there as a fudge value to prevent 
clipping at the higher end of the range. The blue channel is ignored.

.grey use a ponderated average to get a grey equivalent of the colour.

Different intent and use, different ways to get the end value.

Post a reply to this message

Am 22.01.2019 um 17:47 schrieb Alain:

> ..hf use the red as the upper, or most significative, 8 bits and green 
> as the lower, or least significative, 8 bits of a 16 bits value to be 
> used as a height field. The *0.996093 is there as a fudge value to 
> prevent clipping at the higher end of the range. The blue channel is 
> ignored.

BTW, 0.996093 is 255/256.

The function might also be written as:

     hf value = (Red * 255 + Green) / 256

I think for technical reasons the function _should_ be

     hf value = (Red * 256 + Green) / 257

but alas! it isn't.

Post a reply to this message