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
your program to the standardinput of povray. on other os´s (some people

want to use them, some have to..) this won´t work. AFAIK e.g. on
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?)

Mis dos centésimos...

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

The Ellis Family <cel### [at] voyageurca> wrote...

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

That is an interesting idea, though I'm not sure if the author of Lightflow
would feel the same way.  If I understand correctly, Lightflow Tech is a
for-profit company, and therefore the technology in the Lightflow engine is
probably intended to be kept within the company.  If Mr. Pantaleoni would
like to share his knowledge with us, I for one would be interested.

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

Back a few years ago, the team appeared to experience burnout (I say this
from what I observed from the outside at that time), which was in-part
caused by some rude actions on the part of the internet community.  Since
then, the attitudes within the team have changed, and there is now a true
desire to see POV grow and mature.

> Also, PovRay *needs* an accessible api (I realize that this
> would be difficult to implement in a portable way)

The current philosophy of POV is to transfer all scene data to the rendering
engine via the scene definition language.  There are both pros and cons to
this approach.  You will need to back up your claim (and address a number of
important issues) before you can convince everyone that POV *needs* an
accessible API.

Important issues:
1) cross-platform compatibility
2) consistent scene descriptions (more than one file format would be bad)
3) ease-of-use - POV is designed first for artists, then for programmers

> And, most importantly, there needs to be
> more interaction between the PovTeam and the Pov community.

We are addressing this issue through the POV Technical Assistance Group
(TAG).

> Every 2 or
> 3 weeks, the PovTeam could report on the progress of the next release
> (is this too much to ask?).

This may be possible, but we wish to avoid vaporware.  Also, because our
Real Lives get in the way of POV development, we don't want to promise a
release on a certain date and then not be able to fulfil that.  Such action
could cause us to get more rude responses from the internet community (not
necessarily those who read these groups), which could cause the POV-Team to
feel discouraged again.  And I think we all agree that such a thing would be
bad.

-Nathan Kopp

I speak for myself and not for the POV-Team.

Post a reply to this message

Fabien Mosen <fab### [at] skynetbe> wrote...
> (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...)

Actually, it has been good that I have been able to work with both MegaPov
and POV 3.5.  It made it easier to get MegaPov features into POV 3.5.  Also,
we really wish to prevent a "split" in POV development (as has been
happening with Linux development).  Because I have been able to keep an eye
on both sides (official 3.5 and unofficial MegaPov), it has helped a lot to
prevent such a split.

-Nathan Kopp

I speak for myself and not for the POV-Team.

Post a reply to this message

Nathan Kopp wrote:

> > And, most importantly, there needs to be
> > more interaction between the PovTeam and the Pov community.
> 
> We are addressing this issue through the POV Technical Assistance Group
> (TAG).

Along with the co-operation of the TAG the POV-Team themselves
are not altogether inactive in these groups. Within the last 7
days for example we have seen messages posted from:

Chris     Cason       - The POV-Team Co-ordinator
Nathan    Kopp        - Programmer and Windows    developer
Ron       Parker      - Programmer and Windows    developer
Thorsten  Froehlich   - Programmer and Macintosh  developer
Mark      Gordon      - Programmer and Unix/Linux developer
Alan      Kong        - POV-Team Member
Alexander Enzmann     - POV-Team Member (semi-retired)
Lutz      Kretzschmar - POV-Team Member
Thomas    Baier       - POV-Team Member

I would dare say that is pretty active  involvement in the POV-Ray
community by members of the POV-Team. They should be commended for
their active involvement in these groups rather than critisized for
their lack of 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

Just an idea..
-what about making shareware like moray ?
-buy with this money "programming-time" for "unimportant or easy to do"
features..
jurek

Post a reply to this message

In article <3962CC0D.4FC703A7@yahoo.com> , jurek <jur### [at] yahoocom>  
wrote:

> -what about making shareware like moray ?
> -buy with this money "programming-time" for "unimportant or easy to do"
> features..

Then you could buy a commercial software in the first place!

Maybe this answer, written a long time ago by Eduard Schwan (POV-Ray Mac
developer for nine years) and currently included in the Mac OS documentation
can explain this much better:

>>

Why does the team do this for free?
Here's a letter I sent somebody long ago to explain the mission of the team:

"Thank you very much for your interest in compensating us team members
somehow, and I personally appreciate your excitement and enthusiasm, as do
the other team members, and in fact, that's mostly what we live for!  But as
far as any kind of compensation goes, it turns out to be a really difficult
thing to deal with *fairly*.  First, we are spread all over the world, USA,
Germany, Holland, Australia, Denmark, etc...  Second of all, different team
members have been on "the team" for different lengths of time and
contributed different amounts of work.  I for example, have been on the team
for several years, but only contributed a couple of things to the main
cross-platform POV-Ray engine (most notably the Mosaic Preview.)  I am the
Mac OS team member, and have lately been single-handedly building the Mac OS
front-end for POV-Ray.  Third, this is being run as a cooperative
distributed hobby, not a for-profit business.  So let's say we pour a bunch
of money into a pot somewhere, who gets what percentage? Do I get the same
percentage as Chris Young who has put more work into the project in the past
few months than I have in the past few years?  Do we all get free Microsoft
Windows compilers, useless to me and the Unix guys. Mostly what happens is
our nice team comeraderie turns into a bitter feud for divvying up the
spoils (BTW, this is spoken from direct team experience from long ago.)  So
instead, each of us uses the ray tracer to make friends, show off, create
cool movies, write and sell books and CD-ROMs, etc.  Since the team treats
this as a spare time fun activity, the joy we get comes from lots of people
doing great things with POV-Ray, simple as that.  This also explains why it
takes some time for us to come out with new versions... we are working on it
in what little time there is between career and family.

Hopefully this helps explain some of the problems involved in getting money
for a team hobby.  Also, please note that this is my personal set of
opinions and observations as a POV-Ray Team member, but I do not speak for
any other team members or the team as a whole.  Other team members may feel
differently, and that is part of what makes this such a wonderful group of
people to work with!

Happy Ray Tracing, and go show POV-Ray to your friends and coworkers! Eduard
Schwan -- POV-Ray Team Mac Dude"

<<


     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

On Wed, 05 Jul 2000 09:25:05 +0200 "Thorsten Froehlich"
<tho### [at] trfde> wrote:

<snip..>
>Happy Ray Tracing, and go show POV-Ray to your friends and coworkers! Eduard
>Schwan -- POV-Ray Team Mac Dude

  <sniff> You've done an admirable job since Eduard left to pursue RL®
(Real Life) projects, Thorsten. I don't mind saying this in public <s>.

-- 
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer

Post a reply to this message

Thorsten Froehlich wrote:
> 

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

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

Yes, of course.
(Maybe I´ve written the sentence wrong.)
But it is not possible on other operating systems, and (believe me or
not) I know a lot of people with a non-unix os. And even on unix the api
may sometimes be the better way then piping the pov-file.
The api has also another advantage (an advantage for the
pov-developers!). You can make pov more modular. The programmers who
write the scene-file parser use everytime the same api and the
programmers who work on the renderer can add new rendering techniques,
etc.. In the scene-file parser only a few things need to be changed (to
find out wich rendering technique the user want and tell it the
renderer).

cu Stefan
-- 

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

Post a reply to this message

Nathan Kopp wrote:
> 
> > Also, PovRay *needs* an accessible api (I realize that this
> > would be difficult to implement in a portable way)
> 
> The current philosophy of POV is to transfer all scene data to the rendering
> engine via the scene definition language.  There are both pros and cons to
> this approach.  You will need to back up your claim (and address a number of
> important issues) before you can convince everyone that POV *needs* an
> accessible API.

as i wrote in an article above: why not both solutions?
the scene-file for the artists, and the api for other programs. why not
let the scene-file parser simply call the api. the code can be more
modular and clearer.

the cross-platform thing:
well on systems like msdos (and other systems supported by pov?) you
cannot make dynamic linked shared libaries. but if someone on these
platforms *really* needs the api: static linking is not a good solution,
but it is a solution!

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

Post a reply to this message

"The Ellis Family" <cel### [at] voyageurca> wrote in message
news:396### [at] spamlesshotmailcom...
> #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.

I'll probably sell pov images some day, as part of an architectural project
(would be kind of hard to explain: yes, I designed this and was paid for the
project and all the drawings/blue-prints/images but the images done with
Pov...)


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

Mmmh, I do not know about Lightflow, but I think the operative words here
are "in certain areas".


> #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).
Maybe. But: must pov's nature change to get more programmers?
> 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).

I do not sense this. I think PovTeam's members are doing a _great_ work in
their free time, but understandably want to retain some control on their rl.
I respect that and I think it will prove beneficial in the long term.


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

I hate writing this, but this has been discussed many, many times. Maybe it
should be included in a FAQ? (Maybe it already is and I missed 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?).

I do not like that idea for the following reasons:
* It put pressure on the PovTeam, a pressure I would not like were I in
their shoes;
* No surprise with a new release;
* It would make difficult to test features and eventually removing them when
they do not work as well as planned;
* It would become difficult to delay a release for fine-tuning;
* People would probably ask for more intermediate release, which would ask
for more work;
* Different patched Povs somehow fill this need.


>Of coarse, this is all just imho;-)

So it is here ;-)

Povingly,


Philippe

Post a reply to this message

Hy,
you misunderstood me.
I did not intend to buy "programming-time" from you (i think, if you all have
jobs and familiy, there isn't any time anymore to sell..)
I thought of buying "programming-time" from an independent company.
Jurek

Post a reply to this message

jurek wrote:
> 
> Hy,
> you misunderstood me.
> I did not intend to buy "programming-time" from you (i think, if you all have
> jobs and familiy, there isn't any time anymore to sell..)
> I thought of buying "programming-time" from an independent company.
> Jurek

Well..
 - they first have to write the shareware you were talking about
   (I hope you didn't mean turning POV-Ray into shareware...)
 - they have to take time to support it, since its commercial
   (nobody would pay for unsupported software, even cheap shareware)
 - and even if they gather enough money to actually pay other
   programmers (which is very unlikely), they would have to take
   the time to introduce them to the team's methods, explain
   what to do and almost how to do it...

So, IMO, if one wants to help them, the best things seems to :
 - being involved into unofficial patch programming, it helps things
   get going.
 - produce nice images, it's a great motivation for them
   (I always felt that it was the real price of POV-Ray)

Fabien.

Post a reply to this message

In article <39635E94.460067FB@yahoo.com> , jurek <jur### [at] yahoocom>  
wrote:

> you misunderstood me.
> I did not intend to buy "programming-time" from you (i think, if you all have
> jobs and familiy, there isn't any time anymore to sell..)
> I thought of buying "programming-time" from an independent company.

No, that is what I was referring to.  Sorry for not being clear on this.


     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 agree with the statement of eduard schwan. In a "free comunity" you cannot pay
the members. They do it just for fun and for noone else.
Well, I'm not a programmer, but isn't there in Povray 4.0 (which is a complete
rewrite in C++ if I'm right informed) a lot of programming, that isn't complicated
and which could be done by a third person, so that the pov-team could concentrate
on the essentials parts, that need a lot of programming-know-how and
render-know-how ? Just a question...
Jurek

Post a reply to this message

Hookflash raises some interesting points:

- The API.  The current restrictions on the API are derived from the
POV-Ray license.  Many people have contributed code to POV-Ray under the
current license, and many of them are not easy to track down.  The
POV-Team feels it would be a disservice to those who contributed code
under the current license to rerelease that code under a less
restrictive license. The rewrite for 4.0 may give us the opportunity to
revise the license significantly.  Or not.  We'll see.

- The POV-Team needing more programmers.  It has previously been
suggested that the POV-Ray development code base be made available
through CVS.  I see this as possibly a good idea for 4.0, which would
benefit from a large number of eyes.  Currently we're using a
proprietary version control product, and I don't know that it would be
so easy to give client licenses to the entire world.  I feel that moving
to a new version control product this late in 3.5 development would just
get in the way of 3.5.

- Interaction between the POV-Team and the community.  As has been
pointed out, most of the active members of the POV-Team post on this
server regularly.  While the documentation has generally had something
of a "buzz off and leave us alone" quality to it, that's mostly to keep
each of the POV-Team members from getting crushed under a bunch of email
that might best be served by povray.newusers.  That's why we wrote Ken.
;-) I know it goes against what the documentations says, but I'm eager
to talk with anyone who is trying to compile POV-Ray under an officially
unsupported version of Unix.  I actually enjoy getting email from
POV-Ray users about such things.  One of the finest examples of
developer-community interaction is at http://www.linux.org.uk/diary/,
which is Alan Cox's diary.  For those who are unaware, Alan Cox is
basically second-in-command of the Linux kernel, and he keeps an
(almost) daily web diary of what he's up to.  One day he's merging
patches, another he's writing a device driver, and another he's watching
rugby.  Movies, evenings out, and conferences also come up.  His wife
keeps a parallel diary, describing the hour of the afternoon when Alan
got out of bed, the time he spent watching Scooby Doo, that sort of
thing.  It's all quite charming, and I wish I had the time to dedicate
to something like that.  Maybe someday I will.  However, I don't expect
the POV-Team will ever make any sort of policy requiring that we set up
something like JenniCam to keep us under a watchful eye.  ;-)

-Mark Gordon

Post a reply to this message

Mark Gordon wrote:

> Hookflash raises some interesting points:
>
> - The API.  The current restrictions on the API are derived from the
> POV-Ray license.  Many people have contributed code to POV-Ray under the
> current license, and many of them are not easy to track down.  The
> POV-Team feels it would be a disservice to those who contributed code
> under the current license to rerelease that code under a less
> restrictive license. The rewrite for 4.0 may give us the opportunity to
> revise the license significantly.  Or not.  We'll see.

IMHO the licence should be kept as is - you are not being stopped (as far as
I can tell) from writing a version of povray that can do what you want -
expose an API that is.

> - The POV-Team needing more programmers.  It has previously been
> suggested that the POV-Ray development code base be made available
> through CVS.  I see this as possibly a good idea for 4.0, which would
> benefit from a large number of eyes.  Currently we're using a
> proprietary version control product, and I don't know that it would be
> so easy to give client licenses to the entire world.  I feel that moving
> to a new version control product this late in 3.5 development would just
> get in the way of 3.5.

Maybe you could have the development centered at http://sourceforge.net or
set up something similar devoted to POV-Ray at povray.org
SourceForge offers CVS source control accessible via the web through CVSweb

> - Interaction between the POV-Team and the community.  As has been
> pointed out, most of the active members of the POV-Team post on this
> server regularly.

I think its great the way it is esp. with Ken, the TAG and all the myriad
patches (in no specific order) and I very much agree with Philippe Debar's
points on this topic.

--
Bye
Pabs

Post a reply to this message

In article <3963F156.C3615388@mailbag.com> , Mark Gordon 
<mtg### [at] mailbagcom>  wrote:

> I know it goes against what the documentations says, but I'm eager
> to talk with anyone who is trying to compile POV-Ray under an officially
> unsupported version of Unix.  I actually enjoy getting email from
> POV-Ray users about such things.

I agree, I also like to help people to get POV-Ray to compile.

I think the main reason of the note in the manual is to scare away the real
end users (who never used a compiler before) to try to compile POV-Ray.

POV-Ray is complex and surely not the right piece of software to compile as
a first project, but once one has mastered to compile any project with more
than just one file and knows the basics of the compiler one is trying to use
to compile POV-Ray, it is usually no problem to help.

It is just that we usually can't help you if you don't know how to compile a
simple multi-file project using a compiler we may not even have.


      Thorsten


Speaking for myself only.


____________________________________________________
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

On Thu, 06 Jul 2000 13:52:07 +0800, Pabs wrote:
>> - The API.  The current restrictions on the API are derived from the
>> POV-Ray license.  Many people have contributed code to POV-Ray under the
>> current license, and many of them are not easy to track down.  The
>> POV-Team feels it would be a disservice to those who contributed code
>> under the current license to rerelease that code under a less
>> restrictive license. The rewrite for 4.0 may give us the opportunity to
>> revise the license significantly.  Or not.  We'll see.
>
>IMHO the licence should be kept as is - you are not being stopped (as far as
>I can tell) from writing a version of povray that can do what you want -
>expose an API that is.

We aren't.  Y'all are.  It's in the license.

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

Post a reply to this message

The Ellis Family <cel### [at] voyageurca> wrote:

  Somehow I feel your article quite irritating and provocative. Don't know
exactly why, but it seems to be rude and lack politeness.

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

  The fact that you don't know of any people who make money with povray, it
doesn't mean that "very few people" make money with it.
  Ok, it may be true that not many people sell lone images made with povray,
but povray is used in many other ways of creating graphics.
  I myself have created a small logo with povray. This logo is used in the
front page of the documentations created in the project I'm working on. I
have counted the making of the logo as working time, thus receiving more or
less directly money for it. The logo is quite irrelevant in the documents and
in the project and far from directly related to it, but still in an indirect
way I have received money for it. I have also made some graphics (background
images and so on) used in web pages related to the project. Again, not
directly related, but still at working time.
  So I have not sold any image nor I have been asked to make any image with
povray for profit, but still I have used povray and indirectly got money
for it.

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

  It may be "vastly superior" or it may not. The visual appealing of a couple
of example images doesn't tell the whole truth about the quality of the
program itself or even the features those example images show.
  There are several images out there made with povray that show exceptionally
high quality rendering. Putting all of them in one place could perfectly give
the impression that povray is "vastly superior" to other renderers. For
example take the recent "city" irtc winner and a couple of other images of
similar quality, and there you are.
  You can give that impression, but it still doesn't mean that everything you
do with povray looks that good or that it's very easy to get that kind of
images.
  So example images don't tell the whole truth.

  And in my opinion, trying to mix up two different programs can only make
a maintenance nightmare (besides other problems).
  In my opinion, let lightflow evolve in its own path and povray evolve in
its own.

: #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).

  Perhaps no offense is intended here, but still this is a hit under the
belt. This is low.
  You are more or less directly saying, that the povteam is lazy and that
they don't know how to make programs fast enough, and that even one
lightflow programmer can do more in less time than a bunch of povray
programmers.
  Come on. This is insulting. You clearly don't know what you are talking
about.
  Your examples, for instance, are just... how could I say it... ridiculous
(the less insulting word that came to my mind).
  Let me examine them one by one:

  Distributed rendering: This has been discussed before. It has several
problems. One of them is that it can't be done in a portable way and it's
a lot platform specific. Why do you think lightflow is only available for
Linux and NT? What about other Unix users? What about Mac users? What about
OS/2 users? And so on... Would you like to see povray being a Linux/NT-only
program?
  If it could be possible to make distributed rendering easily and portable,
don't you think povray would have it already?

  Accessible api: You mention it as if it was laziness or incapacity that have
stopped the povteam from making a povray api. No, that's not the reason and you
should know it. Read the povray licence and the several articles about the
issue to see why there isn't a povray api.

  "Real" radiosity: This again. What the h*** is with this "real" radiosity?
There's no such a thing as "real" radiosity. All the algorithms for calculating
diffuse interreflection of light are only approximations, as any rendering
technique is.
  Ok, there's an algorithm called "radiosity" which uses a specific technique
for calculating the diffuse interreflection of light (of course only
approximating it), and one could talk about "real" radiosity if the program
uses this algorithm. But why this algorithm is better than stochastic
rendering in raytracing? Or other algorithms out there. What is it that
makes it more "real" than the other algorithms?
  In fact the bug-fixed and enhanced radiosity in megapov (and probably
pov3.5) does a pretty good job. I doubt that using the algorithm called
"radiosity" (which requires tesselation of objects) could do a visibly
better job. It might be a bit faster, but I don't think it would be
considerably faster. As a drawback you will get tesselated objects (which,
if not made with enough detail, can make straight-lined edges to objects and
consumes LOTS of memory if using lots of detail).

  So these are pretty bad examples. Sorry.

: Don't get me wrong, I like PovRay, but I sense a growing lack of
: interest amongst members of the PovTeam

  Please don't talk if you don't know a damn about it.

: Also, PovRay *needs* an accessible api

  No, it doesn't. Why it should?

: (I realize that this
: would be difficult to implement in a portable way)

  Thanks heaven.

: And, most importantly, there needs to be
: more interaction between the PovTeam and the Pov community.

  Have you been sleeping all this time? Check http://tag.povray.org

: Every 2 or
: 3 weeks, the PovTeam could report on the progress of the next release
: (is this too much to ask?).

  They have a good reason to not to do this. They have done it in the past
and got problems with it.
  The fact that you don't hear anything about the team doesn't mean they
are not working hard.

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

Tony[B] <ben### [at] panamac-comnet> wrote:
: 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.

  Ah, so you consider lightflow better than povray.

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

  Tesselation and fancy apis? What for?

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

>   Tesselation and fancy apis? What for?

I don't know about fancy APIs but tesselation would be a useful
feature.

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

Ken <tyl### [at] pacbellnet> wrote:
: I would dare say that is pretty active  involvement in the POV-Ray
: community by members of the POV-Team. They should be commended for
: their active involvement in these groups rather than critisized for
: their lack of it.

  Perhaps the problem is that people don't know/remember who is a povteam
member and who isn't, so their posts don't stand out of the mass?

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

Ken <tyl### [at] pacbellnet> wrote:
: I don't know about fancy APIs but tesselation would be a useful
: feature.

  But worth the efforts?

-- 
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 <3964aedf@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Perhaps the problem is that people don't know/remember who is a povteam
> member and who isn't, so their posts don't stand out of the mass?

So you are suggesting we put ***POV-TEAM*** in our name? ;-)


   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, 06 Jul 2000 18:59:31 +0200, ***POV-TEAM*** Thorsten Froehlich wrote:
>In article <3964aedf@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:
>
>>   Perhaps the problem is that people don't know/remember who is a povteam
>> member and who isn't, so their posts don't stand out of the mass?
>
>So you are suggesting we put ***POV-TEAM*** in our name? ;-)

That makes it look funny in slrn, because it only shows the first few letters
of your name.  Doesn't your signature occasionally say "I am a member of the
POV-Team"?  Mine used to imply I am, but since I post to non-pov newsgroups 
from this machine, and since I haven't customized it for other groups, I 
changed it to something more neutral.

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

Post a reply to this message

***POV-TEAM*** Thorsten Froehlich wrote:

> So you are suggesting we put ***POV-TEAM*** in our name? ;-)
>
>    Thorsten

And don't forget "I speak officially for the POV-TEAM" in you signature ;-)
G.

Post a reply to this message

In article <slr### [at] linuxparkerrfwicom> , 
***POV-TEAM***  wrote:

> That makes it look funny in slrn, because it only shows the first few letters
> of your name.  Doesn't your signature occasionally say "I am a member of the
> POV-Team"?

Yes, I have such a signature.  I use it for responses to e-mail I get to the
mac### [at] povrayorg e-mail address and for some posts in these groups either
if I intend to speak for the team regarding the Mac version, or sometimes if
I get the impression someone desires a response from a team member.

During some arguments, when I talk about the team I also use it occasionally
with a disclaimer in order to point out that it is my opinion, but to make
the person aware of the fact that I am in the team (so I don't get a reply
like: "How do you know about team?") and that I stand for that opinion in
the team.  This especially goes for replies to posts by people who I don't
recognise to visit these groups frequently and who may not know who is in
the team and who is not.

In rare occasions I also remove any signature, to make sure I don't imply
anything.

> Mine used to imply I am, but since I post to non-pov newsgroups
> from this machine, and since I haven't customized it for other groups, I
> changed it to something more neutral.

I had the same problem two years back in these groups.  That is why I
removed it from my default signature, it simply caused too many problems.

I don't post outside these groups, so it is usually OK to include my e-mail
address for any other (non-POV-Ray) reason in the standard signature :-)


     Thorsten


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

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


POV-Ray:
____________________________________________________
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


Newsgroup:
____________________________________________________
Thorsten Froehlich, Duisburg, Germany


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

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

On 6 Jul 2000 12:57:40 -0400, Warp <war### [at] tagpovrayorg> wrote:

>: I don't know about fancy APIs but tesselation would be a useful
>: feature.
>
>  But worth the efforts?

I would bet. There a gazillion quick, effective and good-looking
methods that rely on a polygon-based scene (radiosity, global
illumination, caustics, physical interraction etc. etc.)


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

Post a reply to this message

In article <3964ae3b@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Tesselation and fancy apis? What for?

Tesselation...some objects would render faster if tesselated, and you 
could use the tesselated version as a preview. Also, a low-res 
tesselated version of an object might be useful as a bounding shape for 
some objects.

I think the best way to do this would be a "tesselation {}" keyword for 
objects to specify options and that tesselation should be used. On 
objects which can't be tesselated(julia fractals, CSG, etc), a box, 
sphere, or other approximation could be used.
Infinite objects are more of a problem...a plane could be two triangles 
with the vertices at the largest distance POV can handle, but things 
like poly would have to generate a warning.


Fancy API's? Not needed, and left out for good reasons...

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

Peter Popov <pet### [at] usanet> wrote:
: I would bet. There a gazillion quick, effective and good-looking
: methods that rely on a polygon-based scene (radiosity, global
: illumination, caustics, physical interraction etc. etc.)

  Uh? Radiosity (ie. the specific algorithm called "radiosity") may depend
heavily on tesselation, and perhaps that physical interaction, but the
others I don't understand. We have global illumination and caustics already
in povray (patched or not). They do not need tesselation. And the algorithm
called "radiosity" is obsolete since we have the stochastic method that works
pretty well.

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

Chris Huff <chr### [at] maccom> wrote:
: Tesselation...some objects would render faster if tesselated, and you 
: could use the tesselated version as a preview. Also, a low-res 
: tesselated version of an object might be useful as a bounding shape for 
: some objects.

  But the tesselation process would eat at least some of that gained time.
Tesselation is not free.
  How can you be sure that a tesselated version of a (complicated) object
completely contains the original object?

: Infinite objects are more of a problem...a plane could be two triangles 
: with the vertices at the largest distance POV can handle

  Bad idea. Try to translate that by y*0.01 :)

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

***POV-TEAM*** Thorsten Froehlich <tho### [at] trfde> wrote:
:>   Perhaps the problem is that people don't know/remember who is a povteam
:> member and who isn't, so their posts don't stand out of the mass?

: So you are suggesting we put ***POV-TEAM*** in our name? ;-)

  Well, although apparently more a joke than a serious proposition, it
MIGHT be an idea to be considered after all... :)

-- 
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 wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> : I don't know about fancy APIs but tesselation would be a useful
> : feature.
> 
>   But worth the efforts?

I believe so, yes.

-- 
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 <3964cdb4@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   But the tesselation process would eat at least some of that gained time.
> Tesselation is not free.

And it is even worse if you have to go to virtual memory to hold the 
tesselated object. But still, if you have the RAM, certain objects could 
benefit, and preview renders wouldn't have to be at a high mesh 
resolution.
However, I agree that it isn't a badly needed feature.


>   How can you be sure that a tesselated version of a (complicated) object
> completely contains the original object?

I don't really understand what you mean by this...if you are talking 
about the "placeholders" for objects that can't be tesselated, they 
could be scaled to fit the bounding boxes.


> : Infinite objects are more of a problem...a plane could be two triangles 
> : with the vertices at the largest distance POV can handle
> 
>   Bad idea. Try to translate that by y*0.01 :)

Hmm, transforms might cause problems, but they might not...and anyway, a 
triangle is just a clipped plane, right? Just have the "tesselated" mode 
for a plane be "do nothing", and generate a warning.

-- 
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 6 Jul 2000 12:57:40 -0400, Warp wrote:
>Ken <tyl### [at] pacbellnet> wrote:
>: I don't know about fancy APIs but tesselation would be a useful
>: feature.
>
>  But worth the efforts?

It'd allow export to inferior file formats and answer a VFAQ. 

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

Post a reply to this message

Ron Parker wrote:

> It'd allow export to inferior file formats and answer a VFAQ.

...and displacement mapping, and subdivision surfaces, and...

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

Warp wrote:
> 
> The Ellis Family <cel### [at] voyageurca> wrote:
> 
>   Somehow I feel your article quite irritating and provocative. Don't know
> exactly why, but it seems to be rude and lack politeness.

I tried very hard to word my message in such a way that no-one would
take offense... I guess I failed.  I certainly wasn't trying to be rude
or impolite.
 
>   It may be "vastly superior" or it may not. The visual appealing of a couple
> of example images doesn't tell the whole truth about the quality of the
> program itself or even the features those example images show.

Lightflow is only superior to PovRay in *certain areas* (those were my
exact words), and I didn't mean to suggest that the Lightflow example
images were the only proof of this.

>   Perhaps no offense is intended here, but still this is a hit under the
> belt. This is low.

No offense was intended and, looking back, perhaps I should have worded
it differently.

>   Come on. This is insulting. You clearly don't know what you are talking
> about.

Admittedly, my programming skills aren't exactly spectacular, but I'm
not an idiot either (on rare occassions, I *do* know what I'm talking
about;-).

>   Distributed rendering: This has been discussed before. It has several
> problems. 

Of coarse it has several problems, but it's not impossible.  Anytime you
download a file or fill out a registration form online, you are engaging
in *cross-platform networking through a well-defined protocol*.  The
well-defined protocol is key, but, imho, that would be the only
stumbling block.

>   Accessible api: You mention it as if it was laziness or incapacity that have
> stopped the povteam from making a povray api. No, that's not the reason and you
> should know it. Read the povray licence and the several articles about the
> issue to see why there isn't a povray api.

No offense, but this is one aspect of the PovRay license I do not like. 
But, I can't blame the PovTeam for protecting there interests.
 
>   "Real" radiosity: This again. What the h*** is with this "real" radiosity?
> There's no such a thing as "real" radiosity. All the algorithms for calculating
> diffuse interreflection of light are only approximations, as any rendering
> technique is.

Again, this was poor wording on my part.  I'm certain you know more
about radiosity than I do, and I'm not being sarcastic.  However, is the
PovRay radiosity view-independant?  Is it fast?  And, I personally think
that tesselation might be the answer (it could at least be an option for
the user, but I suppose 2 separate radiosity algorithms would be messy).

>   So these are pretty bad examples. Sorry.

It's not your fault;-)
 
>> PovRay *needs* an accessible api
>   No, it doesn't. Why it should?

Why should we be limited to using PovScript?  What if I want to use a
more powerful scripting lang, such as Python, or even something
proprietary?  With no api, I would have to write a translator, and
having to parse a scene twice would really slow things down (for complex
scenes).  Also, an api would be cleaner & faster for 3rd party
front-ends/modellers.
 
> : Every 2 or
> : 3 weeks, the PovTeam could report on the progress of the next release
> : (is this too much to ask?).
> 
>   They have a good reason to not to do this. They have done it in the past
> and got problems with it.

What problems (this must have been before I entered the PovRay scene). 
I'm sure these problems could be solved.

Hookflash

Post a reply to this message

In article <396### [at] nospamhotmailcom>, 
hoo### [at] nospamhotmailcom wrote:

> Lightflow is only superior to PovRay in *certain areas* (those were my
> exact words), and I didn't mean to suggest that the Lightflow example
> images were the only proof of this.

It would help if you gave examples of which areas it is superior 
in..."surface engine" isn't enough information.
Also, LightFlow seems to be limited to one platform, and was designed 
from the start with a certain direction in mind. This is why some of 
these features were possible.
POV, on the other hand, has to be cross-platform, and has an aging code 
base which makes it very difficult to do some of these things(one reason 
for the 4.0 C++ rewrite, which may make some of these things possible).


> >   Distributed rendering: This has been discussed before. It has several
> > problems. 
> 
> Of coarse it has several problems, but it's not impossible.  Anytime you
> download a file or fill out a registration form online, you are engaging
> in *cross-platform networking through a well-defined protocol*.  The
> well-defined protocol is key, but, imho, that would be the only
> stumbling block.

The protocol may be cross-platform, but the code to use it probably 
isn't. That portion of the code would have to be rewritten for every 
platform to be supported. Then you still have the problems of sharing 
radiosity/photon data, error handling, etc.
So you see, it isn't as simple as finding the right protocol...


> Again, this was poor wording on my part.  I'm certain you know more
> about radiosity than I do, and I'm not being sarcastic.  However, is the
> PovRay radiosity view-independant?  Is it fast?  And, I personally think
> that tesselation might be the answer (it could at least be an option for
> the user, but I suppose 2 separate radiosity algorithms would be messy).

It is view dependant, and it is not too slow(with the MegaPOV fixes, of 
course). And tesselation is not the answer. As has been explained many 
times, there are some objects which just can't be reduced to polygons or 
patches.


> >> PovRay *needs* an accessible api
> >   No, it doesn't. Why it should?
> 
> Why should we be limited to using PovScript?  What if I want to use a
> more powerful scripting lang, such as Python, or even something
> proprietary?  With no api, I would have to write a translator, and
> having to parse a scene twice would really slow things down (for complex
> scenes).  Also, an api would be cleaner & faster for 3rd party
> front-ends/modellers.

Why shouldn't you be limited to POV-Script? It is the input format for 
POV-Ray, and is designed for that purpose. It supports every single 
feature in POV-Ray.
You are welcome to use those languages...all you have to do is have them 
output POV-Script and render it with POV-Ray.
Also, an API has some of the same problems as distributed 
rendering...you have to do it in a platform independant way. Add the 
problems of support...all of these have been discussed before.
The POV Team has very good reasons for this portion of the license and 
for not including this feature, it wasn't just an arbitrary choice.


> What problems (this must have been before I entered the PovRay scene). 
> I'm sure these problems could be solved.

Basically, people get upset when they don't get what they feel is 
promised, whether it is free or not, whether it was actually promised or 
not. The same reason many companies refuse to give release dates and 
definite feature lists. People got upset when a version of POV-Ray was 
delayed past it's release date or didn't have a feature they wanted, and 
some of them got quite irrational.
And these problems were solved...by not giving this type of information 
out. Now there is the problem of people clamoring for more information. 
:-)

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

Ken wrote:
> 
> Warp wrote:
> >
> > Ken <tyl### [at] pacbellnet> wrote:
> > : I don't know about fancy APIs but tesselation would be a useful
> > : feature.
> >
> >   But worth the efforts?
> 
> I believe so, yes.

This make me think of something...
Since bicubic (and bezier) patches are already tesselated before
rendering, wouldn't be _relatively_ easy (for programmers, not
for me !) to apply displacement mapping to them ?

Fabien.

Post a reply to this message

Chris Huff wrote:

> ...definite feature lists. People got upset when a version of POV-Ray was
> delayed past it's release date or didn't have a feature they wanted, and
> some of them got quite irrational.

Irrational is putting it mildly. I heard that some users of the program
were sending e-mail to the team that was both rude and insulting.

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

>   Ah, so you consider lightflow better than povray.

In some ways yes, in some ways no. I seriously respect it. I'll tell you
that.

>   Tesselation

Exporting to other formats, for example.

>  and fancy apis? What for?

I have no idea. I just said that to indicate that eventually, the POV-Team
might get around to adding APIs. I just tossed in "fancy" to make it sound
better. :)

Post a reply to this message