stbenge <^@hotmail.com> wrote:
> No, I cannot. Recent tests don't seem to be showing any black splotches.
> Maybe 3.7's radiosity has been fixed somewhat after all. It used to
> happen when I rendered meshes with high-count radiosity. Strange black
> patches would appear, and higher count values only made it worse. If I
> run into it again, I'll post the relevant code.

Sounds like those classic "black splotches" issue I posted about recently.

They're all about POV-ray's way of keeping track of recursion depth - of the
trace in general (what you control with "max_trace_level") and radiosity (often
referred to as "bounce depth" - the thing you control with the "recursion_limit"
keyword).

In POV 3.6, the handling is straightforward wrong, causing those well-known
artifacts basically in every scene that has any reflection or refraction. POV
3.7 (at least the beta.29 - I haven't seen a single line of code of previous
betas) handles the whole issue differently, probably for totally unrelated
design issues. This change had a positive side effect on the black splotch
issues, but is somewhat bogus as well.

The next beta will most likely have this all sorted out properly (if the POV
team decides to includes my changes, that is).

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Reactor" <rea### [at] hotmailcom> wrote:
> > Well... basically, when you start to run into the 1600 count limit or the count
> > vs patience limit, I've found that some scenes can actually be made to work
> > with a lower count than usual by lengthening the pretrace step and dropping the
> > error bound very low.  Since one usually sees splotches when the count is too
> > low for a given error_bound, if the error_bound is dropped low enough, the
> > splotches become very small and distributed such that the shadows and shading
> > start becoming reasonably accurate again.
> > Depending on the scene, this method can work fairly well.  I have had some
> > degree of success on scenes that are indoors and involve sharper shadows and
> > rapid changes of light.  Outdoor, architectural scenes involving slower changes
> > of light and softer shadows seem to do better with the usual approach.
>
> I see... so what you're basically doing is "de-bundling" the sample rays.
>
> Theoretically this should be somewhat slower, as you probably use the same
> number of sample rays (total, not per sample), and just distribute them more
> evenly across the whole scene, so the lookup will be slowed down.
>
> However, I can also see how this might smoothen the look of the scene.
>

It doesn't smooth it much, actually.  I use it for sharp edges and small things
that a larger error bound would miss (i.e. radiosity is largely unaffected by
the addition or removal of the object).  In those cases, a small count of very
accurately, possibly widely spaced samples is more visually correct.  So far,
it is turning the door into a diffraction grating :(

I have noticed that an error_bound greater than 0.075 leads to the light
"seeping" through the walls.  Attached is an image rendered under
3.6.1.icl8win32  with the following radiosity block:

  radiosity {
    pretrace_start  64/image_width
    pretrace_end     1/image_width
    count 25
    nearest_count 20
    error_bound 0.05
    recursion_limit 4
    low_error_factor 0.5
    gray_threshold 0
    minimum_reuse 0.01
    brightness 1.0
    adc_bailout 0.01
    always_sample on
  }
  #end



I am still testing under MegaPov, but so far, this scene looks like it will
require a very high count, which is what I was hoping to avoid.

-Reactor

Post a reply to this message

Attachments:
Download 'the_secret.jpg' (26 KB)

Preview of image 'the_secret.jpg'

"Samuel Benge" <stb### [at] hotmailcom> schreef in bericht 
news:web.4959339e5b5ba55bf8e75d050@news.povray.org...
>
> There's a quick workaround for 3.7 radiosity. 3.7's radiosity doesn't seem 
> to
> like high count values, so to get more detail you can apply a small-scale
> global surface normal to all objects in your scene like so:
>

Yes, that is true indeed, now that you mention it. I almost 
automatically/unconsciously do this in many of my scenes. Don't remember 
were the trick came from...

Thomas

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> I am still testing under MegaPov, but so far, this scene looks like it will
> require a very high count, which is what I was hoping to avoid.

Try the sample randomization in MegaPOV - it might do some good, because it will
most likely break up the "diffraction grating" effect.

The problem is that POV-Ray doesn't randomize its samples at all, so if you have
a low sample count, the bright gap in the door is always picked up from the same
directions.


I'm currently toying around with some alternative approach of when to take new
samples.

Currently, the sampling is simply "expectation-driven": The scene geometry is
analyzed, and samples are taken if it is *estimated* that the existing samples
will have a too high error for a certain location.

I'm currently experimenting with an approach that sets up a coarse mesh of
samples using the same type of estimation, but when attempting to re-use
samples it checks by how much the existing samples *do* disagree.

Post a reply to this message

Am I correct in assuming that the very bright spot with streaks of
light in the corner of the room, while it might look cool, is actually a
rendering error (light leaks from underneath the wall even though it
shouldn't) and shouldn't be there?

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Am I correct in assuming that the very bright spot with streaks of
> light in the corner of the room, while it might look cool, is actually a
> rendering error (light leaks from underneath the wall even though it
> shouldn't) and shouldn't be there?

Yup.

Post a reply to this message

Among other things, clipka saw fit to write:

> Actually, the walls I use *do* have a thickness. It doesn't even matter
> whether I use meshes or CSG.

Coincident surfaces maybe? If each wall is a different block, do these
blocks overlap?

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Thomas de Groot wrote:
> "Samuel Benge" <stb### [at] hotmailcom> schreef in bericht 
> news:web.4959339e5b5ba55bf8e75d050@news.povray.org...
>> There's a quick workaround for 3.7 radiosity. 3.7's radiosity doesn't seem 
>> to
>> like high count values, so to get more detail you can apply a small-scale
>> global surface normal to all objects in your scene like so:
> 
> Yes, that is true indeed, now that you mention it. I almost 
> automatically/unconsciously do this in many of my scenes. Don't remember 
> were the trick came from...

I keep a section of my #default line ready for this all the time. Who 
knows who started doing it first. Maybe it's like the stacked planes 
trick for volumetrics. I'm pretty sure several people thought they had 
originated the idea (including me), only to find out later it had 
already been done. :)

Sam

Post a reply to this message

Jellby <me### [at] privacynet> wrote:
> Coincident surfaces maybe? If each wall is a different block, do these
> blocks overlap?

The initial thing I used was a mesh, which was basically a box, with a smaller
box cut out of it to form the room, and open at the bottom. The floor was
raised a little bit to make it wasn't coincident with the bottom surfaces of
that mesh.

I later tried to do the same with CSG, again using a box with a smaller box cut
out, this time leaving the bottom closed.

Same effect.

I'm not sure which version I used for the shots I posted, but at the moment I
actually don't really care too much.

Post a reply to this message

"stbenge" <^@hotmail.com> schreef in bericht 
news:495a9aa1@news.povray.org...
>
> I keep a section of my #default line ready for this all the time. Who 
> knows who started doing it first. Maybe it's like the stacked planes trick 
> for volumetrics. I'm pretty sure several people thought they had 
> originated the idea (including me), only to find out later it had already 
> been done. :)
>

Yes, that is another of those things!

Thomas

Post a reply to this message