Thank you for clarifying what I already meant. 
I didn't mean for XML to be used to code directly a scene, but merely as 
an interim format which is easier to convert than plain povray. About any 
program that converts from povray, only goes up to version 2.2, before 
programming directives were added.

This always baffled me because it doesn't really look all that difficult 
to just recognize the directives and unroll the loops. in case of 
presence of a clock variable, you can generate a new file for each frame. 


As for how difficult xml is to parse, well, it doesn't look nearly as 
difficult to parse as the povray SDL. Once an XML parser is written, I 
have no idea why anyone would waste time writing it again and again and 
again for each project. Why not just use Libxml or something like that? 
Then all that happens is you read in an xml file, and you can then access 
the data in it through an object. That sounds pretty easy to me.

But of course, I may be wrong on some of those points due to lack of 
direct experience. 

something else that had me sort of interested is this note
http://www.w3.org/1999/06/NOTE-wbxml-19990624/

describing a binary format that could be derived from XML. In this case 
it's specifically meant to be applied to cell phones and other low 
powered platforms, but I see no reason why it couldn't be used to save 
parse time in other applications.  Maybe not this precise format, but 
maybe some similar heirarchal binary structure. I also liked the 
suggestion of compiling into opcodes for a vm, though that does sound a 
bit much for a 3x patch.

Though, I do see a lot of the points brought up, and see how using XML 
may not be the best solution.



> On 19 Mar 2004 18:15:39 -0500, Breton Slivka <Zen### [at] ZenPsychocom>
> wrote:
> 
>>So, I know that there's been much talk about using XML for povray
>>scene description language, and a lot of sunk in povray purists will
>>have none of it!
> 
> Since I am the one to blame for the latest bringing up the issue, I
> feel I should comment.
> 
> XML is definitely unsuitable for POV-Ray scene description. Most
> people hand-code and the overhead of XML is a needless pain in the
> behind. That's pretty much what most comments boil down to and my
> personal opinion follows the same route.
> 
> However, ...
> 
>>This would also bring the advantages that XML brings, of easy 
>>portability, parsing, and flexibility of presentation, eliminating the
>>difficulties involved in creating alternative rendering engines for
>>quick preview of povray scenes. 
> 
> ...I personally believe XML might be worth a try (unofficially) as a
> means to export already parsed POV-Ray scenes (prior to rendering) for
> the purpose of converting to other formats -- at least the parts that
> make sense. Surely it is not possible to convert the general POV-Ray
> scene because basically everything is procedural - 99% of the
> textures, and quite a lot of the objects (isos, julias, blobs to some
> extent etc.) But there are definitely cases where one can benefit a
> lot by some interoperation between POV and other packages, for example
> by generating a city in POV using Chris Colefax' macros, then render
> it in Terragen or even Radiance for the skies or lighting,
> respectively.
> 
>>Suppose then that a patch in povray would allow the automatic
>>translation between these 3 formats, and the direct parsing of the
>>formats into internal tokens. 
> 
> In any case if one decides to try to implement something along these
> lines, it should be in an unofficial version. First of all, the next
> version of POV (as of current development plans 4.0, release date as
> usually unknown :) ) plans some major rewrite. Who knows what state
> XML will be in by then? It might not make sense at all to use it
> because it might be practically dead by the time 4.0 is out.
> 
>>Anyways, I'd be interested in hearing why this is a stupid idea.
> 
> I don't think it's a stupid idea, but definitely one that needs a lot
> of thought and planning to be taken seriously.
> 
> 
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] vipbg
> TAG      e-mail : pet### [at] tagpovrayorg
>

Post a reply to this message