Hi,

Rendering a movie under beta 24 (Windows version, under Windows Server 2003 on a
dual core Athlon), I noticed some random blocky brightness variations in parts
of my scene viewed through a semitransparent object. The affected blocks vary
from render to render (i.e. I get different results each time it renders).
Checking with version 3.6, this doesn't happen. I've cut out and simplified
enough of my source code to show the effect:

camera { location <-30,10,5> look_at 0 angle 25 }
light_source{ <-100,30,70> rgb 1 }
difference { // make a dome
  sphere { <0,0,0> 5 }  // ball
  sphere { <0,0,0> 4.9 } // hollow interior
  box { <-6,-6,-6> <6,1,6>  pigment { rgb 0 }}  // chop off bottom half
  pigment { rgbt <1,1,1,0.675> }
}
box { <-6,-6,-6> <6,0.99,6> pigment { rgb 1 } } // sit it on a box

The blockiness is visible mainly on the top surface of the box, viewed through
the dome. Note that the effect disappears if:
 - I remove the pigment from the box element used to cut off the bottom of the
sphere
 - I shift the lower box up a little till it touches the bottom edge of the dome

While I can work around it easily now, I thought I'd bring it to the Beta team's
attention.

Cheers,

Andrew.

Post a reply to this message

"ajm" <ajm### [at] aaogovau> wrote:
> Hi,
>
> Rendering a movie under beta 24 (Windows version, under Windows Server 2003 on a
> dual core Athlon), I noticed some random blocky brightness variations in parts
> of my scene viewed through a semitransparent object. The affected blocks vary
> from render to render (i.e. I get different results each time it renders).
> Checking with version 3.6, this doesn't happen. I've cut out and simplified
> enough of my source code to show the effect:
>
> camera { location <-30,10,5> look_at 0 angle 25 }
> light_source{ <-100,30,70> rgb 1 }
> difference { // make a dome
>   sphere { <0,0,0> 5 }  // ball
>   sphere { <0,0,0> 4.9 } // hollow interior
>   box { <-6,-6,-6> <6,1,6>  pigment { rgb 0 }}  // chop off bottom half
>   pigment { rgbt <1,1,1,0.675> }
> }
> box { <-6,-6,-6> <6,0.99,6> pigment { rgb 1 } } // sit it on a box
>
> The blockiness is visible mainly on the top surface of the box, viewed through
> the dome. Note that the effect disappears if:
>  - I remove the pigment from the box element used to cut off the bottom of the
> sphere
>  - I shift the lower box up a little till it touches the bottom edge of the dome
>
> While I can work around it easily now, I thought I'd bring it to the Beta team's
> attention.
>
> Cheers,
>
> Andrew.

http://tag.povray.org/povQandT/languageQandT.html#blackspots

Post a reply to this message

Trevor G Quayle nous apporta ses lumieres en ce 2008/01/29 01:13:
> "ajm" <ajm### [at] aaogovau> wrote:
>> Hi,
>>
>> Rendering a movie under beta 24 (Windows version, under Windows Server 2003 on a
>> dual core Athlon), I noticed some random blocky brightness variations in parts
>> of my scene viewed through a semitransparent object. The affected blocks vary
>> from render to render (i.e. I get different results each time it renders).
>> Checking with version 3.6, this doesn't happen. I've cut out and simplified
>> enough of my source code to show the effect:
>>
>> camera { location <-30,10,5> look_at 0 angle 25 }
>> light_source{ <-100,30,70> rgb 1 }
>> difference { // make a dome
>>   sphere { <0,0,0> 5 }  // ball
>>   sphere { <0,0,0> 4.9 } // hollow interior
>>   box { <-6,-6,-6> <6,1,6>  pigment { rgb 0 }}  // chop off bottom half
>>   pigment { rgbt <1,1,1,0.675> }
>> }
>> box { <-6,-6,-6> <6,0.99,6> pigment { rgb 1 } } // sit it on a box
>>
>> The blockiness is visible mainly on the top surface of the box, viewed through
>> the dome. Note that the effect disappears if:
>>  - I remove the pigment from the box element used to cut off the bottom of the
>> sphere
>>  - I shift the lower box up a little till it touches the bottom edge of the dome
>>
>> While I can work around it easily now, I thought I'd bring it to the Beta team's
>> attention.
>>
>> Cheers,
>>
>> Andrew.
> 
> http://tag.povray.org/povQandT/languageQandT.html#blackspots
> 
> 
> 
1 - There are no coincident surfaces. The bottom box top is 0.01 unit lower than 
the edge of the dome.
2 - The artefact disapear if the bottom box is moved up until there IS a 
coincident surface.

-- 
Alain
-------------------------------------------------
WARNING: The consumption of alcohol may cause you to think you can sing.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> 1 - There are no coincident surfaces. The bottom box top is 0.01 unit lower than
> the edge of the dome.
> 2 - The artefact disapear if the bottom box is moved up until there IS a
> coincident surface.

I guess I didn't really look at the code good enough, the description seemed to
indicate coincident surface.

I can see what is meant now.  I can verify it is happening though I don't know
why.  It occurs as long as there is a pigment attached to the differencing box
and the bottom box is below the cut surface of the sphere, but still viewed
through the sphere.

-tgq

Post a reply to this message

Having investigated a little further:

The artifacts relate to the 32x32 pixel 'blocks' into which the image is carved
for separate rendering by different threads (I guess there's a proper term for
those blocks?). It appears there's a random chance a block may erroneously come
up with a slightly bright result, consistent throughout that rendering block.

The problem happens under 64 and 32-bit windows versions, and Linux.

The problem persists even when using +wt1 to force it to run just one thread. In
this case it looks to me as though the distribution of brighter blocks may be
reproduced exactly the same on subsequent renders, though with more threads it
varies from render to render.

In my more complex scene, the problem persists even when I remove the pigment
from the differencing box (which seems to make it go away in the simple version
above).

Cheers,

Andrew.

Post a reply to this message

......if it helps, the (45MB) movie where the problem jumps up at me is at
ftp://ftp.aao.gov.au/pub/local/ajm/random/pilot_movie.mpg, the problem
showing up rather horribly at about 1 minute when I try to fade the dome to
transparency. A single representative frame is
ftp://ftp.aao.gov.au/pub/local/ajm/random/pilot_movie1527.png

Cheers,

Andrew.

Post a reply to this message

Hi Andrew,

We can't look at it now as beta 25 is due (24 has expired), but will do so
before the next beta.

NB if you're familiar with C++, you may want to have a look for the cause
yourself once the source is released, which will be within the next few days.

-- Chris

Post a reply to this message

On Wed, 30 Jan 2008 23:25:25 EST
"ajm" <ajm### [at] aaogovau> wrote:

> ......if it helps, the (45MB) movie where the problem jumps up at me is
> at ftp://ftp.aao.gov.au/pub/local/ajm/random/pilot_movie.mpg, the
> problem showing up rather horribly at about 1 minute when I try to fade
> the dome to transparency. A single representative frame is
> ftp://ftp.aao.gov.au/pub/local/ajm/random/pilot_movie1527.png
> 
> Cheers,
> 
> Andrew.

Hi Andrew. 

I'm not sure this is the same effect, but this appears with the normal
(not multi-threading) version of POVray:

http://jcoppens.com/ant/compare/img/009_z.png (random block at right)
http://jcoppens.com/ant/compare/img/009_y.png (blocks at center and
bottom) 
http://jcoppens.com/ant/compare/img/009_x.png (many blocks)

All the artifacts disappear when going to non-transparency, so it is not
the input dataset (which is generated in nec, an antenna sim program).

John

Post a reply to this message