ABX wrote:
> You know, there are a few not technical users of POV-Ray. While average
> "artist" can easily write and understand sphere{0 r scale x*4 pigment{Red}}
> anything more complicated would make understanding harder.

I'm not saying that the whole primary file format of POVRay should be 
changed. I just state that there should be a XML version of it. Or there 
should at least be the ability to use a XML version. This can be done by 
using XSLT. No change in POVRay is required. But it wouldn't make sense 
if I programmed my own XSLT for that. So I looked for people that have 
some interest in using XML for POVRay.

>>It would be possible to write material libraries, object libraries and 
>>so on without clobbering the global namespace.
> 
> You have material and object libraries nowadays in include files.
> Can you point me an example of useful namespace application within POV-Ray
> scene from average unskilled user point of view?

Ok, an example. Two people, A and B, work on car models. They both make 
two good ones that you want to use in your scene. Both will get more 
features in the future. So you will want to update them often. But there 
is a problem: Both use equal names for different macros (CreateTire, 
CreateEngine, and so on). As soon as you include both files from these 
two authors you will have conflicts. When you solve them manually they 
will return as soon as you upgrade your files. So you will have to 
constantly solve name conflicts. Ok, this is feasible for two scene 
files. But what, if you have thousands of cars (highway scene)? Welcome 
to namespace hell!

This does not happen with XML: You would use for example use XSLT to 
replace something like <car xmlns="http://www.cardesigner.com/volvo0001" 
tiresize="50" color="Red" leftdoor="open" rightdoor="closed"/> with the 
model of your car. There won't ever be any conflicts.

>>This would make the implementation of HUD systems possible 
> 
> Head Up Displays you mean? Which application you mean exactly?

I needed it when I rendered three dimensional graphics. I had to label 
certain points. It was then neccessary to put all camera parameters into 
global variables. I think it is a rather dirty solution.

>>(useful if you want to mark or label certain things in your scene).
> 
You can do everything. You can even write a C++ compiler in POVRay if 
you have enough sparetime. That's not the point. The point is: Can you 
do it the clean way?

>>One could even convert whole models to meshes and apply mesh 
>>modificators on them. This is AFAIK not yet possible in POVRay.
> 
> That depends what you mean by "convert" and "modificators".
> ie. http://www.geocities.com/SiliconValley/Lakes/1434/images/createmesh.jpg

I am talking about structural conversion: Take a cone {<0,0,0> 1 <1,0,0> 
2} and convert it to an approximation of triangles to apply mesh 
modificators on it (like twisting, bending, etc.). It should be possible 
to do so without losing your original cone markup. So conversion should 
be done on the fly. POVRay won't be able to do this. Ok, POVRay can do 
this if you encode that cone into some data structure. But that won't be 
feasable if someone else wrote that code and you don't want to touch it.

>>Ok, maybe some of these things can be done in POVRay file format.
> 
> IMO that's not POV-Ray file format but POV-Ray features which makes things
> possible.

True, I admit.

>>But if they can be done, how clean can they be done?
> 
> Some prefer question: how hard can they be done. I think writing simple
> include file is easier than introducing new parser and changing habits of
> large community.

I'm not planning to change anyones habits. It is obvious that the design 
of a XSLT script that is able to map all possible features of POVRay to 
XML will take one month or two. Therefore I'm looking for people who are 
interested in such an idea. I'd really like to develop some models, 
materials and things for POVRay but I know that I'd go to namespace hell 
for that. My scripts would be useless in a couple of years. XML is a 
good way to assure compatibility.

Regards,
Bernd Fuhrmann

Post a reply to this message