<woz### [at] club-internetfr>  wrote:

> "We know what is good for you".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Thorsten

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

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

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

Post a reply to this message