"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/ ]

Jeremy M. Praay <sla### [at] hotmailcom> wrote:
> I'm assuming that this is because radiosity uses some sort of random numbers 
> in the generation of the data.

  Nope. It's because the radiosity algorithm reuses the data calculated
so far. If you start from the middle of the image, there's no data from
the first half to be reused. This usually causes the illumination to
differ visibly.

-- 
#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 -

"Slime" <fak### [at] emailaddress> wrote in message 
news:41edfbd4$1@news.povray.org...
>> 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. =)

    I don't have any 'final' renders as yet, but I think I might be the only 
person to create three *heavy-ish* scenes for one comp this time around. I 
lost the first two...   :o/

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

  Heh... ;)  I've just aborted a 1pps image at 1280x1024... 18hrs, line 3...

  It took nearly 20 minutes to abort... (What's with that?)  :o(

  ~Steve~




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

>   Heh... ;)  I've just aborted a 1pps image at 1280x1024... 18hrs, line
3...

1280x1024... have you compensated for the non-4:3 aspect ratio? Just
checking since some people might not realize that 1280x1024 is not 4:3.

>   It took nearly 20 minutes to abort... (What's with that?)  :o(

Was it thrashing? It could have been trying to free memory.

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

"Slime" <fak### [at] emailaddress> wrote in message 
news:41edc6b2$1@news.povray.org...
>> 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.
>


Oops.  Got it.  That severely limits the usefulness of my suggestion.

-- 
Jeremy
www.beantoad.com

"Slime" <fak### [at] emailaddress> wrote in message 
news:41eebe50$1@news.povray.org...
>>   Heh... ;)  I've just aborted a 1pps image at 1280x1024... 18hrs, line
> 3...
>
> 1280x1024... have you compensated for the non-4:3 aspect ratio? Just
> checking since some people might not realize that 1280x1024 is not 4:3.
>
>>   It took nearly 20 minutes to abort... (What's with that?)  :o(
>
> Was it thrashing? It could have been trying to free memory.
>


I think it can only abort when it finishes rendering a pixel.  So in your 
case, it took about 20 minutes to render a pixel.  I'm probably commenting 
about something where I'm wrong again, but that never stops me from trying. 
My best guess is that this has to do with threaded execution.  The thread 
probably only checks the abort state after it finishes rendering a pixel.  I 
don't think POV 3.5 acted that way.

-- 
Jeremy
www.beantoad.com

"Slime" <fak### [at] emailaddress> wrote in message 
news:41edfbd4$1@news.povray.org...
>> 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. =)

Great to hear!

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

If it's not around 5 pps, then I need to turn up the radiosity settings. 
;-)

-- 
Jeremy
www.beantoad.com

"Slime" <fak### [at] emailaddress> wrote in message 
news:41eebe50$1@news.povray.org...

>>   It took nearly 20 minutes to abort... (What's with that?)  :o(
>
> Was it thrashing? It could have been trying to free memory.

   Not sure, but my little orange CPU light was going crazy, so I would 
guess that you're correct.


   ~Steve~


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