|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is a section of a scene using almost exclusively radiosity-based lighting,
as rendered by:
(a) POV-ray 3.6.1c using fairly high quality radiosity settings, and a separate
pretrace render with save_file/load_file (i.e. doing pretrace and final render
in separate runs of POV-ray) which I found to smoothen out quite a lot of
artifacts in the picture. The main shot was taken twice the resolution shown
here.
(b) POV-ray 3.6.1c using exactly(!) the same settings as (a), but without using
the save_file/load_file (i.e. pretrace and final render were done in the same
run) and the resolution you see here.
(c) POV-ray 3.7.0.beta.29, using exactly same setup as for (b).
(d) a modified version of POV-ray 3.7.0.beta.29 (my current status for the
radiosity bugfixing work).
The bottom row shows the (somewhat enhanced) difference between the respective
shot and (a) (which I'd expect to come closest to reality).
It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
that for some reasons it gives exceptionally bad results on the left side of
the pedestal's top.
(c) and (d) aren't too much apart - but for some reasons I don't yet understand,
(d) renders a lot faster (factor 3!!!), so it looks like I did *something*
right.
This also shows that 3.6.1 radiosity is far from perfect, and it's probably not
a good idea to take it as a reference after all for the 3.7 development.
Post a reply to this message
Attachments:
Download 'fishbowl.jpg' (168 KB)
Preview of image 'fishbowl.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rats! If I'd known that the quality of the radiosity in beta 29 were so poor I
would have rendered my 56 frame scene in 3.6.1. At least beta 29 is much
faster...
-Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"SharkD" <nomail@nomail> wrote:
> Rats! If I'd known that the quality of the radiosity in beta 29 were so poor I
> would have rendered my 56 frame scene in 3.6.1. At least beta 29 is much
> faster...
>
> -Mike
I has good news for you...
Post a reply to this message
Attachments:
Download 'lol.jpg' (107 KB)
Preview of image 'lol.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
> that for some reasons it gives exceptionally bad results on the left side of
> the pedestal's top.
What bad results? You're talking about (a), right?
> (c) and (d) aren't too much apart - but for some reasons I don't yet understand,
> (d) renders a lot faster (factor 3!!!), so it looks like I did *something*
> right.
That's great!
> This also shows that 3.6.1 radiosity is far from perfect
Why? And, hey, while you're messing around with it, how about getting radiosity
"count" limit way up? ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> "clipka" <nomail@nomail> wrote:
> > It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
> > that for some reasons it gives exceptionally bad results on the left side of
> > the pedestal's top.
>
> What bad results? You're talking about (a), right?
No, to me (a) looks more realistic than all the others - I'm talking about (b).
And from the process of how it was generated, I must assume that it took more
samples than the others.
> > This also shows that 3.6.1 radiosity is far from perfect
>
> Why?
'cuz it gives you significantly different results depending on whether you save
and later re-load the whole smash. Taking some more samples should reduce
artifacts, but not change anything dramatically.
> And, hey, while you're messing around with it, how about getting
> radiosity "count" limit way up? ;)
Not so high on my agenda. It's a bit "tricksy" anyway: It's not like POV-ray
would just shoot so many random rays - in that case there wouldn't be any
reason for the "hard deck" of 1600 samples. Instead, POV-ray picks the first N
rays from a hard-coded sequence of 1600 sampling directions.
MegaPOV has a mechanism to supply your own sampling directions, and thereby
overcome that limitation. But I'd rather go for figuring out how the original
sampling directions were chosen, and implement an algorithm that re-computes
the very same sequence when POV initializes the radiosity code. Or a larger
one.
Using truly random directions is not an option, because producing (pseudo-)
random numbers is a comparatively costly thing, converting them to suitably
distributed directions requires a bit of trigonometric functions (highly
costly!), and would actually need a higher count to get the same quality.
An interesting side note though: Did you know that you actually don't get the
specified count for all your samples? Instead, the effective count decreases
drastically with trace depth. In fact all your quality settings do.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
> > "clipka" <nomail@nomail> wrote:
> > > It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
> > > that for some reasons it gives exceptionally bad results on the left side of
> > > the pedestal's top.
> >
> > What bad results? You're talking about (a), right?
>
> No, to me (a) looks more realistic than all the others - I'm talking about (b).
Ok. (a) looked the best, obviously, so I thought it was strange of you to be
dissing it.
> > > This also shows that 3.6.1 radiosity is far from perfect
> >
> > Why?
>
> 'cuz it gives you significantly different results depending on whether you save
> and later re-load the whole smash. Taking some more samples should reduce
> artifacts, but not change anything dramatically.
Are you sure you used the same settings for both? If you don't write down
concrete values, default values are used and if one scene sets a value for an
attribute and the other doesn't, the default value may indeed have great
impact.
With my own tests it's the contrary: a single radiosity pass always gives the
best results...
> An interesting side note though: Did you know that you actually don't get the
> specified count for all your samples? Instead, the effective count decreases
> drastically with trace depth. In fact all your quality settings do.
Hmm, I expected it to be an upper limit, yes. The trace you're talking about is
from the pretrace step or is the "bounces" number?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> Are you sure you used the same settings for both?
Definitely.
> With my own tests it's the contrary: a single radiosity pass always gives the
> best results...
Interestingly, that scene has been the only one so far that really worked with
the save & reload approach.
> > An interesting side note though: Did you know that you actually don't get the
> > specified count for all your samples? Instead, the effective count decreases
> > drastically with trace depth. In fact all your quality settings do.
>
> Hmm, I expected it to be an upper limit, yes. The trace you're talking about is
> from the pretrace step or is the "bounces" number?
I'm taking about the "bounces" here.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> This is a section of a scene using almost exclusively radiosity-based lighting,
> as rendered by:
>
> (a) POV-ray 3.6.1c using fairly high quality radiosity settings, and a separate
> pretrace render with save_file/load_file (i.e. doing pretrace and final render
> in separate runs of POV-ray) which I found to smoothen out quite a lot of
> artifacts in the picture. The main shot was taken twice the resolution shown
> here.
Apologies in advance if I'm confused about something: When *loading* the rad
data, did you use the accepted 'witchcraft' thing of setting both
pretrace_start and pretrace_end to 1 (along with always_sample off)? Or did you
run the loaded data with the exact same rad settings that you saved it with? I'm
curious if either one or the other made any visual difference (that is, any
difference from single-pass radiosity.)
BTW, *funny* cat image!
Ken W.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> Apologies in advance if I'm confused about something: When *loading* the rad
> data, did you use the accepted 'witchcraft' thing of setting both
> pretrace_start and pretrace_end to 1 (along with always_sample off)? Or did you
> run the loaded data with the exact same rad settings that you saved it with? I'm
> curious if either one or the other made any visual difference (that is, any
> difference from single-pass radiosity.)
Back then I wasn't using witchcraft yet, just ordinary magic - so of course I
used really identical settings.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |