 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
System: POV-Ray for Windows v3.5b2, Windows NT4 sp6, AMD Athlon 1GHz,
256 megs SDRam
I know radiosity is considered experimental, but I thought I would
report my observation.
With recursion_limit 2 or higher a simple ambient sphere in a box
produces a very strange illumination.
If you run the appended script you will see very distinct vertical and
horizontal bright bands on the surfaces, of the same width as the
sphere.
Reducing the error_bound makes the edges of the bands sharper,
increasing count makes them more even.
Using a single box as the container gives much wider illuminated bands,
less easy to see.
The script gives an identical result with MegaPov 0.7.
Bye for now,
Mike Andrews.
// start of script
// +w160 +h120 -a
global_settings {
max_trace_level 5
assumed_gamma 1
ambient_light 1
#if(1)
radiosity {
pretrace_start 8/image_width
pretrace_end 4/image_width
count 200
error_bound 0.2
recursion_limit 2
}
#end
}
camera {
location <4, 3.0, -4.0>*7
direction 1.7*z
right x*image_width/image_height
look_at <-5, -10, 10>
}
// light source
sphere { 0, 2
pigment { rgb 10 }
finish { ambient 1 diffuse 0 }
translate <-5, -10, 10>
}
// container
#declare A = -<15,25,40>;
#declare B = <40,40,25>;
box { A-1+x,B+1-x inverse
pigment { rgb <1,.6,.2> }
finish { ambient 0 diffuse 0.8 }
}
box { A-1+y,B+1-y inverse
pigment { rgb <.6,.2,1> }
finish { ambient 0 diffuse 0.8 }
}
box { A-1+z,B+1-z inverse
pigment { rgb <.2,1,.6> }
finish { ambient 0 diffuse 0.8 }
}
// end of script
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Michael Andrews" <M.C### [at] reading acuk> wrote in message
news:3BAB71AF.B0F503CA@reading.ac.uk...
> System: POV-Ray for Windows v3.5b2, Windows NT4 sp6, AMD Athlon 1GHz,
> 256 megs SDRam
>
> I know radiosity is considered experimental, but I thought I would
> report my observation.
>
> With recursion_limit 2 or higher a simple ambient sphere in a box
> produces a very strange illumination.
>
> If you run the appended script you will see very distinct vertical and
> horizontal bright bands on the surfaces, of the same width as the
> sphere.
>
> Reducing the error_bound makes the edges of the bands sharper,
> increasing count makes them more even.
>
> Using a single box as the container gives much wider illuminated bands,
> less easy to see.
>
> The script gives an identical result with MegaPov 0.7.
Not a bug, just bad settings; and possibly scene setting too considering
there's a large black emptiness behind the camera.
Try the following:
radiosity {
pretrace_start 8/image_width
pretrace_end 4/image_width
count 123 // does not need to be as high now
error_bound 1.6 // higher smoother
low_error_factor .04 // lower smoother
nearest_count 3 // lower faster, less quality
max_sample 4 // ?? higher better ??
recursion_limit 2 // 3 is really slow, 1 is dimmer
}
It only seems there's a problem when you muck around with the settings and
get bad ones. Not easy to get right, which is why leaving all out and
letting defaults be used generally looks okay. But certainly the recursion
limit isn't faulty.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry Bob, maybe I wasn't clear about what I perceive as the bug.
With recursion_limit 1 the scene gives exactly what I would expect to
see - bright areas on the surfaces by the high ambient ball, intensity
falling off in a roughly circular fashion, smoother with higher count
and more patchy with lower error_bound. I would expect to see something
similar with a higher recursion_limit.
With recursion_limit 2 or more the bright patches are no longer
circular, they are clear (axis aligned?) bands on the surfaces. You even
get a brighter area where the bands cross. These bands become more
distinct as you lower the error_bound and get less patchy as you
increase the count.
You can see these bands on the radiosity passes with your settings too -
the very high error_bound on the final pass is simply smearing them
across the surfaces, the underlying problem is still there.
This seems to indicate to me that there is a sampling problem within the
radiosity code.
After looking through the MegaPov radiosity code, the only odd thing
that I can see is that exactly the same sequence of radiosity samples is
taken each time. With the way the local (axis aligned?) basis vectors
are set up, could this be producing up a sampling bias? I'm sorry, but
this is about where my brain starts to gibber and finds a dark corner to
hide in ...
I hope this clarifies my point a little.
Bye for now,
Mike Andrews.
"Bob H." wrote:
> Not a bug, just bad settings; and possibly scene setting too considering
> there's a large black emptiness behind the camera.
>
> Try the following:
>
> radiosity {
> pretrace_start 8/image_width
> pretrace_end 4/image_width
> count 123 // does not need to be as high now
> error_bound 1.6 // higher smoother
> low_error_factor .04 // lower smoother
> nearest_count 3 // lower faster, less quality
> max_sample 4 // ?? higher better ??
> recursion_limit 2 // 3 is really slow, 1 is dimmer
> }
>
> It only seems there's a problem when you muck around with the settings and
> get bad ones. Not easy to get right, which is why leaving all out and
> letting defaults be used generally looks okay. But certainly the recursion
> limit isn't faulty.
>
> Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Michael Andrews wrote:
>
> This seems to indicate to me that there is a sampling problem within the
> radiosity code.
I have noticed this too. I have one scene where this directional
preference shows clearly. I'll post it if I can find it.
_____________
Kari Kivisalo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kari Kivisalo wrote:
>
> Michael Andrews wrote:
> >
> > This seems to indicate to me that there is a sampling problem within the
> > radiosity code.
>
> I have noticed this too. I have one scene where this directional
> preference shows clearly. I'll post it if I can find it.
>
> _____________
> Kari Kivisalo
Yes, I had several scenes in MegaPoV where there was a marked difference
between one bounce and two bounce radiosity, but this is the clearest
I've seen it.
If I can remember how to compile MegaPoV with MinGW I'll have a go
tweaking the radiosity source. I can think of two things to try:
randomize the local basis vector rotation and randomize the starting
point for the sampling sequence (or just continue where the last
sequence left off, perhaps).
Any other suggestions would be appreciated.
Bye for now,
Mike Andrews.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Michael Andrews" <M.C### [at] readingacuk> wrote...
>
> With recursion_limit 2 or higher a simple ambient sphere in a box
> produces a very strange illumination.
>
> If you run the appended script you will see very distinct vertical and
> horizontal bright bands on the surfaces, of the same width as the
> sphere.
I can confirm this as a bug. It will be fixed in a future beta. (The fix
will probably not be included in beta 5, which should be out very shortly,
but should be in beta 6.)
For those who want details: The problem was with two static vectors (n2 and
n3) in the radiosity code. I converted them to local variables (moved them
inside the scope of ra_gather) and the problem disappeared. I also removed
vector nn3 since it was unused.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Go, Nathan! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
> For those who want details: The problem was with two static vectors (n2 and
> n3) in the radiosity code. I converted them to local variables (moved them
> inside the scope of ra_gather) and the problem disappeared. I also removed
> vector nn3 since it was unused.
>
> -Nathan
Damn! I remember looking at these variables and wondering why they were
set up as static, but I never thought of actually changing them to
locals.
Well done and many thanks Nathan.
Bye for now,
Mike Andrews.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nathan Kopp" <nat### [at] koppcom> wrote...
>
> For those who want details: The problem was with two static vectors (n2
and
> n3) in the radiosity code. I converted them to local variables (moved
them
> inside the scope of ra_gather) and the problem disappeared. I also
removed
> vector nn3 since it was unused.
It looks like this also fixed some of the problems with artifacts... you
know - the ones that would always show up in the corners. Can anyone
determine if these artifact problems have diminished?
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
