Hi all, follows is a recent conversation with Jakob Flierl concerneing a
port of PVMPOV to windows, as you will see from his email at the bottom,
most of the required parts of a windows port are in place.

so if there are any programmers in here who fancy a project (and making a
lot of ppl very happy!)

Rick

-----

unfortunately I am not the person to undertake that venture, unfortunately
my programming skills extend as far as VB..

it sounds like the bulk of the work required is already in place, and all
that's needed it a skilled win32 programmer to take the project up.

I will post this conversation to the povray NG's and see if I can generate
some interest :)

Rick
----- Original Message -----
From: "Jakob Flierl" <fli### [at] fmiuni-passaude>
To: "Rick [Kitty5]" <ric### [at] kitty5com>
Sent: Monday, June 26, 2000 8:14 AM
Subject: Re: windows?


> Hi Rick,
>
> Rick, you write:
> | would it be possabel to port pvm pov to windows, or is that a silly idea
and going to be more trouble than its worth?
>
> I personally think, that it would be possible to port PVMPOV to Windows or
> win32 since there is an existing port of the pvm library and POV-Ray to
> windows. But there has not been any successfull attempt yet.
>
> I don't know of anyone who has tried this and lived. Every time someone
> contacts me about running PVMPOV under Windows, I never hear back from
them.
>
> Cheers,
>
>   JF

Post a reply to this message

I would much rather see Povray implemented with threads.  I would not
know the scope of that though.  

Rick wrote:
> 
> Hi all, follows is a recent conversation with Jakob Flierl concerneing a
> port of PVMPOV to windows, as you will see from his email at the bottom,
> most of the required parts of a windows port are in place.
> 
> so if there are any programmers in here who fancy a project (and making a
> lot of ppl very happy!)
> 
> Rick
> 
> -----
> 
> unfortunately I am not the person to undertake that venture, unfortunately
> my programming skills extend as far as VB..
> 
> it sounds like the bulk of the work required is already in place, and all
> that's needed it a skilled win32 programmer to take the project up.
> 
> I will post this conversation to the povray NG's and see if I can generate
> some interest :)
> 
> Rick
> ----- Original Message -----
> From: "Jakob Flierl" <fli### [at] fmiuni-passaude>
> To: "Rick [Kitty5]" <ric### [at] kitty5com>
> Sent: Monday, June 26, 2000 8:14 AM
> Subject: Re: windows?
> 
> > Hi Rick,
> >
> > Rick, you write:
> > | would it be possabel to port pvm pov to windows, or is that a silly idea
> and going to be more trouble than its worth?
> >
> > I personally think, that it would be possible to port PVMPOV to Windows or
> > win32 since there is an existing port of the pvm library and POV-Ray to
> > windows. But there has not been any successfull attempt yet.
> >
> > I don't know of anyone who has tried this and lived. Every time someone
> > contacts me about running PVMPOV under Windows, I never hear back from
> them.
> >
> > Cheers,
> >
> >   JF

Post a reply to this message

Nick Portelli wrote:
> 
> I would much rather see Povray implemented with threads.  I would not
> know the scope of that though.

It would be difficult.

See:  http://www.students.tut.fi/~warp/povVFAQ/languageVFAQ.html#multiprocessor

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

Rick wrote:

> Hi all, follows is a recent conversation with Jakob Flierl concerneing a
> port of PVMPOV to windows, as you will see from his email at the bottom,
> most of the required parts of a windows port are in place.
>
> so if there are any programmers in here who fancy a project (and making a
> lot of ppl very happy!)
>
> -----
>
> unfortunately I am not the person to undertake that venture, unfortunately
> my programming skills extend as far as VB..
>
> it sounds like the bulk of the work required is already in place, and all
> that's needed it a skilled win32 programmer to take the project up.
>
> I will post this conversation to the povray NG's and see if I can generate
> some interest :)
>
> > Hi Rick,
> >
> > Rick, you write:
> > | would it be possabel to port pvm pov to windows, or is that a silly idea
> and going to be more trouble than its worth?
> >
> > I personally think, that it would be possible to port PVMPOV to Windows or
> > win32 since there is an existing port of the pvm library and POV-Ray to
> > windows. But there has not been any successfull attempt yet.
> >
> > I don't know of anyone who has tried this and lived. Every time someone
> > contacts me about running PVMPOV under Windows, I never hear back from
> them.

What exactly do you require the programmer to do?
I might be interested & have a few weeks off now
I have msvc6sp3 & the msdn lib
but I am not extremely skilled ;-/
& only have a single cpu
The msdn lib will help me when it comes to thread functions etc.
How many people actually run win32 with multiple cpus

--
Bye
Pabs

Post a reply to this message

Pabs wrote:

> How many people actually run win32 with multiple cpus

A small percentage of NT users who are fortunate enough to find
software that supports it.

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

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.

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

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

yes but there is win2000, and in a few years i would suspect that even home
versions of windows will have multi cpu support, while threading may be a
good idea, at the moment it seems like a lot of work with benift for the
few.. mind you once its done, its done so to speak and it is something the
pov team are going to have to look at over the next few years.

Rick

Post a reply to this message

> What exactly do you require the programmer to do?

not being a C programmer myself i am not sure, neither am i exactly sure
what state the completed sections of win32 pvmpov are at.

> I might be interested & have a few weeks off now
> I have msvc6sp3 & the msdn lib
> but I am not extremely skilled ;-/

i don't think the povray source code is a good place to learn, i had a look
a while back when i was learning C and decided after 10 mins that there was
not a chance i was going to mess !!

> & only have a single cpu

there is no way you could develop with only one cpu / one machine, you would
be coding blind.

> The msdn lib will help me when it comes to thread functions etc.

sure mdsn is a great help, but you have to remeber - its finding the help in
there which is often half the problem! - the amont of times i have spent
several hours trawling the cd's when all i needed was a simple 'do it this
way' !!!

Rick

Post a reply to this message

In povray.general Rick <ric### [at] kitty5com> wrote:
: yes but there is win2000

  Win2000 is more WinNT than Win9x. It's made more for the same uses as NT
is rather than for games and such. I think that many win9x games don't even
work in Win2000.

  Of course Linux (and other free unix systems) support multiple processors
and still there is no multithreaded povray for them.
  PVM-pov exists no more, and even when it existed it didn't work with
radiosity.
  Multithreading has also many other problems. It's more problematic than
it may sound. I wrote an entry in the VFAQ about this.

  Another thing is that since it's not made by the povteam, this version will
always be one step behind the official version.

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

I think I have noticed an improvement to all my 3d applications like Povray,
MegaPov, and the swarm off modeling tools I've been using. W2k is very
stable, me likey very much.
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3958b660@news.povray.org...
> In povray.general Rick <ric### [at] kitty5com> wrote:
> : yes but there is win2000
>
>   Win2000 is more WinNT than Win9x. It's made more for the same uses as NT
> is rather than for games and such. I think that many win9x games don't
even
> work in Win2000.
>
>   Of course Linux (and other free unix systems) support multiple
processors
> and still there is no multithreaded povray for them.
>   PVM-pov exists no more, and even when it existed it didn't work with
> radiosity.
>   Multithreading has also many other problems. It's more problematic than
> it may sound. I wrote an entry in the VFAQ about this.
>
>   Another thing is that since it's not made by the povteam, this version
will
> always be one step behind the official version.
>
> --
> 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 article <3958b660@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Of course Linux (and other free unix systems) support multiple processors
> and still there is no multithreaded povray for them.
>   PVM-pov exists no more, and even when it existed it didn't work with
> radiosity.

I think photons wouldn't work either :-(

>   Multithreading has also many other problems. It's more problematic than
> it may sound. I wrote an entry in the VFAQ about this.

For POV-Ray 3.5 we will at least have a list of all the global variables and
in which function(s) they are used.  It is surprising, there are even
globals that are used to just pass an argument from one function to another.
While about 80% of the global variables in POV-Ray could be removed in short
period of time, at least 20% would be next to impossible remove.
That is one of the reasons why there will be some kind of rewrite for
POV-Ray 4.0.

>   Another thing is that since it's not made by the povteam, this version will
> always be one step behind the official version.

One of the long planned goals surely is to offer multithreading and network
rendering, but this will surely not happen before POV-Ray 4.0 :-(


     Thorsten


* Opinions expressed are my own.

Post a reply to this message

In povray.windows Halbert <hha### [at] capitalnet> wrote:
: I think I have noticed an improvement to all my 3d applications like Povray,
: MegaPov, and the swarm off modeling tools I've been using. W2k is very
: stable, me likey very much.

  Still it requires a lot more resources than should be reasonable.
  It seems that microsoft thinks "the higher the stability, the more memory
and other resources needs to be used" when it's more or less the other way
around. IIRC the recommended amount of memory for Win2k is 128MB while the
recommended amount of memory for Linux is something like 16MB.

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

isn't windows ME supposed to be the gamers' solution to an upgrade? 
it's not win2000 right?  anyone know when winME comes out?

Warp wrote:
> 
> In povray.general Rick <ric### [at] kitty5com> wrote:
> : yes but there is win2000
> 
>   Win2000 is more WinNT than Win9x. It's made more for the same uses as NT
> is rather than for games and such. I think that many win9x games don't even
> work in Win2000.
> 
>   Of course Linux (and other free unix systems) support multiple processors
> and still there is no multithreaded povray for them.
>   PVM-pov exists no more, and even when it existed it didn't work with
> radiosity.
>   Multithreading has also many other problems. It's more problematic than
> it may sound. I wrote an entry in the VFAQ about this.
> 
>   Another thing is that since it's not made by the povteam, this version will
> always be one step behind the official version.
> 
> --
> 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

I bet the memory requirements would be alot more reasonable without the web
browser, but so many things (including the system itsself) use components of
IE, there is little that can be done about that. I Tripled my memory before
I setup Windows 2000. Linux doesn't have the interated web browser ( does
it?) or alot of other little gizmos and dohickeys hanging out in memory.
But when W2k does crash, it also recovers astoundingly well (at least it
seems so when your used to Windows 95).
I like Linux too, but it isn't yet universal enough for me to use it at
home.

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3958d119@news.povray.org...
> In povray.windows Halbert <hha### [at] capitalnet> wrote:
> : I think I have noticed an improvement to all my 3d applications like
Povray,
> : MegaPov, and the swarm off modeling tools I've been using. W2k is very
> : stable, me likey very much.
>
>   Still it requires a lot more resources than should be reasonable.
>   It seems that microsoft thinks "the higher the stability, the more
memory
> and other resources needs to be used" when it's more or less the other way
> around. IIRC the recommended amount of memory for Win2k is 128MB while the
> recommended amount of memory for Linux is something like 16MB.

Post a reply to this message

linux's recomended may only be 16mb
but no one in there right mind is going to run X with only 16mb of ram....

and you will see an improvement in rendering and such switching to w2k 
since NT is a true pre-emptive multi-tasking system, where as win98 is only 
cooporative....


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

>In povray.windows Halbert <hha### [at] capitalnet> wrote:
>: I think I have noticed an improvement to all my 3d applications like
>: Povray, MegaPov, and the swarm off modeling tools I've been using. W2k
>: is very stable, me likey very much.
>
>  Still it requires a lot more resources than should be reasonable.
>  It seems that microsoft thinks "the higher the stability, the more
>  memory 
>and other resources needs to be used" when it's more or less the other
>way around. IIRC the recommended amount of memory for Win2k is 128MB
>while the recommended amount of memory for Linux is something like 16MB.
>

Post a reply to this message

It comes out soon and it is not worth it as far as I can tell.  It has
stuff for video editing and other useless junk for the most part.  I do
not know if they upgraded the mem model.  ME is a glorified version of
win98.  Microsoft wants more money, it knows stupid people will upgrade
to it.  Another reason it came about is because 2000 did not have gaming
support like it was supposed to.  

ryan constantine wrote:
> 
> isn't windows ME supposed to be the gamers' solution to an upgrade?
> it's not win2000 right?  anyone know when winME comes out?
> 
> Warp wrote:
> >
> > In povray.general Rick <ric### [at] kitty5com> wrote:
> > : yes but there is win2000
> >
> >   Win2000 is more WinNT than Win9x. It's made more for the same uses as NT
> > is rather than for games and such. I think that many win9x games don't even
> > work in Win2000.
> >
> >   Of course Linux (and other free unix systems) support multiple processors
> > and still there is no multithreaded povray for them.
> >   PVM-pov exists no more, and even when it existed it didn't work with
> > radiosity.
> >   Multithreading has also many other problems. It's more problematic than
> > it may sound. I wrote an entry in the VFAQ about this.
> >
> >   Another thing is that since it's not made by the povteam, this version will
> > always be one step behind the official version.
> >
> > --
> > 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: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

daishi wrote:

> but no one in there right mind is going to run X with only 16mb of ram....

I've tried it.  It's not pretty.  Of course, the sucky video card
contributed to its not being pretty, at least in the literal sense.

-Mark Gordon

Post a reply to this message

por### [at] pilotmsuedu (Nick Portelli) wrote in
<395927CB.8E70B8C6@pilot.msu.edu>: 

>It comes out soon and it is not worth it as far as I can tell.  It has
>stuff for video editing and other useless junk for the most part.  I do
>not know if they upgraded the mem model.  ME is a glorified version of
>win98.  Microsoft wants more money, it knows stupid people will upgrade
>to it.  Another reason it came about is because 2000 did not have gaming
>support like it was supposed to.  
>

um, like what, usb or directX? (both of which w2k has)

from the stuff I've read most games run on w2k with only a marginal 
performance hit. in my mind stability is more important then a few fps, 
this is especially true in the workstation market. 

I'm not planning to go to ME personlly, I'm gonna skip it and go straight 
to w2k, which should be right around the time I go smp. pov might not 
support smp but most professional graphics applications do. photoshop, 
lightwave, 3dsmax, etc etc

Post a reply to this message

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

> and you will see an improvement in rendering and such switching to w2k
> since NT is a true pre-emptive multi-tasking system, where as win98 is only
> cooporative....

This is not correct.  Windows 9x, NT and 2000 are all pre-emptive
multitasking systems.


     Thorsten

Post a reply to this message

In povray.general Halbert <hha### [at] capitalnet> wrote:
: But when W2k does crash

  The point is that it shouldn't.
  The efforts have been put in the wrong side of the crashing.

-- 
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:
: This is not correct.  Windows 9x, NT and 2000 are all pre-emptive
: multitasking systems.

  Win9x is only partially it.

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

> isn't windows ME supposed to be the gamers' solution to an upgrade?
> it's not win2000 right?  anyone know when winME comes out?

hardware manufacturers have ME now, and it should start appearing on oem
machines by September end.

Rick

Post a reply to this message

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