![](/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) |
I followed Kari Kivisalo's suggestions and rendered a 320*240 version of the
scene without ior, without normal and with both diffuse 0 and ambient 0. I
used save_file inside the radiosity block and then I reload the file as you
can see below:
radiosity {
pretrace_start 1
pretrace_end 1
count 400
nearest_count 8
error_bound 0.15
recursion_limit 3
low_error_factor 0.5
gray_threshold 0
minimum_reuse 0.015
brightness 2.5
adc_bailout 0.01/2
always_sample off
load_file "still_rad_data"
}
Well, the result isn't *perfect* (you can see several artifacts, esp on the
table planks and at the lowest edge of the room), but render time was much
more friendly.
The 320*240 image took 22 minutes to render, while the final version took
about 7 hours and 45 minutes (vs 3 days the other one would have taken).
Yet there are many aspects that puzzle me:
1) Why using load_file and always_sample off the render time is still much
slower than without radiosity?
2) Shouldn't you get the same results in spite of the settings used? (When
you're using load_file).
3) Why stopping and then resuming the render caused that discontinuity (with
pretrace_start 1, pretrace_end 1, load_file and always_sample off this
shoudn't occur)
4) What caused those artifacts on the table (there weren't artifacts in the
version rendered for saving data)?
IMO some bugs are involved here, esp. in the saving/loading process. Once I
have practised enough with C I will have a look to the code and find a
solution... but at the moment I'm too busy with my ultra-sofisticated
*Hello* programs :-)
TIA for those who will have the patient to answer all my questions,
--
Jonathan.
<Computer, kill Ned Flander...>
Post a reply to this message
Attachments:
Download 'rad.jpg' (71 KB)
Preview of image 'rad.jpg'
![rad.jpg](/povray.binaries.images/attachment/%3C3be532ca%40news.povray.org%3E/rad.jpg?ttop=443840&toff=10150&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 1) Why using load_file and always_sample off the render time is still much
> slower than without radiosity?
The rad illumination still has to be calculated from the rad samples.
> 2) Shouldn't you get the same results in spite of the settings used? (When
> you're using load_file).
Maybe, but the 15 years I have been using computer software have thought
me to be conservative when assuming anything about how they work. I don't
even believe the manuals. I have to see it. My instinct tells me to use
the same settings :)
> 3) Why stopping and then resuming the render caused that discontinuity (with
> pretrace_start 1, pretrace_end 1, load_file and always_sample off this
> shoudn't occur)
Same reason as 1).
_____________
Kari Kivisalo
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Tony[B]
Subject: Re: Radiosity & Glass take 2: load and save file
Date: 4 Nov 2001 09:16:03
Message: <3be54da3@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Well, the result isn't *perfect* (you can see several artifacts, esp on
the
> table planks and at the lowest edge of the room), but render time was much
> more friendly.
That's an amazing trick! I'm going to have to try it myself... :)
> 3) Why stopping and then resuming the render caused that discontinuity
(with
> pretrace_start 1, pretrace_end 1, load_file and always_sample off this
> shoudn't occur)
As far as I know, only Gilles doesn't have that problem. It seems like
everyone else does. Perhaps POV is rebelling because we are not worthy. :b
> 4) What caused those artifacts on the table (there weren't artifacts in
the
> version rendered for saving data)?
Looks like reflection spots. Increase max_trace_level.
> Once I have practised enough with C I will have a look to the code
> and find a solution... but at the moment I'm too busy with my ultra-
> sofisticated *Hello* programs :-)
Ditto, except that I'm skipping C and going into C++, since that's what 4.0
will be written in. Hopefully, I will be familiar enough with the keywords
and how they work together by the time it's in development to be able to
stare at it and follow what the pros are doing. Not that I will know enough
about the math and physics and advanced programming topics behind raytracing
to actually contribute, but at least I will be able to watch and not get
lost. I hope. :)
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) |
Tony[B] wrote:
> That's an amazing trick! I'm going to have to try it myself... :)
Credit to Kari.
> As far as I know, only Gilles doesn't have that problem.
Neither I do (with pretrace_start 1 and pretrace_end 1). Only with load_file
this problem occurred.
> Looks like reflection spots. Increase max_trace_level.
This could be right if extra-samples were taken in the final step, which is
not the case. As I said, I'm using load_file and always_sample off so
POV-Ray should have used the precalculated data (where those spots were not
there).
> Ditto, except that I'm skipping C and going into C++, since that's what
4.0
> will be written in. Hopefully, I will be familiar enough with the keywords
> and how they work together by the time it's in development to be able to
> stare at it and follow what the pros are doing. Not that I will know
enough
> about the math and physics and advanced programming topics behind
raytracing
> to actually contribute, but at least I will be able to watch and not get
> lost. I hope. :)
I'm gonna study C++ next year. This year only C is required for my exam, and
I have to say that Deitel & Deitel are very good teachers... :-)
--
Jonathan.
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) |
Kari Kivisalo wrote:
> > 2) Shouldn't you get the same results in spite of the settings used?
(When
> > you're using load_file).
>
> Maybe, but the 15 years I have been using computer software have thought
> me to be conservative when assuming anything about how they work. I don't
> even believe the manuals. I have to see it. My instinct tells me to use
> the same settings :)
I mean, if I use pretrace_start 0.08 and pretrace_end 0.004 I get the mosaic
preview. Shouldn't it be redundant?
> > 3) Why stopping and then resuming the render caused that discontinuity
(with
> > pretrace_start 1, pretrace_end 1, load_file and always_sample off this
> > shoudn't occur)
>
> Same reason as 1).
But I did stop and resume other radiosity scenes (with pretrace_start 1 and
pretrace_end 1) without any problems... I think the problem here has
something to do with reloading data or always_sample off that doesn't really
work.
--
Jonathan.
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) |
JRG wrote:
>
> I mean, if I use pretrace_start 0.08 and pretrace_end 0.004 I get the mosaic
> preview. Shouldn't it be redundant?
I ment the other rad settings.
> > > 3) Why stopping and then resuming the render caused that discontinuity
> (with
> > > pretrace_start 1, pretrace_end 1, load_file and always_sample off this
> > > shoudn't occur)
> >
> > Same reason as 1).
>
> But I did stop and resume other radiosity scenes (with pretrace_start 1 and
> pretrace_end 1) without any problems... I think the problem here has
> something to do with reloading data or always_sample off that doesn't really
> work.
It works but when calculating the illumination from saved samples
different samples are used when rendering partial image. It could
be that there are samples just above the border which are used
for the top part of the image but not used when starting below
the border.
_____________
Kari Kivisalo
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) |
Kari Kivisalo
> It works but when calculating the illumination from saved samples
> different samples are used when rendering partial image. It could
> be that there are samples just above the border which are used
> for the top part of the image but not used when starting below
> the border.
OK, this would explain a discontinuity of some sort. But here the bottom
part of the image is noticebly brighter than the top one. How come?
--
Jonathan.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Tony[B]
Subject: Re: Radiosity & Glass take 2: load and save file
Date: 4 Nov 2001 15:25:38
Message: <3be5a442@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Neither I do (with pretrace_start 1 and pretrace_end 1). Only with
load_file
> this problem occurred.
Oh, right... Hmm...
> This could be right if extra-samples were taken in the final step, which
is
> not the case. As I said, I'm using load_file and always_sample off so
> POV-Ray should have used the precalculated data (where those spots were
not
> there).
That has to be a bug of some sort... Nathan?
> I'm gonna study C++ next year. This year only C is required for my exam,
and
> I have to say that Deitel & Deitel are very good teachers... :-)
I'm also using a book by them! I don't much like their teaching of C++, but
after reading the book about 3-4 times, it's all becoming clearer.
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) |
JRG wrote:
>
> 4) What caused those artifacts on the table (there weren't artifacts in the
> version rendered for saving data)?
What was max_trace_level? If it was still 4 it might not be enough.
_____________
Kari Kivisalo
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: blessing
Subject: Re: Radiosity & Glass take 2: load and save file
Date: 4 Nov 2001 23:31:32
Message: <3be61624@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thats the most realistic rendering I've ever seen.
Great job!!
Gary
JRG <jrg### [at] hotmail com> wrote in message news:3be532ca@news.povray.org...
> I followed Kari Kivisalo's suggestions and rendered a 320*240 version of
the
> scene without ior, without normal and with both diffuse 0 and ambient 0. I
> used save_file inside the radiosity block and then I reload the file as
you
> can see below:
>
> radiosity {
> pretrace_start 1
> pretrace_end 1
> count 400
> nearest_count 8
> error_bound 0.15
> recursion_limit 3
> low_error_factor 0.5
> gray_threshold 0
> minimum_reuse 0.015
> brightness 2.5
> adc_bailout 0.01/2
> always_sample off
> load_file "still_rad_data"
> }
>
> Well, the result isn't *perfect* (you can see several artifacts, esp on
the
> table planks and at the lowest edge of the room), but render time was much
> more friendly.
> The 320*240 image took 22 minutes to render, while the final version took
> about 7 hours and 45 minutes (vs 3 days the other one would have taken).
> Yet there are many aspects that puzzle me:
>
> 1) Why using load_file and always_sample off the render time is still much
> slower than without radiosity?
> 2) Shouldn't you get the same results in spite of the settings used? (When
> you're using load_file).
> 3) Why stopping and then resuming the render caused that discontinuity
(with
> pretrace_start 1, pretrace_end 1, load_file and always_sample off this
> shoudn't occur)
> 4) What caused those artifacts on the table (there weren't artifacts in
the
> version rendered for saving data)?
>
> IMO some bugs are involved here, esp. in the saving/loading process. Once
I
> have practised enough with C I will have a look to the code and find a
> solution... but at the moment I'm too busy with my ultra-sofisticated
> *Hello* programs :-)
> TIA for those who will have the patient to answer all my questions,
>
> --
> Jonathan.
> <Computer, kill Ned Flander...>
>
>
>
>
>
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |