Recently, a thread about the cooperation of the PovTeam & the creator of
Lightflow has emerged in this newsgroup.  Many people seem to feel that
the Lightflow license is too restrictive (it doesn't allow a person to
sell images they create with it), and that, for this reason, Povray &
Moray should have nothing to do with it.  I'd like to make a few points:

#1. Very few people (actually, none that I know of) actually make money
using PovRay and/or Moray.  In fact, most people seem to prefer to
*share* their images/source with the rest of the Pov community.

#2. Lightflow is vastly superior to PovRay in certain areas (just look
at Lightflow's surface engine), and I think PovRay would definately
benefit from a merger of some sort.

#3. Given the huge delay between releases, I think it's safe to say the
PovTeam is in need of more programmers.  And, let's face it, the author
of Lightflow has, in a mere 5 years, single handedly implemented
features (such as distributed rendering, an accessible api, and *real*
radiosity) that the PovTeam can only dream about (no offense to the
PovTeam intended; the entire Pov community appreciates their efforts).

Don't get me wrong, I like PovRay, but I sense a growing lack of
interest amongst members of the PovTeam (of coarse, I could be way off
on this).  Also, PovRay *needs* an accessible api (I realize that this
would be difficult to implement in a portable way), and perhaps this api
could be accessed via Python.  And, most importantly, there needs to be
more interaction between the PovTeam and the Pov community.  Every 2 or
3 weeks, the PovTeam could report on the progress of the next release
(is this too much to ask?).  Of coarse, this is all just imho;-)

Hookflash

Post a reply to this message

The Ellis Family wrote:
> 
> Recently, a thread about the cooperation of the PovTeam & the creator of
> Lightflow has emerged in this newsgroup.  Many people seem to feel that
> the Lightflow license is too restrictive (it doesn't allow a person to
> sell images they create with it), and that, for this reason, Povray &
> Moray should have nothing to do with it.  I'd like to make a few points:
> 
> #1. Very few people (actually, none that I know of) actually make money
> using PovRay and/or Moray.  In fact, most people seem to prefer to
> *share* their images/source with the rest of the Pov community.
> 
> #2. Lightflow is vastly superior to PovRay in certain areas (just look
> at Lightflow's surface engine), and I think PovRay would definately
> benefit from a merger of some sort.
> 
> #3. Given the huge delay between releases, I think it's safe to say the
> PovTeam is in need of more programmers.  And, let's face it, the author
> of Lightflow has, in a mere 5 years, single handedly implemented
> features (such as distributed rendering, an accessible api, and *real*
> radiosity) that the PovTeam can only dream about (no offense to the
> PovTeam intended; the entire Pov community appreciates their efforts).
> 
> Don't get me wrong, I like PovRay, but I sense a growing lack of
> interest amongst members of the PovTeam (of coarse, I could be way off
> on this).  Also, PovRay *needs* an accessible api (I realize that this
> would be difficult to implement in a portable way), and perhaps this api
> could be accessed via Python.  And, most importantly, there needs to be
> more interaction between the PovTeam and the Pov community.  Every 2 or
> 3 weeks, the PovTeam could report on the progress of the next release
> (is this too much to ask?).  Of coarse, this is all just imho;-)
> 
> Hookflash

I suggest you read Thorsten's recent reply to the thread "responce to lack"
in povray.windows. It will aquaint you with the difficulties of writting
a distributed rendering solution as well as it will give you an insight
into the operations and goals of the POV-Team in general. After reading
that if you still have critisisms you might address them individually to
that thread and the topics it covers.

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

In article <396### [at] spamlesshotmailcom> , The Ellis Family 
<cel### [at] voyageurca>  wrote:

> #1. Very few people (actually, none that I know of) actually make money
> using PovRay and/or Moray.  In fact, most people seem to prefer to
> *share* their images/source with the rest of the Pov community.

Well, Moray is shareware.  Also, would the IRTC competition CDs used to
finance the povray.org server fall under restrictions of the Lightflow
license.

> #3. Given the huge delay between releases, I think it's safe to say the
> PovTeam is in need of more programmers.

Well, yes, the delays are there.  There are numerous reasons, the fact that
we had to leave CompuServe alone caused a few month delay!

> And, let's face it, the author
> of Lightflow has, in a mere 5 years, single handedly implemented
> features (such as distributed rendering, an accessible api, and *real*
> radiosity)

Well, five years is a long time.  Without knowing the internal structure of
Lightflow I can only say that if you design a program from ground up with
these features in mind it is faster to do than to maintain and add them to a
over ten year old source base written at a time when these features were
more theory than reality.
Also, it is not clear how cross-platform Lightflow is.  It is hard to make
any judgement about the complexity of any program without investigating the
source.
But don't get me wrong, doing such a project alone is a lot of work for
sure.  Additionally keep in mind that the developer of this project either
did not know about POV-Ray or had some reasons not to add the features to
POV-Ray in the first place.  These reasons need to be respected as well!

> that the PovTeam can only dream about (no offence to the
> PovTeam intended; the entire Pov community appreciates their efforts).

No offence taken.

> Don't get me wrong, I like PovRay, but I sense a growing lack of
> interest amongst members of the PovTeam (of coarse, I could be way off
> on this).

You are way off.  It is just a matter of time constraints.  For the Mac
there will be a completely rewritten frontend, for example.
Things like that take long to develop.

> Also, PovRay *needs* an accessible api (I realise that this
> would be difficult to implement in a portable way), and perhaps this api
> could be accessed via Python.

The question is what would you want such an API for?  It is kind of the
nature of POV-Ray to use a scene description language and just to interface
POV-Ray to a modeller you wouldn't need it.  A "small API" like the one
POV-Ray for Windows has is already enough to allow Moray to use it.

> And, most importantly, there needs to be
> more interaction between the PovTeam and the Pov community.  Every 2 or
> 3 weeks, the PovTeam could report on the progress of the next release
> (is this too much to ask?).

It is to much to ask as it would cause much more pressure on the team.  As
it is done in spare time it can happen from time to time that there is no
reportable development for a few weeks.  This may also include the
exploration of new features, reporting anything like that would increase
demand for such a feature, thus increasing pressure.

The TAG is there to improve interaction with the community.

For example it is incredible how many people just send an e-mail to a
bugreport e-mail address or a newsgroup to get help rather than just reading
one paragraph in the manual.  Then there are the real problems with doing
something special in POV-Ray.  For such issues peer support by users is much
more valuable than someone in the POV-Team who perhaps has never even used
the particular feature of POV-Ray trying to help.


Of course it is understandable that users desire a lot more features than
currently available.  It is actually very encouraging to implement those and
continue developing POV-Ray if there are a lot of users asking for new
features.  Some features are easy to add, for other features a lot of
patience is required by users.

You can be sure the POV-Team is aware of the fact that a release every two
years or so requires a lot of patience by our users, and we have and will
surely seek out ways to improve the situation.

This may take some time, so being patient (for a year or so) is probably the
best - any solutions and new ideas need to be worked out in detail, rushing
things now only to show some action in the public won't be a good idea.

For now we have to deal with releasing POV-Ray 3.5.  Once the rewrite
happens with POV-Ray 4.0, POV-Ray will surely again most (if not all) of the
frequently requested features.


      Thorsten


PS: Speaking only for myself!


____________________________________________________
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 <39621f2d@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> For now we have to deal with releasing POV-Ray 3.5.  Once the rewrite
> happens with POV-Ray 4.0, POV-Ray will surely again most (if not all) of the
> frequently requested features.

More more thing regarding the long time between releases:

When POV-Ray 3.1 we could have said we just take the next three years or so,
develop a completely new POV-Ray and there won't be any releases in the mean
time.  We did not do this because of the users of POV-Ray.  The idea was and
still is that many, many users do not need all the features at once and are
not willing to wait for them three years or more.  POV-Ray 3.5 will be one
intermediate step between a giant leap: POV-Ray 4.0.

Continuity is one major point here.  Take XFree (the free X-Windows server,
i.e. used with Linux) for example.  There has also been a redesign with
version 4.0 (this is coincidence of course).  It took many years from XFree
3.x to 4.0 and 3.x was actively developed while 4.0 was in development.

There are many people working on XFree.  It is not always a matter of the
number of people working on a project (actually, software engineering
experts have observed the contrary in many, if not all cases - too many
developers can make matters much worse due to communication overhead), it is
also the general complexity of a program in the size of POV-Ray that cannot
be eliminated and it simply takes at least two years for a major step.

Look at Windows 95, 98, 98 SE and 98 ME for example.  Surely Microsoft can
hire as many developers as many can buy, yet, a complex project simply takes
time even with all the money (no or very few resource limits) and a monopoly
(no or very little market pressure you need to consider).


Oh, and as Ken pointed to my post in povray.windows, the number of people
talented in both, programming and graduate level math, is small.

There are also people who have the knowledge and time to work on POV-Ray but
who already work for a company making a similar (meaning a renderer,
raytracer, modeller) commercial product which does not allow them to do
similar work outside the company they work for.


     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

I think, we all know that the pov-team does a lot of work. And the result is
really phantastic.
But for some months, I look from time to time to lightflow whats new ..., and
-sorry- I ask myself: should I change ? but I do not want..or should I ? or not
?..or what..?
The povray-project has my full sympathy, much more than lightflow and i would be
very sad, if I had to "leave" povray. sounds perhaps a bit emotional, and yes- it
is so.
jurek

Post a reply to this message

Thorsten Froehlich wrote:

> When POV-Ray 3.1 we could have said we just take the next three years or so,
> develop a completely new POV-Ray and there won't be any releases in the mean
> time.  We did not do this because of the users of POV-Ray.  The idea was and
> still is that many, many users do not need all the features at once and are
> not willing to wait for them three years or more.  POV-Ray 3.5 will be one
> intermediate step between a giant leap: POV-Ray 4.0.

Just a tought : it seems to me that MegaPOV, since it exists, has
somewhat
fullfilled the desire for more frequent upgrades; it's stable, reliable,
and has plenty of great additionnal features over the official release.
Maybe this could be a good developpement strategy : a famous unofficial
version for the purpose of experimentation, with frequent public
updates,
and, on the other side, the POV-Team (the "real thing" !!) working
quietly,
taking its time, on more profound changes, behind the MegaPOV curtain...
(but I realize that it can't be as simple as that, given, amongst other
issues, that some people develops in MegaPOV _and_ in the POV-Team...)

Fabien.

Post a reply to this message

Thorsten Froehlich wrote:
> > Also, PovRay *needs* an accessible api (I realise that this
> > would be difficult to implement in a portable way), and perhaps this 
api
> > could be accessed via Python.
> 

> The question is what would you want such an API for?  It is kind of the

> nature of POV-Ray to use a scene description language and just to inter
face
> POV-Ray to a modeller you wouldn't need it.  A "small API" like the one

> POV-Ray for Windows has is already enough to allow Moray to use it.

i think it is better to have _BOTH_ solutions: scene description
language and api. the api is useful to work with other programs. on
unix-systems you can use pipes, you do not need to save the (maybe
huge??) scene you can simply put the pov-file from standardoutput of



dos/windows the pipe is stored to disk and then copied to the STDIN of
the second program.

the solution with the api is a good idea. think about this: you can
write the pov-scene-parser (or parsers for other formats!) as a
standalone application wich is only linked (dynamic or static) to the
rendering engine. the users may use (if they want) a script or a program
wich calls the rendering engine. in a script or a program some things
are easier then in the scene description language. the user can choose
the method they like api or scene-file. if they decide for the api, they
can choose their favourite programming language.

well, you have to change the pov-licence..
but this is IMHO no big problem, write something like this: "the povray
rendering engine is permitted to be used from free software. you have to
say that your program uses the povray rendering engine. etc."

this was my $0.02, some other ideas?

cu stefan
-- 

"All my friends and I are crazy.  That's the only thing that keeps us
sane."

Post a reply to this message

In article <39625EB9.C0531809@gmx.de> , Stefan Moch <st_### [at] gmxde>  wrote:

> i think it is better to have _BOTH_ solutions: scene description
> language and api. the api is useful to work with other programs. on
> unix-systems you can use pipes, you do not need to save the (maybe
> huge??) scene you can simply put the pov-file from standardoutput of
> your program to the standardinput of povray.

I think this is already possible with the Unix version of POV-Ray.


      Thorsten

Post a reply to this message

Although I must admit I have great respect for Lightflow and Jacopo
Pantaleoni, I would like to say I have greater regard for the POV-Ray
project, and I'm sure that this program will be better than Lightflow in due
time. The POV-Team members are very intelligent people and excellent
programmers. I think that when they do get to work on version 4.0, seeing as
version 3.5 will really only be an official MegaPOV, they'll manage to
include equivalents to all of these features we envy from Lightflow. As
Thorsten pointed out, POV-Ray is showing it's age, and is in need of an
overhaul so that we can continue to improve on it in the future. Lightflow
is very new, and was planned from the beginning to include all of these
features which it now has. Cooperation among Jacopo and the POV-Team would
be awesome, but if it can't be arranged, well then, too bad. Anyway, we can
manage. We have some new blood assisting the Team and injecting new ideas
and improving an already great program all the time. I have faith in
POV-Ray, and I'm sure it will continue to grow, and incorporate all those
neat goodies like NURBS and tesselation and fancy APIs, and whatnot.
(Right?)



--
Anthony Bennett
POVer to the end!

Post a reply to this message

Tony, estoy totalmente de acuerdo con tigo.

Saludos, Alberto.

Post a reply to this message