On Mon, 18 Oct 2004 06:14:33 -0400, Warp wrote:
> 
>   What would be the point of having tons of people throwing random thoughts
> and usually just creating endless flamewars about tiny details of the new
> design?
> 

Despite the flame wars, the discussions I was referring to (for your
information, "The language of POV-Ray" and "Pov-Ray 4.0? Wish List.")
seemed to generate some of the best ideas for a major redesign that I have
seen mentioned.  These discussions were not generally about tiny details
of the design, but about large overarching changes to the program that
have the potential to make it better in significant ways.  I don't
understand the motivation for ignoring such discussions just because there
are some ideas that are not to the 'Team's liking.  It's easy enough to
ignore or inform the people who haven't a clue about what they are talking
about, and (discuss / argue / flamewar) with the rest.  At least in this
case there is an outward sign that the Team has an interest in becoming
better informed about the needs of its user base, and also has the
opportunity to show some signs of "life" (if you will), so that users know
that the project is not stagnating.

Of course, if the POV-Team already has a perfect knowledge of the needs of
its users, and a perfect knowledge of how to design a renderer, then there
is no such need for discussion.

Andrew

Post a reply to this message

> In article <ckvtr0$27j$1@chho.imagico.de> , Christoph Hormann 
> <chr### [at] gmxde>  wrote:
> 
>> So it would
>> probably be a better idea to keep such a discussion focussed more on
>> requirements than on actual design
> 
> Exactly.
> 
So, when discussions begin for POV-Ray 4.0, will the Team provide an open
forum for user suggestions?  My vote is for "povray.wishlist".  As a
programmer, I'm also wondering how you really keep "requirements" and
"design" seperate.  A discussion of requirements necessitates some degree
of discussion of feasibility, and after this, the implications to how the
system will be designed.  Unless the team operates as a black box
(input: requirements, output: povray 4.0), then there should be
discussions (perhaps in povray.programming) to discover the implications
of the requirements.  If the team does operate as a black box, then I
think it is a shame, because it seems there are people outside the team
who have skills and motivation to contribute to this aspect of the project.

Post a reply to this message

jute <nomail@nomail> wrote:
> The POV-Ray SDL.  I read from a post that v4 will include a new version of
> the SDL.  Is this true?  How extensive are the planned changes?  Why, if I
> may ask, are they required?

  Exactly as the current POV-Ray source code is a bunch of hacks over hacks
and patches over patches, making it an unmaintainable chaotic mess, the
SDL is pretty similar. The original SDL was never meant to be a programming
language, just a data container format. However, over the years many
programmatical features were added (read: kludged) over the old SDL.
The result is a bloated, mostly ugly, limited and specially inefficient
language.

  Most POVers are accustomed to the current SDL and find it mostly easy
to use and understand, and people have created more or less complex include
files as kind of "plugins" to add new features to the program which people
can easily use. However, due to its limitations and inefficiency it's just
not possible to implement everything which could be possible and this is
a big minus.

  Example: Imagine an include file which you could use to load a scene in
3DMax format. Moreover, imagine that you could *save* a POV-Ray scene
consisting of meshes in 3DMax format with that include file.
  Or imagine you could make an include file that can be used to save the
rendered image in JPEG format.
  Imagine an include file which could allow you to handle NURBS data,
or HDRI data or whatever.
  The list of possibilities is endless.

  What is the current solution to add these kind of new features? To patch
the POV-Ray source code, adding it to the endless list of other patches,
requiring people to download an install yet another unofficial version
of POV-Ray... And yet these newly implemented features are usually rigid
and limited and can't be enhanced by the user unless he knows C++ very well
and is willing to fix the code and recompile a new version of the binary.
This just needlessly bloats the source code, making it harder to maintain
and adding tons of possible bugs and incompatibilities
  And most importantly: These new features would be just kludges over the
already-cluttered poor old SDL which was never designed for these kinds of
things.

  Another problem is speed: The SDL is slow like a bug in molasses.
  I once made a concrete test: I made an ascii-mandelbrot program with perl
(which is also an interpreted scripting language) and basically the same
program with POV-Ray SDL (the output of both was practically identical).
The perl version was over 13 times faster than the POV-Ray version.
  The problem is that the current SDL is not very suitable for speed
optimizations because of its very design (kludges over kludges over old
SDL which was never designed for this).
  A better-designed language could be made as fast as perl.

  I have always said that one of the most powerful features of POV-Ray
(its SDL) is also one of the weakest features of POV-Ray.

  POV-Ray is in desperate need of a powerful and efficient scripting
language. The user-defined functions introduced in POV-Ray 3.5 were a
step towards this, but they were also just kludges over the old SDL.
That is just not the way. It doesn't work very well.

  People have suggested not inventing the wheel once again but to use
an existing scripting language which is fast and efficient. This is not
a good solution because the scripting language of POV-Ray needs to be
specific to POV-Ray. It must be easy to create primitives, textures, etc
with the language. This task becomes harder if they must be created with
a generic scripting language not designed specifically for POV-Ray.

  Conservatives oppose all kind of changes to practially anything, but
that's too bad. The current SDL is just not it. If fundamental improvements
are desired for POV-Ray, the current SDL would be just a drag and would
make any new improvements a lot harder.
  Conservatives find it hard to see the *advantages* of having a more
powerful language: Programmers could create better and more powerful
include files with more diverse features for people (including these
conservatives) to use. And because all these new include files are based
on the one and same scripting language, their usage will be very alike,
making it easier to learn to use them. In the long run people would
benefit from this a lot more than from tons of patched binaries which are
kludges over the current SDL and completely new syntax to learn.

  However, this doesn't necessarily mean that pov4 will be completely unable
to render old scenes. I'm sure the team will have some level of backwards
compatibility.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christoph Hormann wrote:
> Thorsten Froehlich wrote:
>> Then you fundamentally misunderstood the point we always made: We will not
>> discuss the design in public, and we do not endorse design discussions in
>> public either.  Every discussion about design ideas is just ignored,
>> regardless of what is being discussed.
> 
> Speaking only for myself:
> 
> this is a bit exaggerated (or at least could be easily misunderstood).
> Development of POV-Ray does (and i hope will always do) include
> discussion in the POV Community.  This of course does not mean that
> everything is first discussed in the public newsgroups.
> [...]
I'm glad to read a very reasonable statement from Christoph (and also from 
Warp) after having read Thorsten's previous message. (Well, I'm not sure 
how he really meant it but I read it twice and understood it like "we are 
the cooks and the users should eat what we dish them up - or leave it".) 

I completely agree that there need to be only 1 or 2 people who should do 
the main design. Once the interfaces are designed, things like individual 
input/output drivers (different image formats, etc.) could be implemented by 
more/other people. 
And also implementation details should not be discussed (at least not yet). 

But I would strongly suggest that the chief designer puts together a list 
where he notes down all that input from the community which is relevant 
even if it seems to be "uninteresting" and when finally planning he can go 
through the list and decide what should actually be made possible. 
I call this an "idea map" and have quite a lot of paper around for that. 

And finally, there is another problem: Time. Because there is no point to 
plan the best raytracer in the world for one's complete life to have it in 
production shortly before end of one's life, to put it drastically. Because 
one then cannot use it any more. 

And here, things meet: Probably a lot of people would be much happier 
if they either saw that POVRay is making steady advances or at least 
their ideas would be encouraged/accepted. 

But for me "outside here" is just feels like everyone (including the team) 
is merely dreaming of version 4 and actually not putting much effort into 
design or development. I'm not sure if that is really the case or if I have 
to blame the closed development model for that. 
But my overall feeling suggests against the latter and of course there is 
nobody who could force anybody to work on a free project. 

Regards,
Wolfgang

Post a reply to this message

In article <pan### [at] uwaterlooca> , Andrew Clinton 
<ajc### [at] uwaterlooca>  wrote:

> I don't
> understand the motivation for ignoring such discussions just because there
> are some ideas that are not to the 'Team's liking.

It seems you just do not want to understand because I very explicitly made
clear that what you claim in your statement is not the case:

>>>
Every discussion about design ideas is just ignored,
regardless of what is being discussed.  As such, there is simply no judgment
at all made on any idea discussed in public.
<<<

How to misinterpret that statement to "ignoring [..] ideas that are not to
the 'Team's liking." is beyond me, and probably anybody else reading this as
well.

So please stop making absolutely false assertions.

    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

Andrew Clinton wrote:
> So, when discussions begin for POV-Ray 4.0, will the Team provide an open
> forum for user suggestions?  My vote is for "povray.wishlist".  As a
> programmer, I'm also wondering how you really keep "requirements" and
> "design" seperate.  A discussion of requirements necessitates some degree
> of discussion of feasibility, 

No.  As an engineer i can tell you that when planning a new design you 
start with the requirements alone.  Limiting the requirements from the 
beginning to only require what is feasible will result in no innovation 
at all (and i am quite sure this applies for program design as well). 
So what you write here to me indicates that you have no idea what 
formulating the requirements actually means.

So again my suggestion: if you want to start some discussion helpful for 
  future POV-Ray design start with talking about requirements.  The most 
useful discussions usually arise from users talking about something they 
would like to do but that seems difficult/impossible with current 
POV-Ray.  The majority of such postings can of course be answered with 
an already existing and well working solution but from time to time you 
see things that really hit a weak point.  If you then really try to 
formulate what you actually want to do - as concrete as necessary but as 
general as possible - you are already half way finished.

A povray.wishlist newsgroup will only result in a lot of feature 
suggestions and i have already explained why there is not much use in 
proposing features at the beginning.  Everyone who likes to make an 'i 
would like feature xxx in POV' should ask himself what he wants feature 
xxx for and voila - you are again talking about requirements.  A 
separate newsgroup for discussing requirements would only make sense IMO 
if the discipline to keep the discussions on-topic is maintained there.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <4173d131@news.povray.org> , Wolfgang Wieser 
<wwi### [at] nospamgmxde>  wrote:

> I'm glad to read a very reasonable statement from Christoph (and also from
> Warp) after having read Thorsten's previous message. (Well, I'm not sure
> how he really meant it but I read it twice and understood it like "we are
> the cooks and the users should eat what we dish them up - or leave it".)

That is how it is going to be regarding the *design*, yes.

I clearly did not talk about anything else in the development process. And
neither Christoph or Warp said the design process would be different;
instead they addressed the other parts of the development process. Christoph
made a very clear that discussions focusing on requirements are going to be
much more likely being read (and hence considered) if they do not waste time
and space on talking about a specific design to implement a requirement.

    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

"Thorsten Froehlich" <tho### [at] trfde> wrote:
> The point is, would you be happy if you could just state it and never get a
> reply?

I've thought about this a bit and I'm starting to see things your way.  As
far as design goes, it's better done by those who really know the current
program.

However, one day there will probably a specification for developement.  I
think there are many people in the community that both could and would lean
a helping hand that day -- if you let us.

--
jussi.kantola

Post a reply to this message

in news:4173e503$1@news.povray.org Darren New wrote:

> and I don't know of any good scripting 
> languages designed to be embedded that have a good OO foundation
> built in. 

http://docs.python.org/ext/embedding.html

Ingo

Post a reply to this message

Thorsten Froehlich wrote:

> In article <4173d131@news.povray.org> , Wolfgang Wieser
> <wwi### [at] nospamgmxde>  wrote:
> 
>> I'm glad to read a very reasonable statement from Christoph (and also from
>> Warp) after having read Thorsten's previous message. (Well, I'm not sure
>> how he really meant it but I read it twice and understood it like "we are
>> the cooks and the users should eat what we dish them up - or leave it".)
> 
> That is how it is going to be regarding the *design*, yes.
> 
Okay, so I think we all agree that the _design_ needs to be done by 1 or 2 
(or maybe 3) "engenious persons" who read a list of requirements and 
then come up with the design. 
What I wonder (and really would like to know) is if there actually are 
some people in the POV team (or at least one) who is _continuously_ putting 
a considerable amount of time into that design process. 
Or if everybody is "just dreaming of version 4". 

> I clearly did not talk about anything else in the development process. And
> neither Christoph or Warp said the design process would be different;
> instead they addressed the other parts of the development process. Christoph
> made a very clear that discussions focusing on requirements are going to be
> much more likely being read (and hence considered) if they do not waste time
> and space on talking about a specific design to implement a requirement.
> 
Well, people like me would only suggest things which they are convinced are 
feasible in some way and hence before suggesting some "requirement" I would 
think about "implementation". 

But well, what about setting up some "requirement list" summarizing what one 
should be able to do with the ultimate raytracer? Just as a collection of 
ideas, something to be considered during design but without any guarantee. 

Wolfgang

Post a reply to this message