No. But a friend of mine is working on exactly the idea you suggest.
I'll ask him how far he's got. If you want to contact him directly I'm
sure he won't mind me giving you his email address:
Ada### [at] INamecom
I haven't spoken with him for a week or two but he seemed to be making
rapid progress at the last check.

	Graham Redway.

Erle Greer wrote:
> 
> Does anyone know if the POV development team has considered adding parallel
> / distributed network rendering?  I have heard about couple of solutions,
> but I'd prefer a feature already built-in, and not something that I have to
> compile or figure out how to set up.
> 
> The Utopia that I imaging is that we could run POV on all clients and click
> "Parallel Client, Connect, ServerName / IP address".  Having those options
> specifiable on the command-line would be handy too.  Then, whatever scene is
> rendered on ServerName is batched or distributed out to the clients.
> 
> POV is a great program, and I'd image that they already have their hands
> full with bugs and/or feature requests.  Just thought I'd toss this out
> there.
> 
> Thank You

Post a reply to this message

GRedway wrote:
> 
> No. But a friend of mine is working on exactly the idea you suggest.
> I'll ask him how far he's got. If you want to contact him directly I'm
> sure he won't mind me giving you his email address:
> Ada### [at] INamecom
> I haven't spoken with him for a week or two but he seemed to be making
> rapid progress at the last check.
> 
>         Graham Redway.

Take a look at NetRay

http://www.studenter.hb.se/~arch/

-- 
Ken Tyler

See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Ken,

I haven't downloaded it yet but it seems a good bet. I doubt my network
held together with string would appreciate the extra load but I'll give
Adam a shout and tell him to stop work and take a look.

	Graham.
---------------------------------------------------------------------------
All opinions are my own and if you don't agree with them, ignore them,
most of the time I talk complete rubbish anyway.

Ken wrote:
> 
> GRedway wrote:
> >
> > No. But a friend of mine is working on exactly the idea you suggest.
> > I'll ask him how far he's got. If you want to contact him directly I'm
> > sure he won't mind me giving you his email address:
> > Ada### [at] INamecom
> > I haven't spoken with him for a week or two but he seemed to be making
> > rapid progress at the last check.
> >
> >         Graham Redway.
> 
> Take a look at NetRay
> 
> http://www.studenter.hb.se/~arch/
> 
> --
> Ken Tyler
> 
> See my 700+ Povray and 3D Rendering and Raytracing Links at:
> http://home.pacbell.net/tylereng/index.html

Post a reply to this message

GRedway wrote:
> 
> Ken,
> 
> I haven't downloaded it yet but it seems a good bet. I doubt my network
> held together with string would appreciate the extra load but I'll give
> Adam a shout and tell him to stop work and take a look.
> 
>         Graham.

 I just added that link to my bookmark file less that a week ago too and
found it strictly by accident. I wish people would advertise these nifty
little add ons so I don't have to luck into them.

-- 
Ken Tyler

See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote in article
<37B349FA.A46CEDE4@pacbell.net>...
> Take a look at NetRay
> 
> http://www.studenter.hb.se/~arch/
> 
> Ken Tyler

I went to Mikael's page at http://www.studenter.hb.se/~arch/ and his
distributed POV system looks interesting, and promising.  I especially like
the fact that the server and clients are referred to, and communicate via,
IP addresses, allowing scallability across the Internet.  It would be
really nice to be able to sit at home send render jobs to our university
lab computers. (yes, I work there and would have permission).

Mikael does not provide a download link, so I've requested via email to
help test his system on my network.

I still think that John Cruz's Java approach, R-Cast, at
http://www.geocities.com/SiliconValley/Network/4453/rfarm/  holds much
promise, offering cross-platform support.

Still, the horse to win is built-in network rendering in POV itself.

I read somewhere that a problem with distributing a single frame is when
attempting to anti-alias, because a client would have no knowledge of
previous lines that another client had or will be rendering.

Post a reply to this message

> Erle Greer wrote:
> > Does anyone know if the POV development team has considered adding
parallel
> > / distributed network rendering?  I have heard about couple of
solutions,
> > but I'd prefer a feature already built-in, and not something that I
have to
> > compile or figure out how to set up.

GRedway <GRe### [at] Totalisecouk> wrote in article
<37B306EE.A938CAB8@Totalise.co.uk>...
> No. But a friend of mine is working on exactly the idea you suggest.
> I'll ask him how far he's got. If you want to contact him directly I'm
> sure he won't mind me giving you his email address:
> Ada### [at] INamecom
> I haven't spoken with him for a week or two but he seemed to be making
> rapid progress at the last check.

Thank you, I have emailed a request and hope that he has had some success
with his project.

Post a reply to this message

Is this possible without breaking the portability rule of povray?

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

Another issue is that the radiosity code has to be modified in order to
be able to be calculated in parts.

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

Erle Greer wrote:

> Does anyone know if the POV development team has considered adding parallel
> / distributed network rendering?

<snip>

I think PVM-POV meets these criteria, though it's only for the UNIX (AFAIK) and
is five kinds of hell to install.

E.

Post a reply to this message

"Erle Greer" <greere_Spam_Me_Not_@evangel.edu> wrote:

>Does anyone know if the POV development team has considered adding parallel

Yes. I can't say if it'll be this century though. I hope to have a demo testbed
based around 3.1x later this year but I can't promise anything.

Post a reply to this message

On Mon, 16 Aug 1999 16:00:54 GMT, newsadmin@[remove]povray.org
(POV-Ray Newsadmin) wrote:

>"Erle Greer" <greere_Spam_Me_Not_@evangel.edu> wrote:
>
>>Does anyone know if the POV development team has considered adding parallel
>
>Yes. I can't say if it'll be this century though. I hope to have a demo testbed
>based around 3.1x later this year but I can't promise anything.

< wipes saliva from lip, trying not to appear too anxious, hits
refresh awaiting beta test notice... sigh... refresh... nope...
refresh >

Post a reply to this message

On Thu, 12 Aug 1999 17:19:51 -0700, Ken <tyl### [at] pacbellnet> wrote:
[snip]
> I just added that link to my bookmark file less that a week ago too and
>found it strictly by accident. I wish people would advertise these nifty
>little add ons so I don't have to luck into them.
>
>-- 
Ah, but then you wouldn't be held in as much awe if *anyone* could
find the links because they're posted in front of our eyes.

Maybe you could do a tutorial page - "How to find the impossible" and
slap it up on the web?

Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

Post a reply to this message

Cliff Bowman wrote:
> 
> On Thu, 12 Aug 1999 17:19:51 -0700, Ken <tyl### [at] pacbellnet> wrote:
> [snip]
> > I just added that link to my bookmark file less that a week ago too and
> >found it strictly by accident. I wish people would advertise these nifty
> >little add ons so I don't have to luck into them.
> >
> >--
> Ah, but then you wouldn't be held in as much awe if *anyone* could
> find the links because they're posted in front of our eyes.
> 
> Maybe you could do a tutorial page - "How to find the impossible" and
> slap it up on the web?
> 
> Cheers,
> 
> Cliff Bowman
> Why not pay my 3D Dr Who site a visit at http://www.who3d.cwc.net/

How to find the impossible ? Just go to my links page sheeesh !

-- 
Ken Tyler

See my 700+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Nieminen Mika <war### [at] cctutfi> wrote:

> Another issue is that the radiosity code has to be modified in
> order to be able to be calculated in parts.

Why is it not posible to render a picture with radiosity in parts? Does 
this mean +SRn and +ERn must not be used with radiosity scenes? I 
couldn't find any hint in the documentation.

Regards
Sven

Post a reply to this message

In article <Xns### [at] sirius666de> , Sven Heinzel
<Sir### [at] gmxnet>  wrote:

> Why is it not posible to render a picture with radiosity in parts? Does
> this mean +SRn and +ERn must not be used with radiosity scenes? I
> couldn't find any hint in the documentation.

Well, you can of course use them, but when assembling the picture it will
not look like you expect (it will not be identical to a whole render of the
same scene).  It has to do with the way the method called radiosity in
POV-Ray works.  It is a fundamental property of the method and cannot easily
be changed, just take Warps (and my) word for it.

    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

Using pretrace_start 1 and pretrace_end 1 should do the trick though...

--
Jonathan.
"Thorsten Froehlich" <tho### [at] trfde> ha scritto nel messaggio
news:3bfd49a5$1@news.povray.org...
> In article <Xns### [at] sirius666de> , Sven Heinzel
> <Sir### [at] gmxnet>  wrote:
>
> > Why is it not posible to render a picture with radiosity in parts? Does
> > this mean +SRn and +ERn must not be used with radiosity scenes? I
> > couldn't find any hint in the documentation.
>
> Well, you can of course use them, but when assembling the picture it will
> not look like you expect (it will not be identical to a whole render of
the
> same scene).  It has to do with the way the method called radiosity in
> POV-Ray works.  It is a fundamental property of the method and cannot
easily
> be changed, just take Warps (and my) word for it.
>
>     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

JRG wrote:
> 
> Using pretrace_start 1 and pretrace_end 1 should do the trick though...
> 

But this can be much slower and can lead to worse results in some
situations.  As a rule of thumb you can say it works quite well with low
error_bound, but it depends on the situation.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Slower?

--
Jonathan.
"Christoph Hormann" <chr### [at] gmxde> ha scritto nel messaggio
news:3BFD5584.64374532@gmx.de...
>
>
> JRG wrote:
> >
> > Using pretrace_start 1 and pretrace_end 1 should do the trick though...
> >
>
> But this can be much slower and can lead to worse results in some
> situations.  As a rule of thumb you can say it works quite well with low
> error_bound, but it depends on the situation.
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> IsoWood include, radiosity tutorial, TransSkin and other
> things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

JRG wrote:
> 
> Slower?
> 

Yes.

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

I always thought it was much faster (and all my tries confirmed that).

"Christoph Hormann" <chr### [at] gmxde> ha scritto nel messaggio
news:3BFD67EE.D79047A0@gmx.de...
>
>
> JRG wrote:
> >
> > Slower?
> >
>
> Yes.
>
> --
> Christoph Hormann <chr### [at] gmxde>
> IsoWood include, radiosity tutorial, TransSkin and other
> things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Distributing rendering in chunks is rather crude, it is far better to write 
code that spreads computational loops and recursion etc. over as many 
threads as possible and then run the code on a MOSIX cluster where the 
operating system automatically distributes the threads among the available 
CPUs.

I mentioned this recently as but got zero replies.
:o(

I wanted to know if anyone has profiled POVRay to see where all the work 
was being done so that I could use the Cilk system to create a massively 
threaded version of POVRay that could run across a MOSIX cluster.

There is also a PVM version of POV but last time I looked it was based on 
an old version. I was hoping to look at the 3.5 source code some time soon 
and use that as a basis for a Cilk-MOSIX_Povray variant.

This would have to be the Linux/Unix version as MOSIX is not an option for 
a closed source operating system such as Windows, unless Microsoft make a 
MOSIX version of Windows XP (XS?) :o)  available.


Sven Heinzel wrote:

> Nieminen Mika <war### [at] cctutfi> wrote:
> 
>> Another issue is that the radiosity code has to be modified in
>> order to be able to be calculated in parts.
> 
> Why is it not posible to render a picture with radiosity in parts? Does
> this mean +SRn and +ERn must not be used with radiosity scenes? I
> couldn't find any hint in the documentation.
> 
> Regards
> Sven

Post a reply to this message

In article <355### [at] 3-enet>, dan### [at] 3-enet says...
> Distributing rendering in chunks is rather crude, it is far better to write 
> code that spreads computational loops and recursion etc. over as many 
> threads

Why? I think, for performance, this is worse then rendering chunks, 
because the OS also needs CPU time for assigning tasks to each CPU.
And the more often the different threads/tasks change/interact, the more 
time it needs. So, for maximum performance it should IMHO be best to 
split the rendering in exactly as many different tasks as there are CPUs 
available, and then let each of them do their work completely on their 
own.

Lutz-Peter

Post a reply to this message

Also, we need a "binary" scene file, that the parsed scene can be stored in.
That way, the scene is parsed once, stored in a shared file (or the file can be
shipped to each rendering engine), then rendered by the farm.  Perhaps more
efficient than each render-farm element parsing the same scene in order to render
"chunks" of it.

Randy Hawley

Lutz-Peter Hooge wrote:

> In article <355### [at] 3-enet>, dan### [at] 3-enet says...
> > Distributing rendering in chunks is rather crude, it is far better to write
> > code that spreads computational loops and recursion etc. over as many
> > threads
>
> Why? I think, for performance, this is worse then rendering chunks,
> because the OS also needs CPU time for assigning tasks to each CPU.
> And the more often the different threads/tasks change/interact, the more
> time it needs. So, for maximum performance it should IMHO be best to
> split the rendering in exactly as many different tasks as there are CPUs
> available, and then let each of them do their work completely on their
> own.
>
> Lutz-Peter

Post a reply to this message

In article <355### [at] 3-enet> , Daniel Matthews <dan### [at] 3-enet>  
wrote:

> Distributing rendering in chunks is rather crude, it is far better to write
> code that spreads computational loops and recursion etc. over as many
> threads as possible and then run the code on a MOSIX cluster where the
> operating system automatically distributes the threads among the available
> CPUs.
>
> I mentioned this recently as but got zero replies.
> :o(

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


____________________________________________________
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 <3BFDCF57.4026E69A@iquest.net> , Randy Hawley 
<rha### [at] iquestnet>  wrote:

> Also, we need a "binary" scene file, that the parsed scene can be stored in.
> That way, the scene is parsed once, stored in a shared file

It won't help increase the speed of parsing because most of the time is
spend on memory allocation (and processing #macros if you have them).

So there would be no fundamental improvement, but the implementation would
be rather time consuming and a lot of cross-platform issues would have to be
handled.  In conclusion, while it isn't impossible to modify POV-Ray to
output a "binary scene file" (it has been done before with 2.2), it doesn't
solve any problems, it just adds more problems.

    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

On Thu, 22 Nov 2001 23:23:52 -0500, Randy Hawley <rha### [at] iquestnet> wrote:

> Also, we need a "binary" scene file, that the parsed scene can be stored in.
> That way, the scene is parsed once, stored in a shared file (or the file can be
> shipped to each rendering engine), then rendered by the farm.

IMO it has sense only if the "binary" format supports constructions like
#macros, #while etc. Sometimes could be  more efficent to send short script with
#while(N<10000) and parse it on place instead of unrolled "binnary" list of
objects with slow bandwidth.

Also I wonder how accuracy problem will work when platforms on the farm will
support different accuracy.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

Perhaps my statements would make more sense when I describe what I would be thinking
about putting together as my "rendering farm".

I own one "fast" computer (albeit not all that fast anymore), and several older, much
slower machines (all Wintel boxes right now - but I am considering dual-booting my
good one with Linux).  They are all networked on a 10Meg ethernet.

The fast computer may be able to parse some scenes about 100 times faster than the
slower ones.  It may be possible to transfer the memory constructs created by the
parsing process to the slower machines faster than they could generate them.  This
would be even more possible were I to have a 100 Meg ethernet.

So, I have a dream.  It may not be practical, but it is a dream.

The "accuracy problem" is supposed to be addressed by the POV program.  The team
mentions that it has worked to keep cross-platform problems at a minimum, including
random number generation.  I don't know enough about the differences in CPU
architecture to speak to differing accuracies in floating-point operations.

Randy Hawley

"W³odzimierz ABX Skiba" wrote:

> On Thu, 22 Nov 2001 23:23:52 -0500, Randy Hawley <rha### [at] iquestnet> wrote:
>
> > Also, we need a "binary" scene file, that the parsed scene can be stored in.
> > That way, the scene is parsed once, stored in a shared file (or the file can be
> > shipped to each rendering engine), then rendered by the farm.
>
> IMO it has sense only if the "binary" format supports constructions like
> #macros, #while etc. Sometimes could be  more efficent to send short script with
> #while(N<10000) and parse it on place instead of unrolled "binnary" list of
> objects with slow bandwidth.
>
> Also I wonder how accuracy problem will work when platforms on the farm will
> support different accuracy.
>
> ABX
> --
> #declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
> union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
> function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
> contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

Just a general comment:
The discussion of parallel rendering, a binary scene file format and/or
other radical scene description changes are suggested every few month.
However, everything has been said before and the decision to implement
either is not in the hands of those discussing it.  So no need for to people
waste their energy and time to discuss things they can neither change at the
moment nor will be responsible to change in the future...

    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> Just a general comment:
> The discussion of parallel rendering, a binary scene file format and/or
> other radical scene description changes are suggested every few month.
> However, everything has been said before and the decision to implement
> either is not in the hands of those discussing it.  So no need for to people
> waste their energy and time to discuss things they can neither change at the
> moment nor will be responsible to change in the future...
> 
>     Thorsten
> 

"We know what is good for you".

Disclaimer: I really appreciate the hard work done by the pov team, a 
part of which includes the extremely long, painful and not rewarding 
process of hardening, packaging, and documenting the software we all use 
and enjoy.

Now, while I regret that these often sterile discussions always pop up 
from people who did not inquire about what has already been done and 
always want to reinvent the wheel (there are at least 5 different 
distributed versions after POVRay 3.1), this kind of statement sounds 
like an insult to me.

Following your often repeated statements, a good world would be a world 
without anybody implementing anything except under the official control 
of the One Team. A world without patches. A world without macros, 
isosurfaces, improved radiosity, light and vista buffers to quote a few, 
just because people discussing about them do not have the power to 
decide whether these features should be implemented or not.

If people want to try something, just let them do it. Even the current 
POVLEGAL allows them to. You won't believe me: it even encourages them 
to. Many of us are not professional programmers, thus the code resulting 
from our work is often bugged, poorly written, docummented and so on. 
But why should we not try to do things if:
- They do not exist
- We need them for some reason
- We have the will and the knowledge to implement them

Do you think that people who would think it nice to have a generic 
particle system, or something about cloth-like surfaces, or 
post-processing, or motion blur will just start thinking "this guy is 
right: we are not entitled to add our crap to the official work, let's 
stop our outrage"? I hope not. Call this proof of concept if you want, 
but let them discuss and try to implement and improve their ideas.

-- 
François DISPOT  --  http://www.wozzeck.net
       __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

François Dispot <woz### [at] club-internetfr> wrote:
: If people want to try something, just let them do it.

  Did he say that people shouldn't try? I didn't see him saying that.
I think that he was talking about _discussions_ about the issue (if I
understood correctly, discussions of type "someone should do this and
this").

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

>   Did he say that people shouldn't try? I didn't see him saying that.
> I think that he was talking about _discussions_ about the issue (if I
> understood correctly, discussions of type "someone should do this and
> this").

it came across as "please stop talking about this, its been discussed to
death before, its far to difficult, you should be happy with the explanation
in the vfaq"

sorry, but parallel \ distributed rendering is a feature that I for one
really need, and the lack of such a feature in current versions (or in any
foreseeable future versions) is one of the main reasons I do not use pov
(commercial & hobby) as much as I would like.


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

In article <3C0### [at] club-internetfr> , François Dispot 
<woz### [at] club-internetfr>  wrote:

> "We know what is good for you".

No, I didn't say that.  I just noticed discussion 1825 of the *same*
features.  And all these features have been publicly commented on by the
POV-Team.  The team has always said "we want parallel rendering in 4.0", the
team also rejected a "binary scene file format".  And the team surely does
not plan to support "other radical scene description changes", i.e. the
Python script language idea that come up twice in the past in another place
(not referring to this thread).  All three usually are suggested over  and
over again by people who at first don't realize all the difficult aspects
involved.  See below...

> Disclaimer: I really appreciate the hard work done by the pov team, a
> part of which includes the extremely long, painful and not rewarding
> process of hardening, packaging, and documenting the software we all use
> and enjoy.

No, it is the process of fixing all the patches who are half-done, buggy,
incomplete, quick hacks :-(  Wait until you see the 3.5 source code and you
will be surprised how little is actually MegaPOV code...

> Now, while I regret that these often sterile discussions always pop up
> from people who did not inquire about what has already been done and
> always want to reinvent the wheel (there are at least 5 different
> distributed versions after POVRay 3.1), this kind of statement sounds
> like an insult to me.

Yes, and how many of those parallel versions is more than a quick hack?  The
simple answer is:  None!  --  It wouldn't take the POV-Team more than a few
days to do the same.  Saying we don't for some reason other than those
patches being unusable for 99.5% of all users and purposes is an insult as
well *.  But instead of anybody attempting to change radiosity to work in
parallel and to have one implementation, there are (as you say, I didn't
count) five implementations of parallel versions and none of them does the
whole job.

Or are you waiting for the POV-Team to dig into the uncommented quick hacks
of others and fix them?  Sorry, but we are not the quick-and-dirty hack
fixup group!

> Following your often repeated statements, a good world would be a world
> without anybody implementing anything except under the official control
> of the One Team. A world without patches. A world without macros,
> isosurfaces, improved radiosity, light and vista buffers to quote a few,
> just because people discussing about them do not have the power to
> decide whether these features should be implemented or not.

No, but it would be nice if people would actually think more than five
seconds about something before they implement it in a half-working way and
the release it to the public.  For example Chris Young had to rewrite the
original macro patch because it was so unstable and dirty.  And this has
happened with every other patch in 3.5.

Most patches were integrated over two years ago and ever since we have been
fixing them.  Look at the light_groups patch in MegaPOV: It had the worst
possible syntax, a limit of 32 light groups (because the author had the
great idea to use a bitfield to assign lights and objects to groups) and it
didn't actually work the way it should.  Now it is in 3.5 and new bugs are
discovered.  The difference is that the POV-Team has committed itself to
this feature and it is now our job to fix it.  If it had been done "right"
the first time we would not have this situation now :-(

Don't get me wrong, I do not say all patches are bad and nobody should make
any patches.  What I am saying is those who make their patches should
actually finish them!

Or, at the very least should _try_ to do a good job.  Don't take this the
wrong way, but everybody has different talents.  Unfortunately many people
read one book about C and think they are programmers.  They are as wrong as
they can be, and the code they write usually demonstrates this very well :-(

> Do you think that people who would think it nice to have a generic
> particle system, or something about cloth-like surfaces, or
> post-processing, or motion blur will just start thinking "this guy is
> right: we are not entitled to add our crap to the official work, let's
> stop our outrage"? I hope not. Call this proof of concept if you want,
> but let them discuss and try to implement and improve their ideas.

None of these is in 3.5 for some or all the above reasons.  Now it is there.
Doesn't really work and people ask the POV-Team to add it.  Then, all of a
sudden, the same people suddenly expect it to work flawlessly.

This is not what the license intended and it didn't work this way until
before there was the internet.  These days every cat and mouse have their
own IP and think they can program :-(

    Thorsten

* They don't even scale well.  More than four or five systems and they fail.
They also don't handle problems like failing nodes.  All this has been
reported before.  I don't have the time to find internet references for you,
but there are several...

____________________________________________________
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 <3c003eeb$1@news.povray.org> , "Rick [Kitty5]" <ric### [at] kitty5com>
wrote:

> it came across as "please stop talking about this, its been discussed to
> death before, its far to difficult, you should be happy with the explanation
> in the vfaq"

Well, this kind of is the idea.  Yes.

> sorry, but parallel \ distributed rendering is a feature that I for one
> really need, and the lack of such a feature in current versions (or in any

You did apparently miss the various occasions the POV-Team has acknowledged
parallel rendering as a feature for 4.0 (if it is possible).

> foreseeable future versions) is one of the main reasons I do not use pov
> (commercial & hobby) as much as I would like.

Please stop whining.


    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> > foreseeable future versions) is one of the main
> > reasons I do not use pov (commercial & hobby)
> > as much as I would like.

> Please stop whining.

Whining is a tone of voice, primary component being
sound.  Plain text cannot convey whining unless the
writer notes that they are doing so.  It amazes me
how people associate vocal inflection to raw text,
assigning their own meaning which might not be there.

-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Thorsten Froehlich wrote:
> Unfortunately many people read one book about C and
> think they are programmers.  They are as wrong as
> they can be, and the code they write usually
> demonstrates this very well :-(

You're missing the distinction between being a
programmer and being a programmer who writes
good code.  If someone writes a program, no matter
how useless, or how badly coded, even just one
that outputs "Hello world", they are by definition
a programmer (i.e. "one who makes programs").

If I had the need for a feature that POV didn't
have and the ability to throw together a patch
that allowed me to do what I desired, why would
I spend more effort than absolutely necessary
to achieve the effect I want (i.e. make it
usable by anybody other than myself, with clean
code, documentation, the works) if all I need
it for is one or two images?  If someone else
finds the patch useful, fine, but if it doesn't
work the way THEY want, who cares?
-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

In article <3C00E238.DFE8D4AA@scifi-fantasy.com> , "Timothy R. Cook" 
<tim### [at] scifi-fantasycom> wrote:

> You're missing the distinction between being a
> programmer and being a programmer who writes
> good code.  If someone writes a program, no matter
> how useless, or how badly coded, even just one
> that outputs "Hello world", they are by definition
> a programmer (i.e. "one who makes programs").

So a monkey with paint and paper is a painter?

If you think so, fine, but then we just don't agree on the definition.  And
I think my definition is very clear in what I wrote.  So no need to start a
war over it.

    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

In article <3C00DFC7.2977B6DC@scifi-fantasy.com> , "Timothy R. Cook" 
<tim### [at] scifi-fantasycom> wrote:

> Whining is a tone of voice, primary component being
> sound.  Plain text cannot convey whining unless the
> writer notes that they are doing so.  It amazes me
> how people associate vocal inflection to raw text,
> assigning their own meaning which might not be there.

Wrong.  This is just one definition of it.  Try "to complain or protest in a
childish fashion"...

    Thorsten

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
: You're missing the distinction between being a
: programmer and being a programmer who writes
: good code.  If someone writes a program, no matter
: how useless, or how badly coded, even just one
: that outputs "Hello world", they are by definition
: a programmer (i.e. "one who makes programs").

  Knowing a programming language is far different from knowing programming.
  He is right. It's sad how many people *think* they know programming when
in reality they have no clue.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Warp wrote:
> Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
> : You're missing the distinction between being a
> : programmer and being a programmer who writes
> : good code.  If someone writes a program, no matter
> : how useless, or how badly coded, even just one
> : that outputs "Hello world", they are by definition
> : a programmer (i.e. "one who makes programs").
>
>   Knowing a programming language is far different from knowing
programming.
>   He is right. It's sad how many people *think* they know programming when
> in reality they have no clue.

Which doesn't mean they are not allowed to make their own changes to the
code and make them available in their websites. Probably they will never be
members of the POV Team :) but not having your programming skill can't be a
guilt.

--
Jonathan.

Post a reply to this message

François Dispot wrote:

> "We know what is good for you".

That should read -

"Based on 10 years of experience we know what is good for the majority of
you".

-- 
Ken Tyler

Post a reply to this message

Thorsten Froehlich wrote:
> So a monkey with paint and paper is a painter?

Hmm, that'd actually be kinda cool ;)
-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

I saw elephants doing that.

--
Jonathan.

"Timothy R. Cook" <tim### [at] scifi-fantasycom> ha scritto nel messaggio
news:3C014522.5DE67C4D@scifi-fantasy.com...
> Thorsten Froehlich wrote:
> > So a monkey with paint and paper is a painter?
>
> Hmm, that'd actually be kinda cool ;)
> --
> Tim Cook
> http://empyrean.scifi-fantasy.com
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
> N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
> PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
> D++(---) G(++) e*>++ h+ !r--- !y--
> ------END GEEK CODE BLOCK------

Post a reply to this message

> > "We know what is good for you".
>
> That should read -
>
> "Based on 10 years of experience we know what is good for the majority of
> you".

but with the CG industry moving so quickly, 10 years of experience might
just as well make you irrelevant


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

> > it came across as "please stop talking about this, its been discussed to
> > death before, its far to difficult, you should be happy with the
explanation
> > in the vfaq"
>
> Well, this kind of is the idea.  Yes.
>
> > sorry, but parallel \ distributed rendering is a feature that I for one
> > really need, and the lack of such a feature in current versions (or in
any
>
> You did apparently miss the various occasions the POV-Team has
acknowledged
> parallel rendering as a feature for 4.0 (if it is possible).
>
> > foreseeable future versions) is one of the main reasons I do not use pov
> > (commercial & hobby) as much as I would like.
>
> Please stop whining.

after you...

if you feel unable to add to in a constructive manner, please restrain
yourself from joining in, if the 'constant' discussion of this topic upsets
you, remember that you don't have to read the threads.

If you doubt that this feature is even possible (or even really needed) does
not mean that it cannot and should not be done. This is such a radical
feature that will require radical changes to the way povray works and is
used, and in that quest nothing that povray does to date should be allowed
to prevent it.

Even if that means POV stops with 3.5 and version 4 is a new beast by the
same name with no other new features aside from this one.

The possibilities for the way povray can be used, both for hobbyists and
professionals are frankly, staggering.

--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

"Rick [Kitty5]" wrote:
> 
> > > "We know what is good for you".
> >
> > That should read -
> >
> > "Based on 10 years of experience we know what is good for the majority of
> > you".
> 
> but with the CG industry moving so quickly, 10 years of experience might
> just as well make you irrelevant

I have always been irrelevant.

-- 
Ken Tyler

Post a reply to this message

In article <3c01a1e6@news.povray.org> , "Rick [Kitty5]" <ric### [at] kitty5com> 
wrote:

> if you feel unable to add to in a constructive manner, please restrain
> yourself from joining in, if the 'constant' discussion of this topic upsets
> you, remember that you don't have to read the threads.

In case you missed it, I only commented on the discussion and its point.  A
discussion in a two year old thread, after all...

    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

"Rick [Kitty5]" wrote:
> 
> > > "We know what is good for you".
> >
> > That should read -
> >
> > "Based on 10 years of experience we know what is good for the majority of
> > you".
> 
> but with the CG industry moving so quickly, 10 years of experience might
> just as well make you irrelevant

"Ten years of experience" is not the same as "Ten-years-old experience".
The latter might make you irrelevant, not the first one.

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

> I have always been irrelevant.

Just what we like to hear :P


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

"Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
news:3c018f03$2@news.povray.org...
> > > "We know what is good for you".
> >
> > That should read -
> >
> > "Based on 10 years of experience we know what is good for the majority
of
> > you".
>
> but with the CG industry moving so quickly, 10 years of experience might
> just as well make you irrelevant

Heh - like the "EBusiness" model, making old business practices obselete?
Investors saying they don't need Warren Buffet, they've got Tech stocks?

I'd say listen to the pros.  You don't have to do what they say, but at
least -listen- to them!

...Chambers

Post a reply to this message

Sure write your patches although keep it separate from the povray source unless your
willing to continue working on your patch, cause that's half of what programming is.
If a patch is added to povray it has to be thoroughly tested before it is officially
added.

/Jens

On Sun, 25 Nov 2001 07:21:12 -0500
"Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:

> Thorsten Froehlich wrote:
> > Unfortunately many people read one book about C and
> > think they are programmers.  They are as wrong as
> > they can be, and the code they write usually
> > demonstrates this very well :-(
> 
> You're missing the distinction between being a
> programmer and being a programmer who writes
> good code.  If someone writes a program, no matter
> how useless, or how badly coded, even just one
> that outputs "Hello world", they are by definition
> a programmer (i.e. "one who makes programs").
> 
> If I had the need for a feature that POV didn't
> have and the ability to throw together a patch
> that allowed me to do what I desired, why would
> I spend more effort than absolutely necessary
> to achieve the effect I want (i.e. make it
> usable by anybody other than myself, with clean
> code, documentation, the works) if all I need
> it for is one or two images?  If someone else
> finds the patch useful, fine, but if it doesn't
> work the way THEY want, who cares?
> -- 
> Tim Cook
> http://empyrean.scifi-fantasy.com
> 
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
> N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
> PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
> D++(---) G(++) e*>++ h+ !r--- !y--
> ------END GEEK CODE BLOCK------

Post a reply to this message