Warp wrote:
> 
>   At least in the past using +C with radiosity was not a problem.
>   If it's a problem currently, it's a bug, imho.
> 

It usually is no problem but there are technical differences - not all 
data stored in memory during a radiosity render is also written to the file.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Jeremy M. Praay <jer### [at] questsoftwarecom> wrote:
> But...  If I recall correctly, using +C with radiosity was a problem in 3.5. 
> Is that what you mean?

  No. Using +C with radiosity was precisely not a problem with 3.5. If it
is a problem with the current version, it's a bug.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Slime <fak### [at] emailaddress> wrote:
> Yeah, that's what I was referring to. Without a save_file and load_file, I
> would be surprised if the horizontal line could be avoided, since the second
> time through, POV-Ray can't have the radiosity data from the first time
> through.

  Incorrect. Interrupted rendering and radiosity was never a problem with
POV-Ray. Haven't you noticed how POV-Ray saves the radiosity data in a file
during rendering precisely for the purpose of supporting interrupted renders?

  The save_file and load_file features were not innovations. They simply
gave more user control to the file which POV-Ray was already creating.

> Of course, it *works*, in that the image continues to render from where it
> left off, but the results can be bad.

  They were bad only if you deleted the temporary radiosity file POV-Ray
had created. Else it was just ok.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Christoph Hormann <chr### [at] gmxde> wrote:
> It usually is no problem but there are technical differences - not all 
> data stored in memory during a radiosity render is also written to the file.

  If that is so, then imho it should be fixed.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:41ebaf49@news.povray.org...
> Jeremy M. Praay <jer### [at] questsoftwarecom> wrote:
>> But...  If I recall correctly, using +C with radiosity was a problem in 
>> 3.5.
>> Is that what you mean?
>
>  No. Using +C with radiosity was precisely not a problem with 3.5. If it
> is a problem with the current version, it's a bug.
>


I tried to prove you wrong (with version 3.5).  I set count to various 
values (all the way down to 1) in a simple radiosity scene.  I started and 
stopped it repeatedly but it worked just fine every time.  I even stopped 
and restarted POV-Ray, and it still worked just fine.  I'm going to assume 
that you are correct, and that I was remembering something else, such as 
splitting-up a render across different machines.

-- 
Jeremy
www.beantoad.com

>   Incorrect. Interrupted rendering and radiosity was never a problem with
> POV-Ray. Haven't you noticed how POV-Ray saves the radiosity data in a
file
> during rendering precisely for the purpose of supporting interrupted
renders?


No, I hadn't. Cool!

I vaguely recall seeing a scene, I think posted in these newsgroups, where
someone was complaining that +C wasn't working with their image and it had
the problem I described. It's possible that some people (including myself)
accidentally concluded that radiosity was the cause. That was a long time
ago though, so either it was a separate bug or just the fault of the person
making the image.

 - Slime
 [ http://www.slimeland.com/ ]

Jeremy M. Praay <jer### [at] questsoftwarecom> wrote:
> I tried to prove you wrong (with version 3.5).  I set count to various 
> values (all the way down to 1) in a simple radiosity scene.  I started and 
> stopped it repeatedly but it worked just fine every time.  I even stopped 
> and restarted POV-Ray, and it still worked just fine.  I'm going to assume 
> that you are correct, and that I was remembering something else, such as 
> splitting-up a render across different machines.

  When you stopped rendering, did you check if an extra file had
appeared in the same directory where the scene was? (Or it might appear
in the same directory as the final image is written; I don't really know
which.) It's the radiosity cache file (it is removed after the rendering
ends).

  But certainly if you render half of the image and then the other half
as a separate render (with start/end row options) you will most probably
get a visible line.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:41ed08c4@news.povray.org...
>
>  But certainly if you render half of the image and then the other half
> as a separate render (with start/end row options) you will most probably
> get a visible line.
>


I'm assuming that this is because radiosity uses some sort of random numbers 
in the generation of the data.  If that's the case, it might be a nifty 
feature if the user could supply a "radiosity_seed Float" to ensure that it 
used the same random seed.  Otherwise, the only alternative of which I am 
aware, is to create the radiosity data in advance of the actual rendering.

Just a thought.

-- 
Jeremy
www.beantoad.com

> I'm assuming that this is because radiosity uses some sort of random
numbers
> in the generation of the data.  If that's the case, it might be a nifty
> feature if the user could supply a "radiosity_seed Float" to ensure that
it
> used the same random seed.

Having the same random seed wouldn't mean you have the same data that was
calculated in the first rendering. To get that, you'd have to rerender from
scratch (using the seed) - which defeats the purpose.

 - Slime
 [ http://www.slimeland.com/ ]

> Currently doing what I hope will be my final, final render.  :-)

I have also managed to put together a scene which I will submit (thank
goodness for the deadline extension). I have at least four "final" renders
in my image folder now. =)

Thankfully, unlike you crazy people, I refuse to render anything slower than
5 pps. Right now I'm going at about 30 or so.

 - Slime
 [ http://www.slimeland.com/ ]