Ive wrote:

>> #declare N_Cloth = normal {function {f_cloth(x,y,z).red}}
>>
> 
> sorry, but this will not work (as expected) as the function you feed 
> into the normal statement needs to evaluate the *slope* and not the 
> *height* at a specific point in 3d space.

I have to admit I didn't think too deep about this and just did a
test render which looks suspicously similar to that of Thomas ;)

In the documentation I now found 3.5.2.1

"Each of the various pattern types available is in fact a mathematical 
function that takes any x, y, z location and turns it into a number 
between 0.0 and 1.0 inclusive. That number is used to specify where the 
various high and low spots are."

I'd interpret that to mean it's actually the height, not the slope.
Also, a slope_map assigning slopes to heights makes more sense then.

Post a reply to this message

Dave Blandston wrote:

> Wow, that's fantastic! Thanks for taking the time to do that an post it!

Glad I could finally contribute something useful ;)

Post a reply to this message

"Dave Blandston" <nomail@nomail> schreef in bericht 
news:web.4b7bf3a8adaa4c5ecba3fb0f0@news.povray.org...
> Here's a simple computer programming example to show how and why this 
> works:
>
>   x = 1;
>   .
>   .
>   .
>   x = x + 1;
>
> In this case, the variable "x" is assigned a value (1), then later it's 
> assigned
> a new value based on the old value. This works because when the new value 
> is
> assigned, a temporary copy is made of the old value, manipulated (in this 
> case 1
> is added), then re-stored in the original location and becomes "x" again.
> "P_Cloth" is just a more complex variable that can be manipulated like any
> simpler variable. The restriction would be that once "P_Cloth" is defined 
> as a
> pigment it must remain a pigment.
>
> This can be a useful technique to make your scenes more readable, and also 
> more
> efficient by not leaving intermediate variables laying around.

Interesting. I knew this of course for variables, but I had never realized 
that it applied also to more complex pigment codes. I don't think this is 
mentioned in the docs, is it? I always assumed that one needed intermediate 
names to make this work.

Yet learned something new! Hurray!  :-)

Thanks indeed for the explanation, Dave.

Thomas

Post a reply to this message

Thomas de Groot wrote:

> Interesting. I knew this of course for variables, but I had never realized 
> that it applied also to more complex pigment codes.

Ah, but everything you #declare is a variable. The value
of the variable P_Cloth just happens to be a pigment. There's
nothing special about this variable ...

Dave Blandston wrote:

 > The restriction would be that once "P_Cloth" is defined as a
 > pigment it must remain a pigment.

... which is why this is also incorrect. Feel free
to follow it up with

#declare P_Cloth = 5;

or

#declare P_Cloth = sphere {0,1}

or even

#declare P_Cloth = sphere {0,1 pigment {P_Cloth}}

The reason you can use P_Cloth to define P_Cloth is that
the right hand side of an assignment is processed first,
then the result is assigned to the left hand side.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Ah, but everything you #declare is a variable. The value
> of the variable P_Cloth just happens to be a pigment. There's
> nothing special about this variable ...
>
> Dave Blandston wrote:
>
>  > The restriction would be that once "P_Cloth" is defined as a
>  > pigment it must remain a pigment.
>
> ... which is why this is also incorrect. Feel free
> to follow it up with
>
> #declare P_Cloth = 5;
>
> or
>
> #declare P_Cloth = sphere {0,1}
>
> or even
>
> #declare P_Cloth = sphere {0,1 pigment {P_Cloth}}
>
> The reason you can use P_Cloth to define P_Cloth is that
> the right hand side of an assignment is processed first,
> then the result is assigned to the left hand side.

Oh yes, my mistake! Thanks!

Regards,
Dave Blandston

Post a reply to this message

"Dave Blandston" <nomail@nomail> schreef in bericht 
news:web.4b7dc3e6adaa4c5ecba3fb0f0@news.povray.org...
> Christian Froeschlin <chr### [at] chrfrde> wrote:
>> Ah, but everything you #declare is a variable. The value
>> of the variable P_Cloth just happens to be a pigment. There's
>> nothing special about this variable ...
>>
>> Dave Blandston wrote:
>>
>>  > The restriction would be that once "P_Cloth" is defined as a
>>  > pigment it must remain a pigment.
>>
>> ... which is why this is also incorrect. Feel free
>> to follow it up with
>>
>> #declare P_Cloth = 5;
>>
>> or
>>
>> #declare P_Cloth = sphere {0,1}
>>
>> or even
>>
>> #declare P_Cloth = sphere {0,1 pigment {P_Cloth}}
>>
>> The reason you can use P_Cloth to define P_Cloth is that
>> the right hand side of an assignment is processed first,
>> then the result is assigned to the left hand side.
>

To tell the truth, while I see the positive sides of this, I also feel this 
is highly confusing in the end, as you may lose track of all the 
intermediary stages of variable changes.

Thomas

Post a reply to this message

On 17.02.2010 22:57, Christian Froeschlin wrote:
> Ive wrote:
>
>>> #declare N_Cloth = normal {function {f_cloth(x,y,z).red}}
>>>
>>
>> sorry, but this will not work (as expected) as the function you feed
>> into the normal statement needs to evaluate the *slope* and not the
>> *height* at a specific point in 3d space.
>
> I have to admit I didn't think too deep about this and just did a
> test render which looks suspicously similar to that of Thomas ;)
>
> In the documentation I now found 3.5.2.1
>
> "Each of the various pattern types available is in fact a mathematical
> function that takes any x, y, z location and turns it into a number
> between 0.0 and 1.0 inclusive. That number is used to specify where the
> various high and low spots are."
>
> I'd interpret that to mean it's actually the height, not the slope.
> Also, a slope_map assigning slopes to heights makes more sense then.


See the attached images from an old test scene of mine (updated to 3.7 
beta).
The first image is the grayscale image that is used within the second 
one on the left side as a bump_map (and it looks of course as expected) 
and on the right side via pigment and function declaration within a 
normal statement - and this one does *not* look right.

So to me it *looks* like it is expecting a slope not a height, no matter 
what the docs do say ;)
In fact I would be glad if this wouldn't be the case as I do need 
sometimes the same image as a transparency and a normal map and it has 
to be loaded twice (one time as am image_map and one time as a bump_map) 
resulting in quite a waste of memory.


Here's the source:

// ------------------------------------------------

#version 3.7;

camera {
   location  -z*4
   direction 1.5*z
   right     x*image_width/image_height
   look_at   0
}

light_source {0, rgb 1
   translate <30, 30, -10>
}


#declare N_Lace1 = normal {bump_map {jpeg "pat" interpolate 2}}

box {-1, 1
   pigment {rgb 0.6}
   finish {ambient 0  diffuse 1 specular 0.1}
   normal {N_Lace1 bump_size 1}
   translate -x*1
}


#declare P_Lace2 = pigment {image_map{jpeg "pat" file_gamma 1.0 
interpolate 2}}

#declare F_Lace2 = function {pigment {P_Lace2}}

#declare N_Lace2 = normal {function {F_Lace2(x,y,z).gray} bump_size 0.1}


box {-1, 1
   pigment {rgb 0.6}
   finish {ambient 0  diffuse 1 specular 0.1}
   normal {N_Lace2}
   translate x*1
}

// ------------------------------------------------

Post a reply to this message

Attachments:
Download 'pat.jpg' (48 KB) Download 'normaltest.jpg' (138 KB)

Preview of image 'pat.jpg'

Preview of image 'normaltest.jpg'

On 17.02.2010 14:23, Thomas de Groot wrote:

> The image below only uses Christian's normal. I don't see a problem there
> (except that the object is ill chosen of course).
>

Did find my old test scene and there *is* a problem. See my reply to 
Christian.

-Ive

Post a reply to this message

Ive wrote:

> The first image is the grayscale image that is used within the second 
> one on the left side as a bump_map (and it looks of course as expected) 
> and on the right side via pigment and function declaration within a 
> normal statement - and this one does *not* look right.

hmm ... there may be a difference here between looking
"not right" and looking "like crap" ;) While the right image
is not what you want, it does actually seem to have light
and dark regions roughly in the correct place. I just had
a quick peek in the code and I think this is what happens:

In both cases, a scalar map needs to be interpreted for
normal perturbation. It can't actually be a slope, because
that wouldn't contain enough 3d information (note that some
built-in patterns such as bumps or wrinkles have vector
versions which can be used for direct perturbation).

To get from the scalar height map to a normal, a 3d triangle is
constructed from 3 points on the height map. It's normal vector
is the vector used for the normal perturbation at this location.

BUT!

The bump_map has it's own implementation. Similar to a
height_field, it will use the image pixel coordinates for
3d triangles. The general case will sample at the arbitrary
distance of 0.02 units in world coordinates. This leads to
very noticable sampling artifacts when the input function
is highly discrete.

In fact, you can get wildly different output when playing
with the accuracy parameter (which effectively represents the
sampling distance noted above):

#declare N_Lace2 = normal {function {F_Lace2(x,y,z).gray} accuracy 0.011 
bump_size 0.1}

Post a reply to this message