Hello,

I have encountered a problem with smooth heightfield (I know I am
not alone). See in the images group. There are 3 images.

The first is the image of a SMOOTH heightfield with OFFICIAL POVRAY.
The second is the same image with MEGAPOV
The third is the same image WITHOUT SMOOTH and with MEGAPOV.

You can see the problem. I don't say that this problem of black
triangle doesn't appear with the offcial povray but this less
important.

I don't know how hard/easy is to solve this problem but...
It would be nice if someone (ok Nathan ;)) can do something.

Fabian.

Post a reply to this message

I forgot, the source are in the binaries scene file group

Fabian.


> 
> Hello,
> 
> I have encountered a problem with smooth heightfield (I know I am
> not alone). See in the images group. There are 3 images.
> 
> The first is the image of a SMOOTH heightfield with OFFICIAL POVRAY.
> The second is the same image with MEGAPOV
> The third is the same image WITHOUT SMOOTH and with MEGAPOV.
> 
> You can see the problem. I don't say that this problem of black
> triangle doesn't appear with the offcial povray but this less
> important.
> 
> I don't know how hard/easy is to solve this problem but...
> It would be nice if someone (ok Nathan ;)) can do something.
> 
> Fabian.

Post a reply to this message

Since the problem is much more pronounced in megapov, it seems quite clear
that it's some kind of bug.

  However, the general problem of getting odd-looking shadows in smooth
triangle meshes (and a smooth heightfield is just that) is not actually a
bug, but is caused by a self-shadowing problem which is not trivial to fix
(at least so that it will always work correctly and "physically" correctly).
  I have discussed this problem in p.programming and proposed a solution,
but it seems that it will not be corrected anytime soon (if it _is_ possible
to correct completely at all).
  You can get rid of the problem by making the object in question
shadowless. If, however, the shadows of the object are important, then there's
little you can do (besides making the mesh more detailed, ie. with more
triangles).

  In short, the problem is that the object shadows itself in parts that
should be lit due to the normal modifiers. But because normal modifiers are
only "fake" and they do not actually modify the shape of the surface, the
self-shadowing works like with unmodified normals. Making the object
shadowless eliminates this self-shadowing (but this is not always a good
solution if the shadow of the object is important).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Self-shadowing problem leads to black (rgb 0,0,0) triangle on the 
surface or just dark ones (like the triangles which are
actually in the shadow)? Here it is black triangle.

Anyway as you said, since the problem appear more in megapov than
in the official release there is some kind of bug.

Fabian.


> 
>   Since the problem is much more pronounced in megapov, it seems quite clear
> that it's some kind of bug.
> 
>   However, the general problem of getting odd-looking shadows in smooth
> triangle meshes (and a smooth heightfield is just that) is not actually a
> bug, but is caused by a self-shadowing problem which is not trivial to fix
> (at least so that it will always work correctly and "physically" correctly).
>   I have discussed this problem in p.programming and proposed a solution,
> but it seems that it will not be corrected anytime soon (if it _is_ possible
> to correct completely at all).
>   You can get rid of the problem by making the object in question
> shadowless. If, however, the shadows of the object are important, then there's
> little you can do (besides making the mesh more detailed, ie. with more
> triangles).
> 
>   In short, the problem is that the object shadows itself in parts that
> should be lit due to the normal modifiers. But because normal modifiers are
> only "fake" and they do not actually modify the shape of the surface, the
> self-shadowing works like with unmodified normals. Making the object
> shadowless eliminates this self-shadowing (but this is not always a good
> solution if the shadow of the object is important).
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Fabian BRAU <Fab### [at] umhacbe> wrote:
: Self-shadowing problem leads to black (rgb 0,0,0) triangle on the 
: surface or just dark ones (like the triangles which are
: actually in the shadow)? Here it is black triangle.

  It's just a shadow, so it's the color of a shadowed part. Usually they
are quite black unless you have a very high ambient.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Yes but in this example there is 4 light sources so there is no black
shadow. So these black triangle have not the color of shadow.
Strange.

Fabian.


> 
> Fabian BRAU <Fab### [at] umhacbe> wrote:
> : Self-shadowing problem leads to black (rgb 0,0,0) triangle on the
> : surface or just dark ones (like the triangles which are
> : actually in the shadow)? Here it is black triangle.
> 
>   It's just a shadow, so it's the color of a shadowed part. Usually they
> are quite black unless you have a very high ambient.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Fabian BRAU wrote:
> 
> Yes but in this example there is 4 light sources so there is no black
> shadow. So these black triangle have not the color of shadow.
> Strange.
> 
> Fabian.

It seems to be bug in version 0.5, not self shadowing. Changes list
indicates, that "double illumination bug is fixed", perhaps this is the
reason. If I have time, then I try to verify it (hopefully Nathan will
take a look at it, as he probably knows better this matter).

Post a reply to this message

Vahur Krouverk wrote:
> 
> It seems to be bug in version 0.5, not self shadowing. Changes list
> indicates, that "double illumination bug is fixed", perhaps this is the
> reason. If I have time, then I try to verify it (hopefully Nathan will
> take a look at it, as he probably knows better this matter).

I've made some renderings and it seems, that it is bug in POV-Ray. By
default smooth height-fields were double illuminated, but from version
0.5 it is changed to not double illuminate. Seems like smoothing is
changing some surface normals such way, that in intersection point it
appears to be faced backward (inward, into the mountain) and when double
illuminance is turned off, then it is drawn unlit.

In order to test my theory, I've added light source under the
height-field:
light_source {   
  <0.0, 0.0, 0.0>
  color rgb <1.000, 1.000, 1.000>*1.4000
  translate  <-2.0, -2.0, -50.0>
}

after this most of the blackness is gone, i.e. those backward surfaces
are lit by this additional light.

Also, when camera is moved upward, then those backward surfaces are gone
too, so seems like there is error in heightfield intersection (normal)
calculation. I don't know, whether it is due to some coding error or is
it some insolvable or hard-to-solve problem.

In order to make this scene work, there are following possibilities:
1. Create height-field image, which is smoother than current. I imported
it to leveller and smoothed it, after this most of wrong illuminated
surfaces were gone.
2. Double illuminate it by adding double_illuminate keyword.
3. If this can't be done (double illumination is unacceptable from
artistic point of view), then use "rough" height fields or move camera
upward.
4. If this is unacceptable, correct error in POV-Ray source code ;-)


HTH

Post a reply to this message

Vahur Krouverk <vah### [at] aetecee> wrote:
: By
: default smooth height-fields were double illuminated, but from version
: 0.5 it is changed to not double illuminate. Seems like smoothing is
: changing some surface normals such way, that in intersection point it
: appears to be faced backward

  Ah, so there really was a good reason for the double-illumination after all.
  It sounds more a kludge than a real fix, though...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Vahur Krouverk <vah### [at] aetecee> wrote:
> : By
> : default smooth height-fields were double illuminated, but from version
> : 0.5 it is changed to not double illuminate. Seems like smoothing is
> : changing some surface normals such way, that in intersection point it
> : appears to be faced backward
> 
>   Ah, so there really was a good reason for the double-illumination after all.
>   It sounds more a kludge than a real fix, though...

... and it doesn't work if you want to apply a slope pattern on the
hf...

Bouf.

Post a reply to this message