4708ac11@news.povray.org...

> POV-Ray allows you to do that, not as a side-effect of the SDL, but
> precisely BY DESIGN.  Drop that, and you kill POV-Ray (there are
> already many nice and free pure renderers out there).

Really, this is what should be discussed in depth in those threads, because 
it should drive the development of POV 4.0.

POV-Ray is a unique association: a modelling script + a high-quality 
renderer. The modelling script is intuitive enough to be used by 
non-programmers, while still powerful. That's what made POV-Ray a success at 
a time where there was little competition in terms of free, powerful 3D 
applications. This period more or less peaked in 1997-1998, with the 
integration of radiosity. Now, the times have changed.

- The shortcomings of the script as a modelling tool have become more 
evident: 3D users expect to be able to create certain things - character and 
industrial design, animation, particle systems etc. - that typically require 
a GUI to be done efficiently. Also, including external models into POV-Ray 
isn't straightforward, which makes POV-Ray currently ill-suited as a 
rendering-only application.

Using script (and only script) for modelling is generally a personal 
choice - intellectual and/or aesthetical - and there are niches where it's 
very efficient. Particularly, POV-Ray is relevant in sectors like education, 
scientific illustration, processor benchmarking and as a testbed for 
experimental CG techniques (see http://www.wikipov.org/ow.asp?PovSpotting 
for examples and feel free to add some).

- The shortcomings of POV-Ray as a renderer have also become obvious to 
anyone who browses the galleries of other applications. Just have a look at 
Vray, FinalRender or Maxwell galleries, for instance.

So where do we go from there?

Here are the 3 basic options (which could be mixed/nested of course):

1. Keep POV-Ray as it is, with a relatively accessible SDL, with a few 
additional bells and whistles (better mesh support, better integration of 
3rd party objects, more complete shading language...) and an improved 
rendering engine.

2. Turn POV-Ray into a "pure" rendering library, that could be controlled 
through different programming languages and used by external packages.

3. Turn POV-Ray into a standalone modelling+rendering package (using Moray 
as a starting point for the GUI, for instance), with a deep integration 
between the modeller and the script.

Option 1 is certainly the easiest/cheapest. It's main drawback is that it 
maintains POV-Ray where it is now: a hobbyist toy with some niche 
professional applications. Not a bad thing per se, but not very attractive 
to coders and 3rd party users. This kind of thing needs some momentum and 
I'm not sure that a "hobbyist toy" with a smallish user base has it.

Option 2 is intellectually attractive for coders, and, if done well, could 
promote POV-Ray as a valid open source, free high-quality rendering tool.
Problem 1: there's already some lively competition (Yafray, Indigo, 
Kerkythingie...) in the "pure" renderer field.
Problem 2: will it be possible to keep intact the original simplicity and 
human-writeability of the SDL without excluding the non-programmer users?
Problem 3: the attractiveness (to users and programmers) of the software is 
linked to its attractiveness to artists able to create WOW pictures. Now, a 
language too "programmy" is going to limit those to the smaller population 
of good artists that are also serious programmers.
Of course, if POV-Ray become a 100% pure renderer that only reads SDL 
written automatically or by programmers, the question becomes moot (mosts 
artists will use it through a 3rd party GUI), but something will be lost I 
fear.

Option 3 is clearly a mammoth undertaking, and there's already (since we're 
talking pachyderms) that big elephant in the room of open source 3D that is 
Blender, which is probably already sucking up the free time of many CG 
programmers. Now Blender, thanks to its idiosyncratic interface, is a 
love-it-or-hate-it application, and POV-Ray is all love, so there's a 
possibility there ;)

G.

Post a reply to this message