Thorsten Froehlich wrote:
> 
> In article <8F6177D69dashixpressnet@204.213.191.228> , das### [at] x-pressnet
> (daishi) wrote:
> 
> > 'partially' which means win98 is cooporative......(just like mac OS, not
> > counting X of course)
> 
> No, it is pre-emptive with a monolithic operating system.  If you write a
> ...
> In fact this is one of the major improvements in Win 9x since Win 3.x.
> 
>      Thorsten

But, under windows 3.1, separate MS-DOS boxes were preemptively
multitasked.  Goes back farther that you might think.

Win 9x crashes are typically due to bad programs writing into memory
regions that are accessible to all running apps.  And the reason for
those common regions are to retain backwards compatability...

Xander

Post a reply to this message

chr### [at] maccom (Chris Huff) wrote in <chrishuff-
CE60D9.14082128062000@news.povray.org>:

>In article <8F619D6A0dashixpressnet@204.213.191.228>, das### [at] x-pressnet 
>(daishi) wrote:
>
>> but if you use the same settings on all the machines it shouldn't be an 
>> issue, should it?
>
>No, because radiosity is view dependant, and also because it relies on 
>randomized sampling, caching data, as well as generating data on the 
>fly, each square will have shading which is a little bit different from 
>it's neighbors. Similar problems may exist for other features.
>


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

Post a reply to this message

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?)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

ron### [at] povrayorg (Ron Parker) wrote in
<slr### [at] linuxparkerrfwicom>: 

>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

daishi wrote:
> 
> ron### [at] povrayorg (Ron Parker) wrote in
> <slr### [at] linuxparkerrfwicom>:
> 
> >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

woo### [at] accumuse wrote in <395A8AF1.91D7229D@acc.umu.se>:

>daishi wrote:
>> 
>> ron### [at] povrayorg (Ron Parker) wrote in
>> <slr### [at] linuxparkerrfwicom>:
>> 
>> >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

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

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-pressnet (daishi) wrote in
<8F61C58CBdashixpressnet@204.213.191.228>: 

>woo### [at] accumuse wrote in <395A8AF1.91D7229D@acc.umu.se>:
>
>>daishi wrote:
>>> 
>>> ron### [at] povrayorg (Ron Parker) wrote in
>>> <slr### [at] linuxparkerrfwicom>:
>>> 
>>> >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

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

On Thu, 29 Jun 2000 01:32:01 +0200, woo### [at] accumuse 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