 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
Attachments:
Download 'scene-v1.2-mq-2022-01-28.png' (782 KB)
Preview of image 'scene-v1.2-mq-2022-01-28.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcast net> 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.
Just a note on the artifacts. Playing around with other radiosity settings,
(and even looking more closely at this one), the landing gear on the plane are
just simple cylinders, but I can see radiosity artifacts on them, too. So, the
problem isn't limited to isosurfaces, although it is more prevalent there.
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Looking through the "rad_def" include file, I see that all of the radiosity
entries there are missing a maximum_reuse value-- which means that it defaults
to 0.2 in all of the cases. That's a rather large value, and can produce some
large-sized splotches. (From the docs' explanations of the various rad settings,
and possibly from code examples I've seen there(?), the 'typical' spread between
minimun_reuse and maximum_reuse should(?) be approximately 1:13; I guess that's
a trade-off between quality and render speed. And the spread is also designed so
that large flat surfaces get the maximum value-- large smooth rad patches--
whereas curved surfaces or other 'non-flat' areas get smaller patches.
Personally, I now like to use a *small* spread between min and max_reuse; it
kind of defeats the purpose of the render-speed trade-off, and produces patches
that are all of the same (smaller) size; but I like the higher-quality look,
especially if rad's count value is greatly increased to produce more patches.
Anyway...
As an experiment when using, say, the "rad_def" Radiosity_Fast entry (which has
a minimum_reuse value of 0.025), add a maximum_reuse there of 0.026. And greatly
increase the 'count' value. It will be a slow render, so maybe pick out a
smaller section of the image to test (and turn off AA). I can't predict what the
results will be, but this *might* improve the results.
BTW: In your image post, it looks like some of the objects' colors might be
exceeding <1.0,1.0,1.0>, perhaps due to the combination of lights used. This
could be a reason for some of the rad artifacts. Try decreasing the objects'
diffuse values a bit, so that nothing in the scene produces a max color
brightness exceeding 1.0. It will probably be a guessing game of trial and error
;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2022-01-29 à 03:16, Kenneth a écrit :
> BTW: In your image post, it looks like some of the objects' colors might be
> exceeding <1.0,1.0,1.0>, perhaps due to the combination of lights used. This
> could be a reason for some of the rad artifacts. Try decreasing the objects'
> diffuse values a bit, so that nothing in the scene produces a max color
> brightness exceeding 1.0. It will probably be a guessing game of trial and error
> ;-)
>
>
>
>
If that's the case, then, it could be interesting to use a smaller value
for the radiosity adc_bailout.
After all, in the documentation, it is stated that you should use a
smaller value when you have very bright objects or surfaces.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Looking through the "rad_def" include file, I see that all of the radiosity
> entries there are missing a maximum_reuse value-- which means that it defaults
> to 0.2 in all of the cases. That's a rather large value, and can produce some
> large-sized splotches. (From the docs' explanations of the various rad settings,
> and possibly from code examples I've seen there(?), the 'typical' spread between
> minimun_reuse and maximum_reuse should(?) be approximately 1:13; I guess that's
> a trade-off between quality and render speed. And the spread is also designed so
> that large flat surfaces get the maximum value-- large smooth rad patches--
> whereas curved surfaces or other 'non-flat' areas get smaller patches.
>
> Personally, I now like to use a *small* spread between min and max_reuse; it
> kind of defeats the purpose of the render-speed trade-off, and produces patches
> that are all of the same (smaller) size; but I like the higher-quality look,
> especially if rad's count value is greatly increased to produce more patches.
>
> Anyway...
>
> As an experiment when using, say, the "rad_def" Radiosity_Fast entry (which has
> a minimum_reuse value of 0.025), add a maximum_reuse there of 0.026. And greatly
> increase the 'count' value. It will be a slow render, so maybe pick out a
> smaller section of the image to test (and turn off AA). I can't predict what the
> results will be, but this *might* improve the results.
>
> BTW: In your image post, it looks like some of the objects' colors might be
> exceeding <1.0,1.0,1.0>, perhaps due to the combination of lights used. This
> could be a reason for some of the rad artifacts. Try decreasing the objects'
> diffuse values a bit, so that nothing in the scene produces a max color
> brightness exceeding 1.0. It will probably be a guessing game of trial and error
> ;-)
I have started doing some of the trial and error and have noted a few things as
I start to learn how all of the available levers are related and affect the
image.
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 to get a decent error_bound/count combination while also eliminating
the artifacts.
Since most of the artifacts show up on my isosurfaces, and on very thin
cylinders, I am wondering if the extra radiosity rays are finding isosurface
"holes", similar to what happens when max_gradient is too small. The problem is
that I am not seeing any max_gradient warnings. When I render without
radiosity, the max_gradient seems to be fine and I get no warnings. When I bump
them up significantly for radiosity renderings, the warnings I get are that my
max_gradients are too high, yet I see the black splotches.
I am also seeing cases where the isosurface appears to be somewhat transparent
when rendered with radiosity, while it appears solid without. I had thought
this might be an error_bound issue, but even reducing error_bound to 0.06 or
smaller doesn't help.
I'll keep fumbling until I really understand how it all works.
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcastnet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > Looking through the "rad_def" include file, I see that all of the radiosity
> > entries there are missing a maximum_reuse value-- which means that it defaults
> > to 0.2 in all of the cases. That's a rather large value, and can produce some
> > large-sized splotches. (From the docs' explanations of the various rad settings,
> > and possibly from code examples I've seen there(?), the 'typical' spread between
> > minimun_reuse and maximum_reuse should(?) be approximately 1:13; I guess that's
> > a trade-off between quality and render speed. And the spread is also designed so
> > that large flat surfaces get the maximum value-- large smooth rad patches--
> > whereas curved surfaces or other 'non-flat' areas get smaller patches.
> >
> > Personally, I now like to use a *small* spread between min and max_reuse; it
> > kind of defeats the purpose of the render-speed trade-off, and produces patches
> > that are all of the same (smaller) size; but I like the higher-quality look,
> > especially if rad's count value is greatly increased to produce more patches.
> >
> > Anyway...
> >
> > As an experiment when using, say, the "rad_def" Radiosity_Fast entry (which has
> > a minimum_reuse value of 0.025), add a maximum_reuse there of 0.026. And greatly
> > increase the 'count' value. It will be a slow render, so maybe pick out a
> > smaller section of the image to test (and turn off AA). I can't predict what the
> > results will be, but this *might* improve the results.
> >
> > BTW: In your image post, it looks like some of the objects' colors might be
> > exceeding <1.0,1.0,1.0>, perhaps due to the combination of lights used. This
> > could be a reason for some of the rad artifacts. Try decreasing the objects'
> > diffuse values a bit, so that nothing in the scene produces a max color
> > brightness exceeding 1.0. It will probably be a guessing game of trial and error
> > ;-)
> I have started doing some of the trial and error and have noted a few things as
> I start to learn how all of the available levers are related and affect the
> image.
>
> 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 to get a decent error_bound/count combination while also eliminating
> the artifacts.
>
> Since most of the artifacts show up on my isosurfaces, and on very thin
> cylinders, I am wondering if the extra radiosity rays are finding isosurface
> "holes", similar to what happens when max_gradient is too small. The problem is
> that I am not seeing any max_gradient warnings. When I render without
> radiosity, the max_gradient seems to be fine and I get no warnings. When I bump
> them up significantly for radiosity renderings, the warnings I get are that my
> max_gradients are too high, yet I see the black splotches.
>
> I am also seeing cases where the isosurface appears to be somewhat transparent
> when rendered with radiosity, while it appears solid without. I had thought
> this might be an error_bound issue, but even reducing error_bound to 0.06 or
> smaller doesn't help.
>
> I'll keep fumbling until I really understand how it all works.
>
> -- Chris R.
After a lot of head scratching, I discovered that the wing transparency was
happening even with radiosity turned off. And the issue was that my bounding
box had coincident surfaces with the shape function for the wings. Once I
expanded the box by a small amount on all sides, the wings look solid once more.
I think I need a post-it note on my desk that says to look for coincident
surfaces first, before looking for more esoteric answers...
Back to the radiosity settings...
-- Chris R.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris R" <car### [at] comcastnet> 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
|
|
| |
| |
|
|
|
|
| |
|
|
