 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcast net> wrote:
>
> Smaller error bounds and larger counts don't necessarily reduce the black
> artifacts that show up when using radiosity. In fact, in most of my
> experiments, the artifacts disappear with an error_bound of 1 or higher and a
> very small count. That, of course, can lead to blotchy surfaces, missing
> shadows, etc., so most of my work now has been trying to figure out what
> else I can adjust...while also eliminating
> the artifacts.
>
Neglecting possible problems with the isosurfaces: I should have mentioned that
the artifacts being black means that rad is picking up that black color from
somewhere, and using it for some of the patches. Behind and above the airplane
model, there appears to be a big expanse of pure(?) black. A wall? A sky_sphere?
And the reflective table as well. Anyway, try changing one or both of those
colors to something wild like <0,1,1>. I'm willing to bet that the 'black'
splotches change color too. (Not that this will solve your overall rad problem--
but just as a test to possibly help zero-in on the cause.)
BTW: If you are using a newer version of POV-ray (maybe 3.8xxx?), there is now a
'no radiosity' switch that can be added to a particular object. It prevents that
object-- and its color-- from contributing to the overall mix of rad-patch
colors.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Neglecting possible problems with the isosurfaces: I should have mentioned that
> the artifacts being black means that rad is picking up that black color from
> somewhere, and using it for some of the patches. Behind and above the airplane
> model, there appears to be a big expanse of pure(?) black. A wall? A sky_sphere?
> And the reflective table as well. Anyway, try changing one or both of those
> colors to something wild like <0,1,1>. I'm willing to bet that the 'black'
> splotches change color too. (Not that this will solve your overall rad problem--
> but just as a test to possibly help zero-in on the cause.)
Hmmm. Yes, if this is indeed the case, then we may be running into that
color-vector multiplier thing. Anything * <0, 0, 0> = <0, 0, 0>.
So maybe if an extreme change elicits a difference in the splotch color, try
changing your black to something small, but nonzero.
Maybe for ease of experimentation, define a scalar multiplier, and your black to
be that times <1, 1, 1>.
#declare SM = 0.1;
#declare Shade = SM * <1, 1, 1>;
#declare myBlack = pigment {rgb Shade}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > Neglecting possible problems with the isosurfaces: I should have mentioned
> > that the artifacts being black means that rad is picking up that black color
> > from somewhere...
>
> Hmmm. Yes, if this is indeed the case, then we may be running into that
> color-vector multiplier thing. Anything * <0, 0, 0> = <0, 0, 0>.
That's a good and interesting point. In effect: If *large* rad patches are a
blend of colors from various points/objects in the scene-- which I *think* is
the case-- and if one of those patches is pure black, then maybe the entire
'blend' is reduced to black there(?). I have never tested that, but it's worth
an experiment to see what happens.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > > Neglecting possible problems with the isosurfaces: I should have mentioned
> > > that the artifacts being black means that rad is picking up that black color
> > > from somewhere...
> >
> > Hmmm. Yes, if this is indeed the case, then we may be running into that
> > color-vector multiplier thing. Anything * <0, 0, 0> = <0, 0, 0>.
>
> That's a good and interesting point. In effect: If *large* rad patches are a
> blend of colors from various points/objects in the scene-- which I *think* is
> the case-- and if one of those patches is pure black, then maybe the entire
> 'blend' is reduced to black there(?). I have never tested that, but it's worth
> an experiment to see what happens.
Let me re-phrase that, so that my own idea is more clear:
If a SINGLE and large rad patch is a blend of colors from various points/objects
in the scene-- which I *think* is the case, depending on other rad settings--
and if one of those COLORS happens to be pure black, then maybe the entire
'blend' for that patch is reduced to black(?).
Of course, in a typical radiosity scene with a reasonable 'count' value, there
are lots of overlapping patches on objects-- so it might be difficult to
tease-out this blackening effect, if it's indeed happening.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcastnet> wrote:
> Latest attempt at an indoor scene lit by sunlight from a window. I ended up
> adding some extra lights for interest on the toys, too.
>
> This particular rendering was done with a pretty high anti-aliasing setting, but
> just the Radiosity_Fast setting for radiosity. Even increasing it to
> Radiosity_IndoorLQ introduced terrible artifacts on all of my isosurfaces, and I
> haven't figured out how to eliminate them yet.
>
> The blocks, the plane, the train and tracks are all isosurfaces with wood
> pattern perturbations. I experimented with a lot of combinations of low
> accuracy and high max_gradient, and used evaluation, but when I bump up the
> radiosity I end up with black splotches everywhere. I may need to dig into the
> details of the radiosity settings to figure out how to tune them for a
> particular scene...
>
> -- Chris R.
I added a few more elements to the scene, including some haze, generated by the
smoke puffing out of the train engine.
For this run, here were my radiosity settings:
pretrace_start 0.0625
pretrace_end 0.0078125
count 25
nearest_count 5
error_bound 0.25
low_error_factor 0.3
recursion_limit 2
-- Chris R.
Post a reply to this message
Attachments:
Download 'scene-v1.2-mq-2022-02-12.png' (739 KB)
Preview of image 'scene-v1.2-mq-2022-02-12.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcastnet> wrote:
> Latest attempt at an indoor scene lit by sunlight from a window. I ended up
> adding some extra lights for interest on the toys, too.
>
> This particular rendering was done with a pretty high anti-aliasing setting, but
> just the Radiosity_Fast setting for radiosity. Even increasing it to
> Radiosity_IndoorLQ introduced terrible artifacts on all of my isosurfaces, and I
> haven't figured out how to eliminate them yet.
>
> The blocks, the plane, the train and tracks are all isosurfaces with wood
> pattern perturbations. I experimented with a lot of combinations of low
> accuracy and high max_gradient, and used evaluation, but when I bump up the
> radiosity I end up with black splotches everywhere. I may need to dig into the
> details of the radiosity settings to figure out how to tune them for a
> particular scene...
>
> -- Chris R.
I tried a number of combinations of higher-quality radiosity settings and am
still getting artifacts; the higher the count and lower the error_bound the
worse the artifacts. In the image below, I took the radiosity settings from
before and just cut the pretrace_end size in half. As you can see, this
introduced a noticeable, but relatively small artifact on the robot's
glass-covered dial. I am running again with these same settings, but adding a
maximum_reuse of 0.05 and a minimum_reuse of 0.005 to see if that makes the
artifact go away or makes it worse.
-- Chris R.
Post a reply to this message
Attachments:
Download 'scene-v1.2-h1-2022-02-13.png' (736 KB)
Preview of image 'scene-v1.2-h1-2022-02-13.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
For what it is worth, I generally use the following radiosity settings,
to full satisfaction:
pretrace_start 0.08
pretrace_end 0.004
count 100, 1000
nearest_count 10, 5
error_bound 1
recursion_limit 2
low_error_factor 0.3
gray_threshold 0.0
minimum_reuse 0.015
maximum_reuse 0.1
brightness 1
adc_bailout 0.01/2
normal on
media off
always_sample off
This is quite fast and I experience little or no artefacts. Note the
dual (optional) parameters used for count and nearest_count. This can
increase the quality of your render without slowing it down much. See
the following page of the wiki:
https://wiki.povray.org/content/Reference:Radiosity#count
You may also want to try stochastic rendering with, e.g., +am3 +a0.01
+ac0.90 +r3. If you do that, change count to 10 all other radiosity
settings remaining the same.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> For what it is worth, I generally use the following radiosity settings,
> to full satisfaction:
>
> pretrace_start 0.08
> pretrace_end 0.004
> count 100, 1000
> nearest_count 10, 5
> error_bound 1
> recursion_limit 2
> low_error_factor 0.3
> gray_threshold 0.0
> minimum_reuse 0.015
> maximum_reuse 0.1
> brightness 1
>
> adc_bailout 0.01/2
> normal on
> media off
> always_sample off
>
> This is quite fast and I experience little or no artefacts. Note the
> dual (optional) parameters used for count and nearest_count. This can
> increase the quality of your render without slowing it down much. See
> the following page of the wiki:
> https://wiki.povray.org/content/Reference:Radiosity#count
>
> You may also want to try stochastic rendering with, e.g., +am3 +a0.01
> +ac0.90 +r3. If you do that, change count to 10 all other radiosity
> settings remaining the same.
>
> --
> Thomas
Thanks, I tried these out and they seem to have worked pretty well.
-- Chris R.
Post a reply to this message
Attachments:
Download 'scene-v1.2-tdg-hq-2022-02-14.png' (723 KB)
Preview of image 'scene-v1.2-tdg-hq-2022-02-14.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 15/02/2022 om 04:43 schreef Chris R:
>
> Thanks, I tried these out and they seem to have worked pretty well.
>
> -- Chris R.
Indeed. Looks pretty good. Most credit goes to Clipka and Alain I
believe, not forgetting all those povers struggling and coming up with
smart solutions. :-)
It is a fair basis from which tweaking can be done simply when necessary.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcastnet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > For what it is worth, I generally use the following radiosity settings,
> > to full satisfaction:
> > [snip]
> >
> > This is quite fast and I experience little or no artifacts. Note the
> > dual (optional) parameters used for count and nearest_count. This can
> > increase the quality of your render without slowing it down much.
>
> Thanks, I tried these out and they seem to have worked pretty well.
>
This does look much better.
About the 2-value count: In my own tests over the last six months, I have set
the 2nd value *really* high -- for example 700, 93271 (!) I have found that it
seems to smooth-out the distribution of the radiosity light patches, by
gathering them from many truly different random directions. (That's my rather
simplistic description of the process, anyway.) With a single-value count, those
directions/locations are still random-- to a degree-- but 'not quite random
enough', in my opinion; I have seen some subtle artifacts that look like
'harmonic bands' of rad patches on objects...like very subtle geometric bands or
stripes. Sorry that I can't be more descriptive, but it's an effect that the
higher 2nd count helps to eliminate.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
