 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi folks,
I'm developing an indoor radiosity scene, and after going through a couple
of tutorials, the documentation and fiddling with the parameters, I've
decided I have a problem.
The lighting levels in the room are heavily affected by camera position, and
also to a lesser degree by bizarre things like +w/+h.
The light is coming from an ambient sky sphere and a light_source sun. They
are quite far away (10e6 units, oh and one pov unit = 1 m in my scene).
There are double glasses in the windows (two, a big one facing south, a
smaller facing east). Sun is in the southen sky. There are various items
in the room.
Now, I can get good pictures from the model, but it's always after some
tuning with brightness and/or exposure. Basically I can have a good set of
parameters for one camera, but if I move it even a little bit (10cm in my
model is enough) the room can go very dark or very bright.
What am I doing wrong? I thought that the one thing that doesn't affect
radiosity is camera position.
I'm using a rather high recursion_limit of 9, because I figure I 'loose'
four bounces for the windows only. Max_sample is -1, count 15-30,
error_bound 1.0, low_error_level ~0.8 (it's fast, and the results are good
after correcting for brightness), minimum_reuse <= 0.009, nearest_count 10.
The same problem exists with v3.5, v3.6.1 and MegaPov 1.1. I'm using
exposure because it's great, but with respect to my problem it didn't
introduce anything but a second parameter for controlling the light
dynamics (the first one was brightness). This is the first scene where I'm
really relying on radiosity for illumination, so I tend to think that I'm
just missing something somewhere. Any help much appreciated!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
jute wrote:
> [...]
>
> What am I doing wrong? I thought that the one thing that doesn't affect
> radiosity is camera position.
Without showing the scene you will not very likely get a useful reply.
> I'm using a rather high recursion_limit of 9,
Such a high recursion limit is most likely a waste of time.
> because I figure I 'loose'
> four bounces for the windows only.
What is that supposed to mean?
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmx de> wrote:
>
> > Without showing the scene you will not very likely get a useful reply.
I know ... I could share the source in private, put as it is likely to be my
competition entry, I'm unwilling to share it in public before the deadline.
> > I'm using a rather high recursion_limit of 9,
>
> Such a high recursion limit is most likely a waste of time.
That's what I'd learned from the grapevine, but it works in my scene.
In fact, before I pumped it up the back of my room was having a night when
close to windows it was a bright sunshine. Anyway it doesn't slow the
rendering very much, hardly noticeably; I'd guess that to be due to
adc_bailout, but then I couldn't explain why it brightens up the room!
I really, really, /really/ am going to sit down with radiosit.cpp once
I can get my mind off modelling this scene! :)
> > because I figure I 'loose' four bounces for the windows only.
>
> What is that supposed to mean?
Rays pass through four surfaces (two per window) of differing IOR on their
way out; that's four levels for ray tracing, and I'm assuming it's also
four radiosity recursions. This is not so?
--
jussi.kantola
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
jute nous apporta ses lumieres ainsi en ce 2004-09-27 17:17... :
>Christoph Hormann <chr### [at] gmxde> wrote:
>
>
>>>Without showing the scene you will not very likely get a useful reply.
>>>
>>>
>
>I know ... I could share the source in private, put as it is likely to be my
>competition entry, I'm unwilling to share it in public before the deadline.
>
>
>
>>>I'm using a rather high recursion_limit of 9,
>>>
>>>
>>Such a high recursion limit is most likely a waste of time.
>>
>>
>
>That's what I'd learned from the grapevine, but it works in my scene.
>In fact, before I pumped it up the back of my room was having a night when
>close to windows it was a bright sunshine. Anyway it doesn't slow the
>rendering very much, hardly noticeably; I'd guess that to be due to
>adc_bailout, but then I couldn't explain why it brightens up the room!
>
>I really, really, /really/ am going to sit down with radiosit.cpp once
>I can get my mind off modelling this scene! :)
>
>
>
>>>because I figure I 'loose' four bounces for the windows only.
>>>
>>>
>>What is that supposed to mean?
>>
>>
>
>Rays pass through four surfaces (two per window) of differing IOR on their
>way out; that's four levels for ray tracing, and I'm assuming it's also
>four radiosity recursions. This is not so?
>
>
>--
>jussi.kantola
>
What it does, is add to the max_trace_level count, whitch also have an
effect when using radiosity. Maybe it's set to low, 2 steps for the
first pane, 2 for the second, 1 for any background/radiosity
light-object already make 5 = to the default value. Any surface in your
room then push it to 6 and more. I'd try a max_trace_level of 14 or a
little more, then look in the post render statistics and increase it
some more if that value have been reached. Also, look if it change when
you move the camera.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
> four bounces for the windows only. Max_sample is -1, count 15-30,
> error_bound 1.0, low_error_level ~0.8 (it's fast, and the results are good
> after correcting for brightness), minimum_reuse <= 0.009, nearest_count 10.
I think, with such a low count you won't get any kind of reliable results, the number
of samples is just too low. And I do think (without being an expert on that matter)
that changing the location of your camera (and even the image resolution, as you
described) will lead to a different set of samples, and possibly a different result.
You could try increasing the number of pretrace passes, maybe that will help a bit.
Are you just using radiosity to brighten up the room? For that, some well placed low
intensity shadowless light sources would probably do the job better and a lot faster.
In my experience, to get good looking shadows with radiosity, especially on small
objects, you need a very high sample count and low error bound. I've experimented with
that quite a bit myself, and when I get to the point that it's starting to look good
and fairly realistic, it usually becomes so slow that I lose interest ;)
Artur.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"A.Brinkmann" <arb### [at] gmxde> wrote:
>
> I think, with such a low count you won't get any kind of reliable results,
> the number of samples is just too low. And I do think (without being an
> expert on that matter) that changing the location of your camera (and even
> the image resolution, as you described) will lead to a different set of
> samples, and possibly a different result. You could try increasing the number
> of pretrace passes, maybe that will help a bit.
I have in fact suspected that when I go to higher counts (200+) the lighting
gets more stable. It's just that I haven't rendered very many images above
count 80, simply because it is so slow and I'm still in the process of
constantly adding or changing something. Reading your post, I'm suddenly
convinced that this is where my problem lies. I'll do some tests and follow
up on them.
My pretraces are 0.2 -> 0.01 or 0.005. I don't use load_file, it always
gets me some artefacts (i use pretraces 1 and always_sample off when
loading) and besides I'm constantly updating the scene contents so it
wouldn't work anyways.
> Are you just using radiosity to brighten up the room?
Yes.
> For that, some well placed low intensity shadowless light sources would
> probably do the job better and a lot faster.
I've thought about this, but as I'm modelling a real-world room I want to
try to have it working with the same lighting that is available in reality.
And I do have the sun light_source (damn, I even have a brightening around
sun in the sky sphere. it's probably doing nothing, lighting-wise, but it
looks nice whenever I happen to render a scene that has the sun
visible...). Overall I'm very happy with the current results -- and I
haven't even tried HDRI yet!
> it's starting to look good and fairly realistic, it usually becomes so slow> that I
lose interest ;)
I hear you ;-)
--
jussi.kantola
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"A.Brinkmann" <arb### [at] gmxde> wrote:
> I think, with such a low count you won't get any kind of reliable results,
> the number of samples is just too low. And I do think (without being an
I ran some tests and while the results remain inconclusive, it seems like my
biggest concern is indeed the low sample count. There's also a noticeable
difference between the halton sample set and Thies Heidecke's 'sunflower'
set that I've been using for the last week -- sunflower gives a lot
brighter (I'd say +0.2 brightness) image with low count. This is not a
drawback for the sample set, at least now that I know about it.
However, the +w/+h problem clearly manifests itself only with low counts.
The problem of my testing was that I was somewhat unable to reproduce the
symptoms with the camera position I used, even as just yesterday I was
rendering images from the same position and the problem manifested itself
profoundly.
What I've come to believe now is that I'm simply making so many simultaneous
changes to the scene description between renders that I can't really keep
track of them, and it happens that I've changed something even when I
believe I haven't. In other words, I'm willing to rest this case at least
until I get time to do some *proper* tests and be certain if there really
is something fishy going on. Besides, I'm getting rather good at
pre-guessing good values for brightness & exposure :D
Now, where was that intersection { ...
--
jussi.kantola
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jute" <nomail@nomail> wrote in message
news:web.4159ba8d8cfd44a0b2800eda0@news.povray.org...
> "A.Brinkmann" <arb### [at] gmxde> wrote:
> > I think, with such a low count you won't get any kind of reliable
results,
> > the number of samples is just too low. And I do think (without being an
>
> I ran some tests and while the results remain inconclusive, it seems like
my
> biggest concern is indeed the low sample count. There's also a noticeable
> difference between the halton sample set and Thies Heidecke's 'sunflower'
> set that I've been using for the last week -- sunflower gives a lot
> brighter (I'd say +0.2 brightness) image with low count. This is not a
> drawback for the sample set, at least now that I know about it.
>
> However, the +w/+h problem clearly manifests itself only with low counts.
>
> The problem of my testing was that I was somewhat unable to reproduce the
> symptoms with the camera position I used, even as just yesterday I was
> rendering images from the same position and the problem manifested itself
> profoundly.
>
> What I've come to believe now is that I'm simply making so many
simultaneous
> changes to the scene description between renders that I can't really keep
> track of them, and it happens that I've changed something even when I
> believe I haven't. In other words, I'm willing to rest this case at least
> until I get time to do some *proper* tests and be certain if there really
> is something fishy going on. Besides, I'm getting rather good at
> pre-guessing good values for brightness & exposure :D
>
> Now, where was that intersection { ...
>
> --
> jussi.kantola
>
>
Not sure if you resolved the problem or not, but when reading through I was
a bit startled by your settings. In my experience, final scenes rarely can
use less than 150 samples (this is highly dependant on the error_bound).
Also, when doing a test render for, I drop nearest count to 5, but when
testing the radiosity, I move it to at least 15 or it's final setting of 20.
I am very curious about this scene, so far I have never required above a
recursion level of 5. If time constraints allow, maybe you can try tracing
with a lower recursion level and higher settings? A typical radiosity block
for me in late stages of radiosity tuning looks like:
#local do_rad = 1;
global_settings{
#if(do_rad)
radiosity{
pretrace_start 0.080
pretrace_end 0.005
count 200
nearest_count 20
error_bound 1 // highly scene dependant!
recursion_limit 4
low_error_factor .5
gray_threshold 0.75
minimum_reuse 0.0015
brightness .95
adc_bailout 0.01/2
normal on
//media on
//save_file "file_name"
//load_file "file_name"
always_sample off
//max_sample 1.0
}
#end
}
HTH
Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jute" <nomail@nomail> schrieb im Newsbeitrag
news:web.415865be6aa6ed1cf834c8120@news.povray.org...
> Hi folks,
Hi,
i think the problem is, that radiosity sometimes misses
your sun when taking radiosity-samples and sometimes it
hits your sun. The problem is the low count-value.
the count-value determines the number of sample-rays that
are shot for each radiosity-calculation in random
directions of the hemisphere. Each ray has to 'observe'
a part of the hemisphere that gets larger the lower
your 'count' is. If your sun has a small solid angle
when viewed from your room it's possible that it falls
between two (or more) samplerays and therefore is
completely missing in the calculation. So you should
choose the count-value high enough that no significant
ambient lightsources are missed in the sampling.
A good rule of thumb is:
count >= 3*(r/R)^2
where r is the distance of the lightsource to the lit
area and R is the radius of the (sphere-shaped)
lightsource.
So if in your example you want to model the sun in POV
realistically you should use a minimum count of
3*(1,5*10^11m / 7*10^8m)^2 = 140000
So it's rather utopistic to realize that in POV-Ray...
Perhaps it's better to use a pointlight to make the
sunlight and just use a small ambient-value like 1
to let your sun appear reasonable bright.
I hope i didn't disappoint you too much..
Thies
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thies Heidecke" <h3i### [at] gmxnet> wrote:
>
> i think the problem is, that radiosity sometimes misses
> your sun when taking radiosity-samples and sometimes it
> hits your sun.
Yes, I expected this before starting the whole thread. And I guess my
fresnel windows are making the situation worse, as many of the samples will
hit the glass in such an angle that they get reflected back in to the room
even when I'm not looking at the windows. Which of course is as it should
be, but I *have* been thinking of a pass_through for radiosity :)
> A good rule of thumb is:
> count >= 3*(r/R)^2
Thanks!
> Perhaps it's better to use a pointlight to make the
> sunlight and just use a small ambient-value like 1
> to let your sun appear reasonable bright.
My sun is just a point source, no looks_like, instead I've got a cylindrical
pigment intersecting the sky sphere in sun's direction. I really can't
justify this design, probably it was just a way of doing something unusual
on the day I created it. And it doesn't look *hopelessly* ugly! :)
--
jussi.kantola
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
