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