Hi Bernd,

"Bernd Fuhrmann" <Sil### [at] gmxde> wrote in message
news:41d51598@news.povray.org...
> Hi!
>
> I just thought if it might be possible to use XML to describe a scene.
> ... snip ...
> I'd like to know if there is already such a system planned or implemented.

It is already possible to use VRML to describe a scene (not a POVRay scene).
VRML has been about since about 1994.
There is a project working to convert it to an XML base (xVRML) as it was
originaly based on SGML principles. In fact I think they released an XML
schema for it way back in 2003.

It sounds like it might be of interest to you as it already supports flying
through scenes, which is the sort of thing you would need for use with a
head up display.
You can also bookmark 3d positions in a scene so that the user can fasttrack
the view point to those positions.

> ...snip ...  Is anyone except me interested in implementing such a system?
> What do you think about this idea?

I think there are probably lots of people on the VRML news groups and in the
xVRML community that are interested in such a system.

I myself took a brief interest in this before discovering POVRay. I, like
you, am quite happy to dive into coding markup languages by hand, but what
put me off VRML (and the concept of using tagged markup languages for scene
description in general) is the enourmously verbose manner used to describe
an object.
As has already been mentioned, POVRays Scene Description Language provides a
highly elegant and concise yet flexible way to describe objects.

I found that even to describe relatively simple objects in VRML 1.0 was
cumbersome. It may have improved with the more recent versions of VRML, but
I think it's more down to the nature of markup languages. Nowadays I think
people probably use converters to generate anything but the simplest VRML
scenes, and even then I've never seen any VRML scenes that come close to the
sophistication of some of the newbie POVRay scenes posted on the povray
newsgroups.

>
> Thanks in advance
> Bernd Fuhrmann

So I think the concept of using an XML, VRML, xVRML or other tagged markup
language to describe 3D scenes has a place.
But I very much prefer the POVRay SDL for the sort of things you see POVRay
being used for and would direct anyone advocating changing it in the
direction of a tagged markup language to take a look at why VRML hasn't
grown into this space in the 10 years it's been about.

Regards,
Chris.

Post a reply to this message

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

In article <37jat050gpl1jhjhfl290afmkdbivt0f7q@4ax.com>, abx### [at] abxartpl 
says...
> On 31 Dec 2004 07:54:35 -0500, ingo <ing### [at] tagpovrayorg> wrote:
> > > Can you point me an example of useful namespace application within
> > > POV-Ray scene from average unskilled user point of view?
> >
> > A problem I ran into several times is using multiple include files, where 
> > in two or more inc's objects are defined with the same name.
> 
> And usually how hard it is to solve such issue?
> 
> ABX
> 

Actually, that 'could' be solved with something as simply as treating the 
file itself as an object. I.e.:

File 1 (Fred.inc):

...
object Fred = {Sphere{<0,0,0>, 1}}
...

File 2 (MyBoxes.inc):

...
object Fred = {box{<-0.5,-0.5,-0.5>,<0.5,0.5,0.5>}
...

Instead of generating a parse error, you take any duplicates and make 
then sub objects:

Fred.Fred
MyBoxes.Fred

If however, you only use one of the includes, then 'Fred' would 
automatically resolve to the only one available. This would have no 
effect on most scenes, since it only effects cases where more than one 
definition is being used. Of course, it would need to ignore re-
definitions in the same file, so that only the 'final' state of the 
includes objects are considered. If Fred was redefined five times in the 
same include, only the last version would become valid, since that is all 
the main scene would see anyway. Same with local definitions, though you 
might need to include the concept of 'me.<object>' for clarity.

But really, just editing the names for your own purposes is not that big 
a deal. Well, unless it is one of those million object tree includes one 
of the tree maker utilities generates..... lol Just finding all the damn 
names to change them in those is a nightmare.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <41d59f26$1@news.povray.org> , Bernd Fuhrmann 
<Sil### [at] gmxde>  wrote:

> 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.

Whatever argument for XML you can give, it applies for any other format.
The use of XML has been discussed to death before, and there are just no
arguments for it that do not apply to the current format just as well. As
such, there is no point to argue for XML.  To the contrary, there are things
you can do in POV-Ray right now that would be incredibly difficult to
express in XML.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> Why not? It isn't that difficult. People write XHTML, MathML and even 
> SVG by hand. At least I do. So why not POVRay?

  Because there already is a language which is ten times easier to
write and understand.

> It would be possible to write material libraries, object libraries and 
> so on without clobbering the global namespace.

  If this is the problem, why is XML the solution?

  The POV-Ray SDL is a *programming language*, XML is a markup language.
Trying to create a programming language with a markup language is not
the best possible idea.

> It would become possible to access the camera settings to adjust certain 
> values. This would make the implementation of HUD systems possible 
> (useful if you want to mark or label certain things in your scene).

  And XML is the best solution for this because...?

> One could even convert whole models to meshes and apply mesh 
> modificators on them. This is AFAIK not yet possible in POVRay.

  And how on earth does XML make this any easier? Does XML have some
magic which will allow you to tesselate any given surface?

> Ok, maybe some of these things can be done in POVRay file format. But if 
> they can be done, how clean can they be done?

  It is aknowledged that the current SDL has reached its practical limits
and that a better language may be necessary, but XML is certainly not
the answer. POV-Ray needs a programming language, not a markup language.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Isn't it funny how someone like Bernd here gets a different idea and slant
on things and wants to try it - only to be spanked by other users because
it's "not practical" or "not the done thing"???

Too bad.

My advice Bernd:

You go for it.
Do your thing and don't let stuff get you down.

Nathan

By the way, I have no idea what XML or anything like that is, so I can't
help you there... :)

Post a reply to this message

In article <web.41d623caa2588acaf1cc99770@news.povray.org> , "Captain 
Chemistry" <njj### [at] studentmonasheduau> wrote:

> Isn't it funny how someone like Bernd here gets a different idea and slant
> on things and wants to try it - only to be spanked by other users because
> it's "not practical" or "not the done thing"???
>
> Too bad.
<snip>
> By the way, I have no idea what XML or anything like that is, so I can't
> help you there... :)

It you do not know what you are talking about it is usually best to remain
silent rather than post a comment offending virtually everybody else in the
discussion.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>Why not? It isn't that difficult. People write XHTML, MathML and even 
>>SVG by hand. At least I do. So why not POVRay?
> 
>   Because there already is a language which is ten times easier to
> write and understand.

But not to transform. Automatic code generation is an important goal. At 
least I want to achieve it.

>>It would be possible to write material libraries, object libraries and 
>>so on without clobbering the global namespace.
> 
> 
>   If this is the problem, why is XML the solution?

Because XML supports namespaces via xmlns.

>   The POV-Ray SDL is a *programming language*, XML is a markup language.
> Trying to create a programming language with a markup language is not
> the best possible idea.

Well. POVRay syntax won't stay the same forever, will it? Extensions 
will surely be added. There needs to be a system that assures that these 
extensions wont result in any conflicts with old scenes. How can you 
know that the names you use for variables won't ever be used by POVRay 
itself? Your scenes might not render in POVRay 5.

>>It would become possible to access the camera settings to adjust certain 
>>values. This would make the implementation of HUD systems possible 
>>(useful if you want to mark or label certain things in your scene).
> 
> 
>   And XML is the best solution for this because...?

It isn't. XML is a general markup language made by humans and has 
certainly it's flaws. But XML is the best general markup language I know 
of. In fact you might ask any IT professional for the best general 
markup language and most sane will tell you: "Use XML". There is XSLT, a 
general transformation language. It is (with a few tweaks) as powerful 
as the lambda calculus and thus as powerful as POVRay itself.

>>One could even convert whole models to meshes and apply mesh 
>>modificators on them. This is AFAIK not yet possible in POVRay.
> 
>   And how on earth does XML make this any easier? Does XML have some
> magic which will allow you to tesselate any given surface?

Not really. You'd have to code it all yourself. But this is still 
possible. I guess it will take 1/2 year. But the point is: You cannot do 
this at all with POVRay since you cannot access scene objects. XSLT 
could do this. Or what if you wanted an object to appear always in the 
same size. You would have to access the camera data. This cannot be 
written as an POVRay include file. You can write it easily as XSLT 
transformation from one scene to another.

>>Ok, maybe some of these things can be done in POVRay file format. But if 
>>they can be done, how clean can they be done?
> 
> 
>   It is aknowledged that the current SDL has reached its practical limits
> and that a better language may be necessary, but XML is certainly not
> the answer. POV-Ray needs a programming language, not a markup language.

Tell me: What is the fundamental difference between a programming 
language and a markup language. Both are finite. Both have a tree-like 
structure.

Regards,
Bernd Fuhrmann

Post a reply to this message

Thorsten Froehlich wrote:

> Whatever argument for XML you can give, it applies for any other format.
> The use of XML has been discussed to death before, and there are just no
> arguments for it that do not apply to the current format just as well. As
> such, there is no point to argue for XML.  To the contrary, there are things
> you can do in POV-Ray right now that would be incredibly difficult to
> express in XML.

And POVRay can do namespaces how? If it can do namespaces: Why isn't 
there anything written in the documentation? If you have to fake 
namespaces: Why isn't there a coding style guide that will advise people 
how to make extensions to existing include files and libraries?

If you haven't noticed: I'm just asking if someone is interested in 
writing such a system. Noone would be forced to switch to XML. But it 
just doesn't make any sense for me to write such a system on my own. 
Possibly other persons are interested in such a system and I'm looking 
for such persons. If you are not interested, it's ok. I don't want to 
change the default SDL. I just want to add one.

Additionaly I state that POVRay will run into big trouble (known as 
namespace clobbering) in the future. Big projects will be more difficult 
to make due to this.

Regards,
Bernd Fuhrmann

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> >   Because there already is a language which is ten times easier to
> > write and understand.

> But not to transform. Automatic code generation is an important goal. At 
> least I want to achieve it.

  Transform to what?

  You have to still remember that the SDL is a programming language, not
a document.

> >>It would be possible to write material libraries, object libraries and 
> >>so on without clobbering the global namespace.
> > 
> >   If this is the problem, why is XML the solution?

> Because XML supports namespaces via xmlns.

  So what you are basically saying there is that XML is the only
language in the world which supports namespaces?

  Let me rephrase the question: If namespaces are the problem, why XML
is the right solution compared to all other languages (including possible
specific languages which can be created for POV-Ray) supporting namespaces?

  C++ supports namespaces as well. Why would XML be any better than C++?

> How can you 
> know that the names you use for variables won't ever be used by POVRay 
> itself? Your scenes might not render in POVRay 5.

  Why is XML the right solution to this? Why is it better than just
developing a standard convention (eg. that reserved keywords will
always be lowercase, meaning that any variable written with at least
one uppercase letter will never conflict with a keyword)?

> >   And XML is the best solution for this because...?

> It isn't. XML is a general markup language made by humans and has 
> certainly it's flaws. But XML is the best general markup language I know 
> of.

  But that's exactly the problem: POV-Ray scenes are not documents. They
are programs. XML is a markup language, not a programming language.
People want to write, understand and execute SDL scripts, seldom print
them nicely. It just doesn't make any sense to write a program in a
markup language.

> >   And how on earth does XML make this any easier? Does XML have some
> > magic which will allow you to tesselate any given surface?

> Not really. You'd have to code it all yourself. But this is still 
> possible. I guess it will take 1/2 year. But the point is: You cannot do 
> this at all with POVRay since you cannot access scene objects. XSLT 
> could do this.

  In fact, you can (there have been simple tesselation SDL macros out there
which you can give objects to tesselate).

  However, that's besides the point. If accessibility of data is the
problem, why would XML be a better solution than a true programming
language with the required features? Why change a programming language
to a markup language just to get data out of elements?

> Tell me: What is the fundamental difference between a programming 
> language and a markup language. Both are finite. Both have a tree-like 
> structure.

  In a programming language you typically write things like:

(x+y^2)/(k+1)

  In XML you write that like:

<mrow>
  <mfrac>
    <mrow>
      <mi>x</mi>
      <mo>+</mo>
      <msup>
        <mi>y</mi>
        <mn>2</mn>
      </msup>
    </mrow>
    <mrow>
      <mi>k</mi>
      <mo>+</mo>
      <mn>1</mn>
    </mrow>
  </mfrac>
</mrow>

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message