Bernd Fuhrmann wrote:
> Patrick Elliott wrote:
> 
>> In article <41d6ae1a$1@news.povray.org>, Sil### [at] gmxde says...
>>
>>> Thorsten Froehlich wrote:
>>> But POVRay files are rather small. Parsing speed does not matter that 
>>> much.
>>>
>>
>> Ah.. A real professional user of POV-Ray are we? Some SDL takes longer 
>> to parse than the actually rendering. The very idea that size, 
>> complexity and speed in that step is irrelevant is.... incomprehensible..
> 
> 
> To be honest: I am not a professional user of POVRay. I just want to 
> render some illustrations for my documents and my webpage with POVRay. 
> No landscapes, no complex meshes and so on. The sentence you quoted lost 
> its context: In MPEG parsing speed is essential. It can make the 
> difference if you can watch a movie on a 300Mhz processor or if you need 
> a 1000Mhz processor. Assembler optimization is absolutely neccessary for 
> such parsers. But in POVRay its different: There is no time limitation 
> of that kind. You don't render 25 pics per second, do you? So what if 
> you need twice the time for parsing? It won't do that much harm. You 
> just have to wait a bit longer or buy a faster computer or simplify your 
> scene a bit.
> 
> Besides: Parsing is just transforming the program to a treelike internal 
> representation form. It's not executing or evaluating the program except 
> you do everything with the preprocessor. So does it really take that 
> long to process handwritten code? I cannot believe that. It will take 
> much longer to execute and evaluate the internal treelike representation.
> 
>>> Now for the 4.0 rewrite: What will it be like? I just googled a bit, 
>>> but I couldn't find anything about it. How do you know that similar 
>>> limitations like the ones described won't appear again? Is there any 
>>> information about it available?
>>>
>>
>> First off... Thorsten Froehlich is on the development team for this 
>> program, so one would think he would have a clue what the flaws are 
>> and why your idea is purely nuts. Yeah, there is one application of 
>> XML I can think of that provides for programming, but it does so by 
>> borrowing the <script></script> tags from HTML and using real 
>> languages to do the work. The rest of it is just parsing of user 
>> readable information that defines simple behaviours and settings for 
>> inbuilt functions, not complex objects. It also uses name spaces to 
>> keep things straight, but doesn't allow directly talking between 
>> things in different name spaces. Why? Because the same 'include' might 
>> be used in several different XML plugins. Each of them could use the 
>> same function names, the same names for objects, etc. and keeping all 
>> of them straight, even with namespaces, is easier is they never 
>> directly interface in any way. The interfaces that are supported 
>> involve using a unique UID for each one, to make sure they don't 
>> interfere. With POV-Ray, even with separate spaces, these things have 
>> to interoperate and coexist. That has to be handled 'by the application'.
>>
>> What form the data takes in the source file has nothing to do with the 
>> function, only the time wasted a) coding it and b) parsing it. Making 
>> it intentionally more complex doesn't fix the problem, which is not in 
>> the file, but in the way the application handles the information. You 
>> could use bloody Sanskrit on punch cards, Tolkein's elven language 
>> transmitted by brain waves or even your XML idea and it wouldn't alter 
>> the fact that the problem is in the limitation of how the data is 
>> handled 'in the program', not how it is represented in the SDL itself.
> 
> 
> Right. That is why I suggest to put some processing outside of POVRay. 
> POVRay is a good raytracer. I'm really impressed by it's fine 
> performance. But I think that not all processing of data should be done 
> by POVRay. There are e.g. programs that build meshes out of other data. 
> A good example might be the creation of humanoids out of a collection of 
> sizes. I will never be able to write anything like human{<0,0,0> 30 40 
> 10} because I cannot define my own objects. It wouldn't make sense 
> anyway if I could because this would lead to total anarchy in the lower 
> namespace. But it is still incredible difficult for me to write a parser 
> that will just replace all "human {...}" with something that POVRay can 
> render like a mesh. That is what I want. I don't want to touch the 
> POVRay parser. I just want to get my own preprocessing done. This is 
> possible with XSLT (though it sometimes looks ugly, I admit).
> 
>> Argh.. Its like arguing with someone that insists printing Bible 
>> quotes on toilet paper would be sacrilegious, it has to be exactly 
>> such and such font, this specific size, the paper made from only the 
>> finest rose wood pulp, blah, blah, blah. Only the real argument is if 
>> the Reader's Digest Condensed version leaving out all the verse names 
>> and insisting on calling Moses, "the bearded guys with a stick" was 
>> the best way to get the story across. lol Which is more important, 
>> that the program supposed the feature everyone admits is missing, or 
>> that it was painted in the most recent style? 
> 
> 
> No, that isn't the point. Example: BASIC is a language that is capable 
> of many things. But C/C++ is better. At least for professional 
> programmers. No sane man would ever start to write a complex software 
> project (like Mozilla or sth similar) with BASIC. So it's not a question 
> of style but a question of language features. POVRay SDL lacks a lot 
> features I'd like to see. So what do I do? Change POVRay? No! I cannot 
> because I don't have the time. I'll rather invent some cool system that 
> is able to emulate the features I'd like to have.
> 
>  > BTW, I equate XML with pointillism. Complicated,
> 
>> insanely anal and totally pointless if there is a more efficient 
>> method to solve the problem. Maybe, given 50-60 years it will actually 
>> look 'useful' for some programming applications, much the way 
>> pointillism more or less accidentally hit on the idea for digital 
>> video, years before it was remotely practical for anyone without a lot 
>> of patience and several loose screws to use the idea. However, I 
>> strongly suspect it won't. lol
> 
> 
> Do whatever you like.
> 
>> And for the 99,999th time on these news groups. Version 4.0 features 
>> are not yet even technically 'in development' yet, which makes it a 
>> bit hard to discuss what or how anything will be implemented in it.... 
>> Nor has the team expressed a desire to discuss it and have 500 people 
>> telling them not what will improve the ideas, but how they are doing 
>> it all totally wrong.
>>
> 
> Exactly. And that is why I won't base my faith upon it. I never said 
> that it should be done this way or that way. I just asked if someone 
> would like to design an XML version of the POVRay SDL in order to gain 
> customizable proprocessing levels. No change in POVRay was suggested. If 
> I did, I apologize.
> 
> Besides: If that has been discussed so many times: Why don't you put it 
> in the FAQ?
> 
> Regards,
> Bernd Fuhrmann


I have a simple question. Bernd, why do you think it's easier to write 
xml/xslt parser with the suport of advanced features rather than to 
extend current Povray SDL.  i think to write XML parser is more difficult.
Have you tried Povray?  it's  a very easy script. May be you could help 
in Pov parser/SDL development? 4th version would appear sooner.
Povray is not a commercial project so certainly guys work on it with 
their spare time, but enthusiastic people like you should be encouraged.

Later it will be possible to write direct convertors from povray to xml. 
Though an application of this for me is not obious.

Andrey Skvrotsov

Post a reply to this message