On 8/5/21 6:10 PM, Bald Eagle wrote:
> "pkoning" <nomail@nomail> wrote:
> 
>> That doesn't seem to be the explanation.  I rewrote it without any declared
>> identifiers and it still fails:
> 
>> Same message, complaining about the warp.
> 
> Because you have it in the wrong place.
> You have a plain srgb pigment - no _pattern_.  So there is nothing to warp.
> Move the warp up into the normal statement and it works.
> 
> #declare tmoon = texture
> {
>    pigment { color srgb <0.55 0.60 0.65> }
>    finish { specular 0.1 }
>    normal {
>      bump_map {
>        png "plasma2.png"
>        bump_size 8e-3 *5
>      }
>      warp {spherical}
>    }
> 
>    scale <rfeature, rfeature * 2, 1>
>    no_bump_scale
> }
> 

I think you've got it Bill. The behavior, though, looks inconsistent to 
me. Maybe if I think about it more, it's how it must be?

Looking at something like this:

//---
#version 3.8;
global_settings { assumed_gamma 1 }

#declare pmoon = pigment {
     color rgb <0.55 0.60 0.65> warp {spherical}
}
#declare tmoon = texture {
     // pigment { color rgb <0.55 0.60 0.65> warp { spherical } }
     pigment {
         function { 0.5 }
         color_map {
             [ 0 color rgb <0.55 0.60 0.65> ]
             [ 1 color rgb <0.55 0.60 0.65> ]
         }
       //warp {spherical}
     }
     finish { specular 0.1 }
     normal {
         bump_map {
             png "plasma2.png"
              bump_size 8e-3 *5
         }
       //warp {spherical}
       }

     warp {spherical} // Parser sees this as illegal

     scale <1, 2, 1>
     no_bump_scale
}
//---

I get :

File 'hmm.pov' line 7: Possible Parse Error: Unmatched {
File 'hmm.pov' line 26: Parse Error: No matching }, warp found instead

If I comment that last warp{}, and un-comment two warp{}s above - or use 
instead the plain pigment inside the texture with the warp{}, I get no 
complaint about any 'pointless' warps(a) - though some of them certainly 
are.

There are likely situations where top level warps / turbulence could be 
applied and passed to contained blocks, but I believe it would be hard 
(impossible?) to do generally...

Drifting, the above examples touch on why I find myself sometimes 
wanting to be able to declare warp ids.

(a) - Not done any debugging to see if the 'pointless' warps / modifiers 
end up used.

Aside 1: turbulence{} trips this parse error too.

Aside 2: transforms can be pointless too and like turbulence and warp we 
'sometimes' get PossibleError warnings for those though I'm not aware of 
any hard errors there.

Aside 3: With image based mapping, the usual approach would be to use 
the appropriate map type inside the bump_map{} block - here 'map_type 1' 
spherical - though the warp{spherical} modifier should work too.

Aside 3a: There is too 'uv_mapping' for spheres which can be used inside 
texture, pigment and normal blocks.

:-) Nothing if not lots of knobs,  buttons and switches!

Bill P.

Post a reply to this message