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