![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
The below scene demonstrates a bug in UVPov's sampling method 3. Render it and
the problem should be obvious. It seems to be related to the number of media
samples (more samples reduces the effect). It only manifests itself in areas
where the (non-black) background colour is visible.
Margus
//Begin scene
//lower background brightness and the problem becomes less visible
background{rgb .7}
camera{location <5,4,-8> look_at 0}
light_source{
-z*1000 color rgb 5000
spotlight point_at 0 radius .03 falloff .031
}
box{
-1+z,1
pigment{rgb x}
}
sphere{0,2000
pigment{rgbf 1}
finish{ambient 0 diffuse 0}
interior{
media{
scattering{1 rgb .0002 extinction 1}
intervals 1
samples 1,1
//samples 10,50 //more samples -> problem less visible
method 3
}
}
hollow
}
//The problem disappears on pixels occupied by the disc
disc{z*10,z,3 pigment{rgb z} finish{ambient .2} hollow}
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I didn't see any problem with uvpov 6.1 (nor any difference when I
increased the samples)...
Jerome
--
*******************************
* they'll tell you what can't * mailto:ber### [at] iname com
* be done and why... * http://www.enst.fr/~jberger
* Then do it. *
*******************************
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
That is weird... I am using 6.1 too (Windows compile downloaded from Nathan's
site).
Here, the light beam is not completely blocked by the box (i.e. it continues
beyond it, although it's fainter). Also, I have further explored the effect: it
is only visible when there is nothing between media and the background. When the
disc is made transparent, the bug is not visible this side of the disc, but it
is visible through the disc.
I will post a small image in p.b.i
Can anybody else reproduce the problem?
Margus
"Jerome M. BERGER" wrote:
>
> I didn't see any problem with uvpov 6.1 (nor any difference when I
> increased the samples)...
>
> Jerome
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I was able to reproduce it in the Smellenbergh POV-RayUnofficial
MultiPatch for Mac, which is apparently based in part on UVPov 6.1 code.
To the left is a bright beam of light, and off to the right a faint beam
of light continues off into the distance.
It is barely visible, gamma differences may make it invisible on some
systems.
Increasing extinction makes it a lot more visible, extinction of 0 makes
it invisible.
Very strange...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I can verify this bug and I am looking for a solution.
-Nathan
Margus Ramst <mar### [at] peak edu ee> wrote...
> The below scene demonstrates a bug in UVPov's sampling method 3. Render it
and
> the problem should be obvious. It seems to be related to the number of
media
> samples (more samples reduces the effect). It only manifests itself in
areas
> where the (non-black) background colour is visible.
>
> Margus
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ok. Fixed for the next release of UVPov.
-Nathan
Margus Ramst <mar### [at] peak edu ee> wrote ...
> The below scene demonstrates a bug in UVPov's sampling method 3. Render it
and
> the problem should be obvious. It seems to be related to the number of
media
> samples (more samples reduces the effect). It only manifests itself in
areas
> where the (non-black) background colour is visible.
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
What was it?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I tried to reuse samples between intervals (i.e. the last sample of an
interval would be reused as the first sample of the next). Unfortunately,
the samples already had a weight applied to them that was proportional to
the length of the interval. Thus, one sample from all intervals except for
the first could have an incorrect weight
The problem would not show up if all the intervals were the same length (all
the same weight). However, if one interval was shorter (because it
represented a lit interval that was part of a spotlight), then the weights
would be thrown off and things would look bad. More samples meant that the
error in that one sample would not show up as much.
The solution is to not reuse the samples. this means a bit slower
rendering, but it at least produces correct results. I tried to reuse the
samples and compensate for the incorrect weights, but it didn't work.
-Nathan
TonyB <ben### [at] panama phoenix net> wrote in...
> What was it?
>
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |