POV-Ray

to duplicate issue, remove no_radiosity from sinai macro... sorry

version 3.7.0.RC7.msvc10-sse2.win32

winXP home SP3
Intel 4400 dual core
500mb

Can you please provide initial settings for Cam_pos, Cam_lkt and Cam_agl? Thanks.

//courtyard gating not included due to size of code and many external files needed. add anything around <0,0,0> to try to reproduce effect of error

Can't reproduce with just "anything around <0,0,0>"; please provide a scene that does show the problem without us having to guess what we might or might not have to add.

#ifndef(Cam_pos) #declare Cam_pos = 0; #end
#ifndef(Cam_lkt) #declare Cam_lkt = 0; #end
#ifndef(Cam_agl) #declare Cam_agl = 0; #end

thanks for the quick reply Christoph. Just too much to include to duplicate the image submitted so I'll duplicate the issuse with a simple scene and repost later today.

brilliance < 1.4 or emission > = 0 on first cylinder does not seem to duplicate the effect.
any exponent < = 1 in second cylinder does not seem to duplicate the effect.
multiple renders show black circles show up in random locations and sometimes do not show

povray.ini set to default at install
rendered at 640x480 no AA

global_settings {
  radiosity {
   pretrace_start .1
   pretrace_end .01
   error_bound .3
   recursion_limit 1
  }
}

light_source{
  500*y
  1
  rotate <-28, 0, 14>
}

camera {
  location <0, 7, -7>
  look_at <0, 3, 0>
}

background { rgb <.3, .5, .8> }
plane { y,0 pigment { rgb <1, 1, 1> } }

cylinder { <-1, 0, 0>, <-1, 3, 0>, .4 scale <1, 1, 10> rotate 55*y translate 5*z
 texture {
  pigment{ rgb .7 }
  finish{
   emission -.15
   brilliance 2
  }
 }
}

cylinder { <2.5, 0, 0>, <2.5, 3, 0>, .1
 texture {
  pigment { rgb .7 }
  finish {
   reflection {
    .2
    exponent 1.1
   }
  }
 }
}

   test.png (35 KiB)

The problem is not limited to radiosity, nor to negative emissions, as can be demonstrated with the following scene; there is a general problem when anything with a negative brightness is reflected in a surface with almost any exponent other than 1, causing the resulting image regions to be pitch black even if other properties of the reflecting surface would normally boost its brightness back to positive values:

light_source{
  500*y
  rgb 1
  rotate <-80, 60, 0>
}

light_source{
  500*y
  rgb -0.001
  rotate <-80, -60, 0>
}

camera {
  location <0, 3, -7>
  look_at <0, 1, 0>
}

background { rgb <.3, .5, .8> }
plane { y,0 pigment { rgb 1 } finish { reflection { 0.2 exponent 1.1 } } }

cylinder { <0, 0, 0>, <0, 1, 0>, 1
 texture {
  pigment{ rgb 1 }
  finish{
   diffuse 1.0
   ambient 0
   emission 0
  }
 }
}

exponent values that are the inverse of a natural number (such as 1/2, 1/3, etc.) appear to be safe. I suspect this is an inherent problem of the math involved, rather than an outright bug.

Note that reflection exponents other than 1.0 are anything but realistic; same goes for negative values for emission (although some particularly vivid yet still realistic colours may require individual colour components to be set to negative values, which will lead to similar problems with a non-1 reflection exponent).

thanks for looking into it Christoph.

I have been using v 3.62 for this project and descided to move up to 3.7. In adjusting lighting and textures to fit the new version, I went off on a tangent playing with the new features and seeing what effects would result from radical settings.

The new crackle has be pulling my hair out as it is definitely not backwards compatible with setting the version. It seems to have a different starting point in the pattern or something as using crackle as a pattern in a function has different results from 3.62

Thanks to you all for the great work. Radiosity looks awesome in 3.7.

There's a conceptual question how to interpret negative light. pow(color,exponent) has no meaning for negative color and noninteger exponent (trace.cpp::ComputeLightedTexture) and returns NaN, which breaks everything. You could either copy the sign, such as pow(fabs(color),exponent)*(color>0?1:-1), or just zero out the negative components, like color>0?pow(color,exponent):0. The second option makes a bit more sense, if this feature is meant to make the bright objects reflect, but ignore darker reflections.

The choice is completely arbitrary, as this feature is completely unphysical and breaks the linearity of light transport - multiplying all the lights by some factor changes the behavior of the reflective surface. For natural scenes, this is not needed anyway, povray internally uses floating point (high dynamic range), so bright objects can be made realistically bright.

Now tracked on github as issue #223.