POV-Ray : Newsgroups : povray.bugreports : bump maps inverted in spherical warp Server Time
28 Mar 2024 17:02:40 EDT (-0400)
  bump maps inverted in spherical warp (Message 1 to 10 of 15)  
Goto Latest 10 Messages Next 5 Messages >>>
From: pkoning
Subject: bump maps inverted in spherical warp
Date: 3 Aug 2021 16:25:00
Message: <web.6109a481dc4077061e101ef1b9aee0ac@news.povray.org>
I'm using a normal with a bump map, wrapped around a sphere using
warp{spherical}.  It looks normal in the northern hemisphere, but the bumps are
changed to depressions in the southern.
I've reproduced this on 3.8.0 alpha on Linux, as well as both 3.7 and 3.8 beta
on Macintosh.  Attached is a scene file that reproduces it (bumpmap.pov), along
with the two
bump map images it uses and the resulting image.  The "equator" on the image is
3 rows from the top, so you can see the top 3 rows are correct and the ones
below that are inverted.  (Light is above the camera.)
--paul


Post a reply to this message


Attachments:
Download 'bug.tar.gz' (387 KB)

From: clipka
Subject: Re: bump maps inverted in spherical warp
Date: 4 Aug 2021 03:07:05
Message: <610a3c99$1@news.povray.org>
Am 03.08.2021 um 22:19 schrieb pkoning:
> I'm using a normal with a bump map, wrapped around a sphere using
> warp{spherical}.  It looks normal in the northern hemisphere, but the bumps are
> changed to depressions in the southern.

This is a known issue that has been around for... well, ever since 
warped bump maps were first introduced, I guess.

Sometimes the bumps even seem to turn "sideways".


Post a reply to this message

From: pkoning
Subject: Re: bump maps inverted in spherical warp
Date: 4 Aug 2021 10:25:00
Message: <web.610aa29bfbcfb68e1e101ef1b9aee0ac@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 03.08.2021 um 22:19 schrieb pkoning:
> > I'm using a normal with a bump map, wrapped around a sphere using
> > warp{spherical}.  It looks normal in the northern hemisphere, but the bumps are
> > changed to depressions in the southern.
>
> This is a known issue that has been around for... well, ever since
> warped bump maps were first introduced, I guess.
>
> Sometimes the bumps even seem to turn "sideways".

And sometimes it doesn't happen.  Before today I haven't noticed it, though I
may have overlooked it.  In earlier tests I was using a plain texture instead of
the "cells" pattern, and then I don't remember seeing it.

Just  now I tried to reproduce it but I'm seeing a different baffling issue:
when I take out the "cells" pattern and replace it by a reference to a plain
texture, the parser complains that the "warp" modifier is not expected.  See
attached.

Possible Parse Error: Unmatched {

"/Users/pkoning/Documents/svn/tajemnica/bumpmap.pov"
 line 100
Parse Error: No matching }, warp found instead


Post a reply to this message


Attachments:
Download 'bumpmap.pov.txt' (3 KB)

From: Kenneth
Subject: Re: bump maps inverted in spherical warp
Date: 5 Aug 2021 02:45:00
Message: <web.610b87ecfbcfb68e4cef624e6e066e29@news.povray.org>
"pkoning" <nomail@nomail> wrote:

>
> Just  now I tried to reproduce it but I'm seeing a different baffling issue:
> when I take out the "cells" pattern and replace it by a reference to a plain
> texture, the parser complains that the "warp" modifier is not expected.  See
> attached.
>
> Possible Parse Error: Unmatched {
>
>  line 100
> Parse Error: No matching }, warp found instead

Apparently, a warp{...} cannot be added to a previously-#declared texture. I
sometimes run into similar problems; some things can be added, some can't.

Your syntax is like this:

#declare tmoon = texture
{
  pbfr // [previously-#declared]
  scale <rfeature, rfeature * 2, 1>
  no_bump_scale
  warp {spherical}
}

Interestingly, the no_bump_scale *is* OK there. I was surprised at that.


Post a reply to this message

From: Kenneth
Subject: Re: bump maps inverted in spherical warp
Date: 5 Aug 2021 03:30:00
Message: <web.610b930bfbcfb68e4cef624e6e066e29@news.povray.org>
"pkoning" <nomail@nomail> wrote:
>
> ...the parser complains that the "warp" modifier is not expected.  See
> attached.
>
> Possible Parse Error: Unmatched {
>...
> Parse Error: No matching }, warp found instead

By the way: As Clipka pointed out in a another recent thread, those "unmatched
{" warnings/errors are sometimes 'generic', in that they simply flag some kind
of 'possible' error that isn't clearly known to the parser. Yeah, it's kind of
confusing sometimes, to figure out what the true problem is. ;-)


Post a reply to this message

From: Thorsten
Subject: Re: bump maps inverted in spherical warp
Date: 5 Aug 2021 05:42:34
Message: <610bb28a$1@news.povray.org>
On 05.08.2021 09:28, Kenneth wrote:
> "pkoning" <nomail@nomail> wrote:
>>
>> ...the parser complains that the "warp" modifier is not expected.  See
>> attached.
>>
>> Possible Parse Error: Unmatched {
>> ...
>> Parse Error: No matching }, warp found instead
> 
> By the way: As Clipka pointed out in a another recent thread, those "unmatched
> {" warnings/errors are sometimes 'generic', in that they simply flag some kind
> of 'possible' error that isn't clearly known to the parser. Yeah, it's kind of
> confusing sometimes, to figure out what the true problem is. ;-)

Actually, the reason this is called "possible error" (my naming back 
then) has to do with the message driven changes to output from POV-Ray 
3.5 onward. Before, the parser would simply output to a text stream, so 
it was perfectly feasible to output some text somewhere and the next 
line would make sense out of it (from the user's perspective). However, 
there might be a long and complex call chain of internal parser 
functions between the place that detected the likely error and the place 
that actually knows it is an error.

In modern integrated development environments (IDEs) it is at last 
handled much better because the parsers hand them a full trace of all 
the steps they took to get where they are and the user gets a kind of 
trace where the parser went with each step and what it expected or 
allowed. So yes, error reporting evolved over the last 15 years. But it 
would require a very well structured parser, which POV-Ray doesn't have 
due to its age (and no, it is not easy to rewrite either, nor is it a 
beginner's task).

Thorsten


Post a reply to this message

From: pkoning
Subject: Re: bump maps inverted in spherical warp
Date: 5 Aug 2021 17:20:00
Message: <web.610c55a0fbcfb68e1e101ef1b9aee0ac@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> "pkoning" <nomail@nomail> wrote:
>
> >
> > Just  now I tried to reproduce it but I'm seeing a different baffling issue:
> > when I take out the "cells" pattern and replace it by a reference to a plain
> > texture, the parser complains that the "warp" modifier is not expected.  See
> > attached.
> >
> > Possible Parse Error: Unmatched {
> >
> >  line 100
> > Parse Error: No matching }, warp found instead
>
> Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> sometimes run into similar problems; some things can be added, some can't.
>
> Your syntax is like this:
>
> #declare tmoon = texture
> {
>   pbfr // [previously-#declared]
>   scale <rfeature, rfeature * 2, 1>
>   no_bump_scale
>   warp {spherical}
> }
>
> Interestingly, the no_bump_scale *is* OK there. I was surprised at that.

Yes, that's documented to affect the texture it is applied to and all its
offspring.

It's strange that warp works the way you mentioned, it makes it very hard to
use.  The fact that it's an undocumented behavior doesn't help.  (I suppose it
makes sense if it's considered a bug -- I think it should be.)


Post a reply to this message

From: pkoning
Subject: Re: bump maps inverted in spherical warp
Date: 5 Aug 2021 17:25:00
Message: <web.610c56abfbcfb68e1e101ef1b9aee0ac@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> sometimes run into similar problems; some things can be added, some can't.
>
> Your syntax is like this:
>
> #declare tmoon = texture
> {
>   pbfr // [previously-#declared]
>   scale <rfeature, rfeature * 2, 1>
>   no_bump_scale
>   warp {spherical}
> }
>
> Interestingly, the no_bump_scale *is* OK there. I was surprised at that.

That doesn't seem to be the explanation.  I rewrote it without any declared
identifiers and it still fails:

#declare tmoon = texture
{
  pigment { color srgb <0.55 0.60 0.65> }
  finish { moon_finish }
  normal {
    bump_map {
      png "robo-bfr.png"
      bump_size 8e-3 *5
    }
  }
  warp {spherical}
  scale <rfeature, rfeature * 2, 1>
  no_bump_scale
}

Same message, complaining about the warp.


Post a reply to this message

From: Bald Eagle
Subject: Re: bump maps inverted in spherical warp
Date: 5 Aug 2021 18:15:00
Message: <web.610c61cdfbcfb68e1f9dae3025979125@news.povray.org>
"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
}


Post a reply to this message

From: William F Pokorny
Subject: Re: bump maps inverted in spherical warp
Date: 5 Aug 2021 20:20:11
Message: <610c803b$1@news.povray.org>
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

Goto Latest 10 Messages Next 5 Messages >>>

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