![](/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) |
ron### [at] povray org (Ron Parker) wrote in
<slr### [at] linux parkerr fwi com>:
>On 28 Jun 2000 18:40:05 -0400, daishi wrote:
>>okay, so do it by line insted of by tile. send the first 10 lines to
>>one comp, next 10 to another, etc. only problem you might run into is
>>reassembling the images in the right order. pov-ray already supports
>>this with its resume feature, just no one has written a way to do it
>>distributedly
>
>Same problem. Believe us, we've actually thought about this problem and
>it's not as simple as you think. (Why do I find myself saying that more
>and more these days?)
>
why won't it work? does pov-ray do some kind of image analysis when it
resumes an image? I've done this with huge renders (say 10 lines one day,
another 10 lines the next, etc) and I haven't had any problems
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) |
daishi wrote:
>
> ron### [at] povray org (Ron Parker) wrote in
> <slr### [at] linux parkerr fwi com>:
>
> >On 28 Jun 2000 18:40:05 -0400, daishi wrote:
> >>okay, so do it by line insted of by tile. send the first 10 lines to
> >>one comp, next 10 to another, etc. only problem you might run into is
> >>reassembling the images in the right order. pov-ray already supports
> >>this with its resume feature, just no one has written a way to do it
> >>distributedly
> >
> >Same problem. Believe us, we've actually thought about this problem and
> >it's not as simple as you think. (Why do I find myself saying that more
> >and more these days?)
> >
>
> why won't it work? does pov-ray do some kind of image analysis when it
> resumes an image? I've done this with huge renders (say 10 lines one day,
> another 10 lines the next, etc) and I haven't had any problems
If I understand things correctly you don't get the same random seed
every time
you start a render, this leads to the images not fitting together as
nice as
they should, this is very noticable if you are using radiosity. Since
povray
doesn't store the seed it will not be able to make your scene perfect,
if you
are using just antialiasing you might not see it, but try to do some
radiosity
and you should most probably get a somewhat noticable line where you
halted the
rendering, and then resumed.
/Peter Toneby
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) |
woo### [at] acc umu se wrote in <395A8AF1.91D7229D@acc.umu.se>:
>daishi wrote:
>>
>> ron### [at] povray org (Ron Parker) wrote in
>> <slr### [at] linux parkerr fwi com>:
>>
>> >On 28 Jun 2000 18:40:05 -0400, daishi wrote:
>> >>okay, so do it by line insted of by tile. send the first 10 lines to
>> >>one comp, next 10 to another, etc. only problem you might run into
>> >>is reassembling the images in the right order. pov-ray already
>> >>supports this with its resume feature, just no one has written a way
>> >>to do it distributedly
>> >
>> >Same problem. Believe us, we've actually thought about this problem
>> >and it's not as simple as you think. (Why do I find myself saying
>> >that more and more these days?)
>> >
>>
>> why won't it work? does pov-ray do some kind of image analysis when it
>> resumes an image? I've done this with huge renders (say 10 lines one
>> day, another 10 lines the next, etc) and I haven't had any problems
>
>If I understand things correctly you don't get the same random seed
>every time
>you start a render, this leads to the images not fitting together as
>nice as
>they should, this is very noticable if you are using radiosity. Since
>povray
>doesn't store the seed it will not be able to make your scene perfect,
>if you
>are using just antialiasing you might not see it, but try to do some
>radiosity
>and you should most probably get a somewhat noticable line where you
>halted the
>rendering, and then resumed.
>
>/Peter Toneby
>
I'll try doing a radoisity test, but I just did a test rendering with my
method and everything rejoined fine. renderered the bottom third of my
image, then the first third, then the second. I didn't have any problems
joining them back together
if its just a matter of saving the random seed, I don't think that would be
a major obstacle. or maybe just have the ability so the user can define the
seed in their scene ahead of time.
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) |
Ron Parker wrote:
> 9x is still dependent on a lot of 16-bit code, which is to a certain extent
> cooperative. 16-bit apps running on 9x cooperate with each other, and the
> entire 16-bit subsystem (if you can call it that) is one process from the
> point of view of the 32-bit scheduler.
That's pretty much what I've heard, too.
-Mark Gordon
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) |
well I just ran my radisoity test. and yea I can see some problems when I
rejoined the image. it really depends on the type of scene though, as the
only part of the image that had a problem was some reflective stuff, I
would imagine a scene with little radisoity would join back up without
problems
so I guess all that needs to be done is have the ability to define the seed
value ahead of time, or save the seed....
das### [at] x-press net (daishi) wrote in
<8F61C58CBdashixpressnet@204.213.191.228>:
>woo### [at] acc umu se wrote in <395A8AF1.91D7229D@acc.umu.se>:
>
>>daishi wrote:
>>>
>>> ron### [at] povray org (Ron Parker) wrote in
>>> <slr### [at] linux parkerr fwi com>:
>>>
>>> >On 28 Jun 2000 18:40:05 -0400, daishi wrote:
>>> >>okay, so do it by line insted of by tile. send the first 10 lines
>>> >>to one comp, next 10 to another, etc. only problem you might run
>>> >>into is reassembling the images in the right order. pov-ray already
>>> >>supports this with its resume feature, just no one has written a
>>> >>way to do it distributedly
>>> >
>>> >Same problem. Believe us, we've actually thought about this problem
>>> >and it's not as simple as you think. (Why do I find myself saying
>>> >that more and more these days?)
>>> >
>>>
>>> why won't it work? does pov-ray do some kind of image analysis when
>>> it resumes an image? I've done this with huge renders (say 10 lines
>>> one day, another 10 lines the next, etc) and I haven't had any
>>> problems
>>
>>If I understand things correctly you don't get the same random seed
>>every time
>>you start a render, this leads to the images not fitting together as
>>nice as
>>they should, this is very noticable if you are using radiosity. Since
>>povray
>>doesn't store the seed it will not be able to make your scene perfect,
>>if you
>>are using just antialiasing you might not see it, but try to do some
>>radiosity
>>and you should most probably get a somewhat noticable line where you
>>halted the
>>rendering, and then resumed.
>>
>>/Peter Toneby
>>
>
>I'll try doing a radoisity test, but I just did a test rendering with my
>method and everything rejoined fine. renderered the bottom third of my
>image, then the first third, then the second. I didn't have any problems
>joining them back together
>
>if its just a matter of saving the random seed, I don't think that would
>be a major obstacle. or maybe just have the ability so the user can
>define the seed in their scene ahead of time.
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) |
On Wed, 28 Jun 2000 19:52:32 -0500, Mark Gordon wrote:
>Ron Parker wrote:
>
>> 9x is still dependent on a lot of 16-bit code, which is to a certain extent
>> cooperative. 16-bit apps running on 9x cooperate with each other, and the
>> entire 16-bit subsystem (if you can call it that) is one process from the
>> point of view of the 32-bit scheduler.
>
>That's pretty much what I've heard, too.
God, I hope it's accurate. Mucking about with the 16-bit subsystem at
an assembly-language level is what I do for a living. :)
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
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) |
On Thu, 29 Jun 2000 01:32:01 +0200, woo### [at] acc umu se wrote:
>If I understand things correctly you don't get the same random seed
>every time
>you start a render, this leads to the images not fitting together as
>nice as
>they should, this is very noticable if you are using radiosity. Since
>povray
>doesn't store the seed it will not be able to make your scene perfect,
It's not about a random seed; it's about the radiosity cache. When POV
samples an area for radiosity calculations, it saves the result of the
sample and reuses it later if it needs something sufficiently close by.
If you abort the render and restart it later, POV starts over with the
default radiosity cache (that's what it's building when it does the
required mosaic preview) that doesn't contain all the fine-grained
samples it had at the end of the previous run. Thus, the samples on
the first scanline of the new region probably looked at a point further
away, or a slightly different point, than the samples on the last line
of the old region, leading to subtle tonal variations.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
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) |
if I'm not mistaken there is a way to save the radisoisty file in pov-ray.
would making sure each time you did radisoity you saved the file work
around the problem?
ron### [at] povray org (Ron Parker) wrote in
<slr### [at] linux parkerr fwi com>:
>On Thu, 29 Jun 2000 01:32:01 +0200, woo### [at] acc umu se wrote:
>>If I understand things correctly you don't get the same random seed
>>every time
>>you start a render, this leads to the images not fitting together as
>>nice as
>>they should, this is very noticable if you are using radiosity. Since
>>povray
>>doesn't store the seed it will not be able to make your scene perfect,
>
>
>It's not about a random seed; it's about the radiosity cache. When POV
>samples an area for radiosity calculations, it saves the result of the
>sample and reuses it later if it needs something sufficiently close by.
>If you abort the render and restart it later, POV starts over with the
>default radiosity cache (that's what it's building when it does the
>required mosaic preview) that doesn't contain all the fine-grained
>samples it had at the end of the previous run. Thus, the samples on
>the first scanline of the new region probably looked at a point further
>away, or a slightly different point, than the samples on the last line
>of the old region, leading to subtle tonal variations.
>
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) |
On 28 Jun 2000 23:35:08 -0400, daishi wrote:
>if I'm not mistaken there is a way to save the radisoisty file in pov-ray.
>would making sure each time you did radisoity you saved the file work
>around the problem?
For continued renders, yes. I'll leave the question of whether it would
help parallel rendering as an exercise for the reader.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
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) |
ron### [at] povray org (Ron Parker) wrote in
<slr### [at] linux parkerr fwi com>:
>On 28 Jun 2000 23:35:08 -0400, daishi wrote:
>>if I'm not mistaken there is a way to save the radisoisty file in
>>pov-ray. would making sure each time you did radisoity you saved the
>>file work around the problem?
>
>For continued renders, yes. I'll leave the question of whether it would
>help parallel rendering as an exercise for the reader.
>
me thinks I'll try this tomorrow....
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) |