Computers have been networked not for a long time. The internet is almost 
every where. If programs are not written for networks they might as well 
stay in dos. They will not be of use. Povray is know for doing things that 
other programs can not yet. But Povray in all of its power can not even 
brake up the image into chunks and pass those to nodes to render and return 
the part of the image. This IS a simple venture. I have built an external 
system to do just this but it is clumsey. Even simpler is to send frames 
out to different systems. This would help also. This is something the 
povray team should have already done. I know the program is free but honer 
and pride in work along with integraty should have driven them to write a 
completely modern application. As for money they can talk to me about that.



fou### [at] pegeorg (Mösl Roland) wrote in <3959345d$1@news.povray.org>:

>"Warp" <war### [at] tagpovrayorg> wrote in message
>news:39586434@news.povray.org...
>>   Too bad that Windows9x doesn't support multiple processors. NT
>>   supports, 
>> but I think that the number of NT users are an extremely small percent
>> of the Windows9x users.
>>   So I think it would be a waste of time.
>
>Around 10 %.
>
>
>--
>Mösl Roland http://www.pege.org
>Clear targets for a confused civilization
>http://www.BeingFound.com
>web design and seminars
>+43 699 17343674
>
>
>

Post a reply to this message

war### [at] tagpovrayorg (Warp) wrote in <3959ac7d@news.povray.org>:

>In povray.general Thorsten Froehlich <tho### [at] trfde> wrote:
>: This is not correct.  Windows 9x, NT and 2000 are all pre-emptive
>: multitasking systems.
>
>  Win9x is only partially it.
>


'partially' which means win98 is cooporative......(just like mac OS, not 
counting X of course)

Post a reply to this message

In article <8F617F84Elavendersmith@204.213.191.228>, 
lav### [at] hotmailcom (lavender) wrote:

> Computers have been networked not for a long time. The internet is 
> almost every where. If programs are not written for networks they 
> might as well stay in dos. They will not be of use. Povray is know 
> for doing things that other programs can not yet. But Povray in all 
> of its power can not even brake up the image into chunks and pass 
> those to nodes to render and return the part of the image. This IS a 
> simple venture. I have built an external system to do just this but 
> it is clumsey. Even simpler is to send frames out to different 
> systems. This would help also. This is something the povray team 
> should have already done. I know the program is free but honer and 
> pride in work along with integraty should have driven them to write a 
> completely modern application. As for money they can talk to me about 
> that.

It is not as easy as you seem to think...there is a lot of data that 
needs to be shared, the code isn't built with this type of rendering in 
mind, so most of the code would need to be rewritten, and the solution 
needs to be cross-platform. Also, there are certain things like noise 
and data generated on the fly which would need to be synchronized 
somehow. Add the need for testing, and it is pretty obvious why it 
hasn't been done yet.
Distributing frames to render is much easier, but still has problems-all 
the frames up to the current one would have to be parsed, since a frame 
may depend on the frames before it.

The POV-Team will probably at least make preparations for network 
rendering features in POV 4, but that will be a complete rewrite in C++.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

is it not possible in pov to render only a portion of the screen? if it is 
it should be possible to hack a simple script together to do network 
rendering. bmrt comes with a script that does this (have one comp render a 
portion of the screen, another comp render another portion, etc then all 
the images are assembled by an external program)

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

>In article <8F617F84Elavendersmith@204.213.191.228>, 
>lav### [at] hotmailcom (lavender) wrote:
>
>> Computers have been networked not for a long time. The internet is 
>> almost every where. If programs are not written for networks they 
>> might as well stay in dos. They will not be of use. Povray is know 
>> for doing things that other programs can not yet. But Povray in all 
>> of its power can not even brake up the image into chunks and pass 
>> those to nodes to render and return the part of the image. This IS a 
>> simple venture. I have built an external system to do just this but 
>> it is clumsey. Even simpler is to send frames out to different 
>> systems. This would help also. This is something the povray team 
>> should have already done. I know the program is free but honer and 
>> pride in work along with integraty should have driven them to write a 
>> completely modern application. As for money they can talk to me about 
>> that.
>
>It is not as easy as you seem to think...there is a lot of data that 
>needs to be shared, the code isn't built with this type of rendering in 
>mind, so most of the code would need to be rewritten, and the solution 
>needs to be cross-platform. Also, there are certain things like noise 
>and data generated on the fly which would need to be synchronized 
>somehow. Add the need for testing, and it is pretty obvious why it 
>hasn't been done yet.
>Distributing frames to render is much easier, but still has problems-all 
>the frames up to the current one would have to be parsed, since a frame 
>may depend on the frames before it.
>
>The POV-Team will probably at least make preparations for network 
>rendering features in POV 4, but that will be a complete rewrite in C++.
>

Post a reply to this message

In article <8F61873E3dashixpressnet@204.213.191.228>, das### [at] x-pressnet 
(daishi) wrote:

> is it not possible in pov to render only a portion of the screen? if 
> it is it should be possible to hack a simple script together to do 
> network rendering. bmrt comes with a script that does this (have one 
> comp render a portion of the screen, another comp render another 
> portion, etc then all the images are assembled by an external 
> program)

It is possible to render a portion of an image, but getting the images 
tiled without discontinuities is a problem. If you distribute parts of 
an image to different machines this way, features like radiosity, 
antialiasing, etc can produce a "tiles" effect, like a mosaiac 
photograph.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <8F617F84Elavendersmith@204.213.191.228> , 
lav### [at] hotmailcom (lavender) wrote:

> But Povray in all of its power can not even
> brake up the image into chunks and pass those to nodes to render and return
> the part of the image. This IS a simple venture. I have built an external
> system to do just this but it is clumsey. Even simpler is to send frames
> out to different systems. This would help also.

While this is easy to implement on _one_ platform, doling it on multiple
platforms is an extreme amount of work.  How many of the "professional"
programs can do this on more than just a few Unix platforms?  The answers is
simple: None.  Pixar added Windows NT support for RenderMan just a short
time ago, and they have hundreds of millions of dollars (after the movies
they made for Disney).  There is no standard API for networking defined in
either the C or C== standard, even Unix has Sockets and Streams.

> This is something the
> povray team should have already done. I know the program is free but honer
> and pride in work along with integraty should have driven them to write a
> completely modern application.

There will be a rewrite for 4.0 using C++, but consider that we do it in our
spare time, don't get paid $10000/month and work 50 hours/week for POV-Ray.
Some of the features in POV-Ray also require PhD grade math to understand.
I.e. for photons there are just the mathematical models, even those who
invented these models don't have a parallel solution for them yet (at least
published).


     Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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
simple application that just executes a loop lets say 10 billion times, will
the other applications still get a share of the processor?  Yes, because the
operating system will interrupt it after a few milliseconds and then switch
to another application.  This is pre-emptive multitasking.

On a Mac with i.e. Mac OS 9 an application executing the same program will
not share the processor with other applications until it calls the operating
system and allows it.  This is co-operative multitasking.

The difference between Win 9x and Win NT/2000 is the quality (and
probability method) of the scheduling algorithms, but they are still both
pre-emptive.
In fact this is one of the major improvements in Win 9x since Win 3.x.


     Thorsten


PS: If you don't believe me, get any recent CS textbook on operating
systems, and it will tell you Win 9x and NT both use pre-emptive
multitasking :-)


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <8F61873E3dashixpressnet@204.213.191.228> , das### [at] x-pressnet 
(daishi) wrote:

> is it not possible in pov to render only a portion of the screen? if it is
> it should be possible to hack a simple script together to do network
> rendering.

This will not work for radiosity.


      Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

>In article <8F61873E3dashixpressnet@204.213.191.228>, das### [at] x-pressnet 
>(daishi) wrote:
>
>> is it not possible in pov to render only a portion of the screen? if 
>> it is it should be possible to hack a simple script together to do 
>> network rendering. bmrt comes with a script that does this (have one 
>> comp render a portion of the screen, another comp render another 
>> portion, etc then all the images are assembled by an external 
>> program)
>
>It is possible to render a portion of an image, but getting the images 
>tiled without discontinuities is a problem. If you distribute parts of 
>an image to different machines this way, features like radiosity, 
>antialiasing, etc can produce a "tiles" effect, like a mosaiac 
>photograph.
>


but if you use the same settings on all the machines it shouldn't be an 
issue, should it?

Post a reply to this message

daishi wrote:

> but if you use the same settings on all the machines it shouldn't be an
> issue, should it?

Do you understand how anti-aliasing works ?

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

tho### [at] trfde (Thorsten Froehlich) wrote in <395a47bc@news.povray.org>:

>In article <8F617F84Elavendersmith@204.213.191.228> , 
>lav### [at] hotmailcom (lavender) wrote:
>
>> But Povray in all of its power can not even
>> brake up the image into chunks and pass those to nodes to render and
>> return the part of the image. This IS a simple venture. I have built
>> an external system to do just this but it is clumsey. Even simpler is
>> to send frames out to different systems. This would help also.
>
>While this is easy to implement on _one_ platform, doling it on multiple
>platforms is an extreme amount of work.  How many of the "professional"
>programs can do this on more than just a few Unix platforms?  The
>answers is simple: None.  Pixar added Windows NT support for RenderMan
>just a short time ago, and they have hundreds of millions of dollars
>(after the movies they made for Disney).  There is no standard API for
>networking defined in either the C or C== standard, even Unix has
>Sockets and Streams. 
>
would it be possible to use CORBA to do this?

Post a reply to this message

Chris Huff wrote:

>It is possible to render a portion of an image, but getting the images 
>tiled without discontinuities is a problem. If you distribute parts of 
>an image to different machines this way, features like radiosity, 
>antialiasing, etc can produce a "tiles" effect, like a mosaiac 
>photograph.
>

What if you make the portions a bit bigger than needed, so the "tiles" 
overlap?

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

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.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

On Wed, 28 Jun 2000 20:57:13 +0200, Thorsten Froehlich wrote:
>The difference between Win 9x and Win NT/2000 is the quality (and
>probability method) of the scheduling algorithms, but they are still both
>pre-emptive.
>In fact this is one of the major improvements in Win 9x since Win 3.x.

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.

NT has the same arrangement, except for the dependence on 16-bit code, 
unless you set up your 16-bit apps to run in separate processes (this is
not the default.)

So 9x and NT are mostly preemptive, but they still have a cooperative 
system inside for legacy apps.

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

Post a reply to this message

I've been following this thread for a while and have been playing with
raytracing for a few years.
I wonder if it would be possible for a single machine to generate the
radiosity map and then pass it around. This would solve the randomization
issues. just passing a seed value would only work if all the machines had
the same radomize function.

Alan

"Chris Huff" <chr### [at] maccom> wrote in message
news: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.
>
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/

Post a reply to this message

tho### [at] trfde (Thorsten Froehlich) wrote in <395a4a62@news.povray.org>:

>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 simple application that just executes a loop lets say 10 billion
>times, will the other applications still get a share of the processor? 
>Yes, because the operating system will interrupt it after a few
>milliseconds and then switch to another application.  This is
>pre-emptive multitasking. 
>
>On a Mac with i.e. Mac OS 9 an application executing the same program
>will not share the processor with other applications until it calls the
>operating system and allows it.  This is co-operative multitasking.
>
>The difference between Win 9x and Win NT/2000 is the quality (and
>probability method) of the scheduling algorithms, but they are still
>both pre-emptive.
>In fact this is one of the major improvements in Win 9x since Win 3.x.
>
>
>     Thorsten
>
>
>PS: If you don't believe me, get any recent CS textbook on operating
>systems, and it will tell you Win 9x and NT both use pre-emptive
>multitasking :-)
>
>
>____________________________________________________
>Thorsten Froehlich, Duisburg, Germany
>e-mail: tho### [at] trfde
>
>Visit POV-Ray on the web: http://mac.povray.org
>

while I agree with what your saying. there was an article a while ago 
discussing NT vs win98 that said win98 was cooporative. I can't seem to 
find the article though...

win98s scheduling needs improvement then, cause compared to other multi-
tasking OSs it sucks..

Post a reply to this message

On 28 Jun 2000 15:42:35 -0400, daishi wrote:
>while I agree with what your saying. there was an article a while ago 
>discussing NT vs win98 that said win98 was cooporative. I can't seem to 
>find the article though...
>
>win98s scheduling needs improvement then, cause compared to other multi-
>tasking OSs it sucks..

It's no more cooperative than NT.  It sucks because it switches back and
forth from the (mostly non reentrant) 16-bit core a lot.

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

Post a reply to this message

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

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

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

Post a reply to this message

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

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

>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'm pulling no punches here. I have no respect for folks who come into this
form and insult us ...

"lavender" <lav### [at] hotmailcom> wrote:
> Computers have been networked not for a long time. The internet is almost
> every where. If programs are not written for networks they might as well
> stay in dos. They will not be of use. Povray is know for doing things that

Fascinating point of view. A non-networked program is not of use ? Wow. I
guess I had better throw out my non-networked version of Photoshop, the
non-networked C++ compiler I use, the non-networked word processor, the non-
networked utilities, and probably 90% of the other software on my machine.

After all, you said they 'will not be of use' and you couldn't possibly be
wrong ... could you ?????

> other programs can not yet. But Povray in all of its power can not even
> brake up the image into chunks and pass those to nodes to render and return

What do brakes have to do with rendering ?

> the part of the image. This IS a simple venture.

Really ? And you're an expert on the subject I see ... how many raytracers
have you written so far ? Can you point me to some URL's or binaries ? I
would like to understand how 'simple' this is by seeing your quality work ...

> Even simpler is to send frames out to different systems.

You don't have a clue what you're talking about. Come back when you understand
the subject.

> povray team should have already done. I know the program is free but honer
> and pride in work along with integraty should have driven them to write a

Don't presume to tell us what we should do with our time. You have no right
whatsoever to belittle us and suggest that our integrity is blemished because
we haven't done something that YOU think is easy.

We see people like you come along from time to time. They know little but
say much, and presume to insult us because we don't do things that they
want us to.

-- Chris Cason
   POV-Team

Post a reply to this message

On Thu, 29 Jun 2000 13:52:07 +1000, Chris Cason wrote:
>I'm pulling no punches here. 
[extremely fine rant elided]

Seconded.  Couldn'a said it better myself.

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

Post a reply to this message

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

> On Thu, 29 Jun 2000 13:52:07 +1000, Chris Cason wrote:
>>I'm pulling no punches here.
> [extremely fine rant elided]
>
> Seconded.  Couldn'a said it better myself.

I agree.


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In povray.general Ron Parker <ron### [at] povrayorg> wrote:
: So 9x and NT are mostly preemptive, but they still have a cooperative 
: system inside for legacy apps.

  That's why they are only partly pre-emptive.
  I can make a program that completely steals all the CPU time in windows.
  I can't do this in Unix. I can make a program that steals _most_ of the
CPU time, but still it just can't lock up the system; other programs can
still run and, for example, kill the resource-stealing program if necessary.
In windows, however, it is possible to make a program that locks up the
system completely.
  I don't know about win2k or NT.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In povray.general lavender <lav### [at] hotmailcom> wrote:
: Computers have been networked not for a long time. The internet is almost 
: every where. If programs are not written for networks they might as well 
: stay in dos.

  Not true. Multitasking (and of course memory protection) is a very important
feature even in a 1-processor computer. Of course one sole program will not
benefit from multitasking in a 1-processor computer, but you need only two
programs running at the "same" time to get the benefits (not to talk about
the tens or even hundres of processes running in a typical multitasking
environment).
  If you have several computers connected to each other, a program could
benefit from this and make each one of them perform an independent task of
the program.
  Usually this needs direct support in the program itself, but luckily
povray is not one of those. Since povray supports partial renders you can
run povray in each computer and render one part of the image.
  With proper tools you can automatize this task (without having to patch
povray itself). Of course a proper operating system will help providing these
tools by itself or allowing to make them rather easily (either with some
scripting language or easy support to a programming language like C).
  Unfortunately Windows is not one of these operating systems.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In povray.general Thorsten Froehlich <tho### [at] trfde> wrote:
: There will be a rewrite for 4.0 using C++, but consider that we do it in our
: spare time, don't get paid $10000/month and work 50 hours/week for POV-Ray.

  On the other hand you don't have deadline pressures, market pressures,
competition pressures ("must have this product out before competitors").
Which means that if you are not happy with the current version, you just don't
publish it and that's it. You publish it when it's ready, and then it will
certainly be a lot higher quality program.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"lavender" <lav### [at] hotmailcom> wrote in message
news:8F617F84Elavendersmith@204.213.191.228...
> Computers have been networked not for a long time. The internet is almost
> .....

Hmm, I smell a rat - or am I just being naive in thinking that no one could
be this idiotic and insulting accidentally?

> ... As for money they can talk to me about that.

I hereby appoint myself financial director in the lavender/POV-team
endevour. Send me money. Initially, it will be spent on a new Pentium III PC
for myself, as I wish to render all contracts with radiosity and photons on
iso-surface paper.

Post a reply to this message

In povray.general Chris Cason <nospam@noemail> wrote:
:> Even simpler is to send frames out to different systems.

: You don't have a clue what you're talking about. Come back when you understand
: the subject.

  Please try to understand that it is not so easy to know the difficulties
of multithreading and multitasking unless you have studied it or tried to
make lots of programs using it.
  I didn't have a clue about multithreading and multitasking (and their
problems) until I had several courses about the matter here (Tampere university
of technology).
  A layman can easily think that it's just a piece of cake to make
multitasked systems and multithreaded programs. It's only when you try to
do it or when you are taught about it that you realize how problematic it
really is. Some problems are so deep, that even the most modern science have
not solved them in a fool-proof manner.
  One could think that if it's so problematic, how come there are countless
operating systems and programs using it without problems?
  Operating systems have more than 30 years of experience about multitasking
behind them and they use well-known algorithms. These algorithms are often
extremely complicated, specially if the OS tries to achieve the multitasking
effectively, without too much overhead (multitasking is _never_ free; it
always consumes some resources). This is the reason why some systems don't
have multitasking at all and some others have only extremely poor versions
of them.
  A multithreaded program is not any luckier (if anything, it's the other
way around, ie. it can have even more problems). There are very serious
and complicated problems here, like mutual exclusion problems, communication
(between threads) problems, problems about sharing of resources, and so on.
Some operating systems offer system tools for these tasks (like semaphores,
monitors, etc), others don't.
  The big problem about these is that they are incredibly malicious. You can
have a mutual exclusion bug in your program which doesn't happen to you no
matter how many test runs you make. However when thousands of people start
to use the program, the bug can arise.
  These mutual exclusion (and other similar) bugs usually happen in only
certain conditions. These conditions are usually extremely rare and extremely
hard to reproduce (you'll have to reproduce the entire series of events that
lead to that bug, and this can be near to impossible since it may depend
on what the operating system was doing at that exact time).
  There's one adjective to describe this type of behaviour: Non-deterministic.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:395b1a0a@news.povray.org...
>   Please try to understand that it is not so easy to know the difficulties
> of multithreading and multitasking unless you have studied it or tried to
> make lots of programs using it.
>...
>   A layman can easily think that it's just a piece of cake to make
> multitasked systems and multithreaded programs.

<dumb>
Gosh, you lot do try and complicate things. Multi-tasking is easy - you just
wire up a load of CPUs in series. Alternatively, if you wish your system to
go longer without crashing, you can wire them up in parallel.
</dumb>

Post a reply to this message

Warp wrote:
> 
>   I can make a program that completely steals all the CPU time in windows.

But not in NT.

>   I don't know about win2k or NT.

Aha.

Markus

Post a reply to this message

> It is possible to render a portion of an image, but getting the images
> tiled without discontinuities is a problem. If you distribute parts of
> an image to different machines this way, features like radiosity,
> antialiasing, etc can produce a "tiles" effect, like a mosaiac
> photograph.

couldn't this be solved by using overlapping tiles?

Rick

Post a reply to this message

In povray.general Chris Huff <chr### [at] maccom> wrote:
: It is possible to render a portion of an image, but getting the images 
: tiled without discontinuities is a problem. If you distribute parts of 
: an image to different machines this way, features like radiosity, 
: antialiasing, etc can produce a "tiles" effect, like a mosaiac 
: photograph.

  So far radiosity is the only source of problems. Antialiasing is not
a problem.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 28 Jun 2000 23:41:08 -0400, daishi wrote:
>ron### [at] povrayorg (Ron Parker) wrote in
><slr### [at] linuxparkerrfwicom>: 
>
>>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....

Well, that confirms my suspicions.  The answer to that question does not
require research, just a little (very little) thought.

(hint: if you don't have the radiosity cache you need for line 10 until you
finish line 9, how are you going to render line 10 in parallel with line 1?)

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

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:395b4663@news.povray.org...
| In povray.general Chris Huff <chr### [at] maccom> wrote:
| : It is possible to render a portion of an image, but getting the images
| : tiled without discontinuities is a problem. If you distribute parts of
| : an image to different machines this way, features like radiosity,
| : antialiasing, etc can produce a "tiles" effect, like a mosaiac
| : photograph.
|
|   So far radiosity is the only source of problems. Antialiasing is not
| a problem.

Radiosity sampling would be nice for partial renders, even if POV-Ray were to
redo the entire image in mosaic preview before doing the selected region.
Guess that goes without saying.

Bob

Post a reply to this message

In povray.general Bob Hughes <per### [at] aolcom?subject=pov-news:> wrote:
: Radiosity sampling would be nice for partial renders, even if POV-Ray were to
: redo the entire image in mosaic preview before doing the selected region.
: Guess that goes without saying.

  This is only supposing that it will not calculate any new radiosity samples
in the final pass.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

tom### [at] tomandluf9couk (Tom Melly) wrote in <395b19de$1@news.povray.org>:

>"lavender" <lav### [at] hotmailcom> wrote in message
>news:8F617F84Elavendersmith@204.213.191.228...
>> Computers have been networked not for a long time. The internet is
>> almost .....
>
>Hmm, I smell a rat - or am I just being naive in thinking that no one
>could be this idiotic and insulting accidentally?
>
>> ... As for money they can talk to me about that.
>
>I hereby appoint myself financial director in the lavender/POV-team
>endevour. Send me money. Initially, it will be spent on a new Pentium
>III PC for myself, as I wish to render all contracts with radiosity and
>photons on iso-surface paper.
>
>

I am not sure what you are trying to say with this but I will reply to the 
buttom part.

Why do you not have enough money to buy you a new PIII system? Email this 
back and I will explain! Not in this form.

Post a reply to this message

"lavender" <lav### [at] hotmailcom> wrote in message
news:8F6276DAClavendersmith@204.213.191.228...
> tom### [at] tomandluf9couk (Tom Melly) wrote in <395b19de$1@news.povray.org>:
>
> >"lavender" <lav### [at] hotmailcom> wrote in message
> >news:8F617F84Elavendersmith@204.213.191.228...
> >> Computers have been networked not for a long time. The internet is
> >> almost .....
> >
> >Hmm, I smell a rat - or am I just being naive in thinking that no one
> >could be this idiotic and insulting accidentally?
> >
> >> ... As for money they can talk to me about that.
> >
> >I hereby appoint myself financial director in the lavender/POV-team
> >endevour. Send me money. Initially, it will be spent on a new Pentium
> >III PC for myself, as I wish to render all contracts with radiosity and
> >photons on iso-surface paper.
> >
> >
>
> I am not sure what you are trying to say with this but I will reply to the
> buttom part.

but tom what?

>
> Why do you not have enough money to buy you a new PIII system? Email this
> back and I will explain! Not in this form.

What form would you like to use? (recognisable English would be a start).

Post a reply to this message

On 29 Jun 2000 05:02:30 -0400, Warp <war### [at] tagpovrayorg> wrote:

>  That's why they are only partly pre-emptive.
>  I can make a program that completely steals all the CPU time in windows.
>  I can't do this in Unix. I can make a program that steals _most_ of the
>CPU time, but still it just can't lock up the system; other programs can
>still run and, for example, kill the resource-stealing program if necessary.
>In windows, however, it is possible to make a program that locks up the
>system completely.
>  I don't know about win2k or NT.

I can't say about win2k but my experience with NT reveals that it's
not much better in this regard (aside from being a worse CPU and RAM
hog thant Win9x). What I have in mind is a nightmare in which NT took
half an hour to boot on a K6/233 with 64 RAM, the last fifteen minutes
being spent on drawing an icon a minute on the desktop. In this
nightmare a network client was trying to connect to localhost for some
reason only known to itself and took in the process so much CPU time
that it couldn't even be killed, giving an absurd message akin to "The
network server is too busy to complete this request". The thing that
troubled me the most was that this nightmare was real. No more NT for
me since then, No Thanks.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Tom Melly wrote:
> 
> What form would you like to use? (recognisable English would be a start).

I thought only germans were able to start language flame wars...

shhh.

Markus

Post a reply to this message

> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Clever little program ...

Jon

Post a reply to this message