Hi!

I just thought if it might be possible to use XML to describe a scene. 
In my opinion, this would have a lot of advantages: Namespaces, ability 
to transform whole scenes using XSLT and the ability to retrieve data 
from POVXML-files and use them somewhere else.

It wouldn't pose AFAIK any problem to write a XSLT-script that would 
transform an XML-document to POVRay file format. Obviously this works 
only in one direction. It is, however some work to do so since all 
POVRay features would have to be mapped to XML.

I'd like to know if there is already such a system planned or implemented.
If not: Is anyone except me interested in implementing such a system?

What do you think about this idea?

Thanks in advance
Bernd Fuhrmann

Post a reply to this message

Bernd Fuhrmann wrote:
> Hi!
> 
> I just thought if it might be possible to use XML to describe a scene. 
> In my opinion, this would have a lot of advantages:

In short: nothing prevents you from doing so (at least theoretically) 
but you should bear in mind the following thing: no one sane who uses 
POV-Ray for serious work will write a scene in XML or use XML to store 
scene data.  If you have trouble imagining why this is the case just 
have a look at Yafray.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> In short: nothing prevents you from doing so (at least theoretically) 
> but you should bear in mind the following thing: no one sane who uses 
> POV-Ray for serious work will write a scene in XML or use XML to store 
> scene data.  If you have trouble imagining why this is the case just 
> have a look at Yafray.

I just had a look at it. Yafray seems to support only meshes. This is 
certainly not a good approach. This will lead to big XML files. XML as 
low level language can't be a good idea since processing speed does 
matter. But what about a high level XML representation? There wouldn't 
be that bad processing speed impacts.

On the other hand: The POVRay file format is not that open to 
extensions. There isn't a reasonable naming scheme which would allow to 
use codesnippets from all kinds of people in one single project. So for 
real big and long-term projects XML would definately be the markup 
language of choice.

Bernd Fuhrmann

Post a reply to this message

On Fri, 31 Dec 2004 10:02:16 +0100, Bernd Fuhrmann <Sil### [at] gmxde>
wrote:
> What do you think about this idea?

As Christoph said.

FYI: http://www.web3d.org/x3d/overview.html

ABX

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> I just thought if it might be possible to use XML to describe a scene. 
> In my opinion, this would have a lot of advantages: Namespaces, ability 
> to transform whole scenes using XSLT and the ability to retrieve data 
> from POVXML-files and use them somewhere else.

  I really don't see those as advantages.

  No-one will write XML scenes by hand, so what's the point?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>I just thought if it might be possible to use XML to describe a scene. 
>>In my opinion, this would have a lot of advantages: Namespaces, ability 
>>to transform whole scenes using XSLT and the ability to retrieve data 
>>from POVXML-files and use them somewhere else.
> 
> 
>   I really don't see those as advantages.
> 
>   No-one will write XML scenes by hand, so what's the point?

Why not? It isn't that difficult. People write XHTML, MathML and even 
SVG by hand. At least I do. So why not POVRay? There are a lot of 
advantages:

It would be possible to write material libraries, object libraries and 
so on without clobbering the global namespace.
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).

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

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?

Regards,
Bernd Fuhrmann

Post a reply to this message

Bernd Fuhrmann wrote:
>>
>>   No-one will write XML scenes by hand, so what's the point?
> 
> 
> Why not? It isn't that difficult.

That's not the point.  You can either take my word on it that people 
won't do it or ignore the fact - the result will be the same.  The same 
ideas are brought up from time to time in these newsgroups - 
interestingly usually not by people who use POV-SDL a lot.

You can easily find previous discussions on this matter by searching 
these newsgroups, for example:

http://news.povray.org/povray.general/thread/<Xns94B1A5863FF0DZenZenPsychocom%40203.29.75.35>
http://news.povray.org/povray.programming/thread/<38CE3B1A.80B4F27%40nigels.com>

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 31 Dec 2004 13:12:46 +0100, 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?

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.

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

> It would become possible to access the camera settings to adjust certain 
> values.

See screens.inc include file solutions.

> This would make the implementation of HUD systems possible 

Head Up Displays you mean? Which application you mean exactly?

> (useful if you want to mark or label certain things in your scene).

? Anything you can't do currently?

> 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

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

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

ABX

Post a reply to this message

in news:s1hat0h78j5s8q34g4e8308c8aubiv6230@4ax.com ABX 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.

Ingo

Post a reply to this message

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

Post a reply to this message

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 () {
  If Schrödingers_cat is alive  
    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

in news:37jat050gpl1jhjhfl290afmkdbivt0f7q@4ax.com ABX wrote:

> And usually how hard it is to solve such issue?
> 

The first time it happend it took a day to figure it out, but generaly 
it's not a big problem. Still I think namespaces wouldn't be a bad thing 
to have in a future version of POV-Ray (maybe even alongside with a 
"better" way of dealing with include-file packages).


from: The Zen of Python
- Namespaces are one honking great idea -- let's do more of those!

   -- Tim Peters  ( http://www.python.org/doc/Humor.html#zen )

Ingo

Post a reply to this message

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

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

No, only the marketing department will.  Just like marketing departments
told everybody that Java is the best general programming language five years
ago.  XML is nothing but a huge hype producing documents several times the
size of a well-designed binary counterpart that can be just as "easy" to
parse (that that XML is trivial to parse).  XML certainly has its
applications, but they are limited, not universal.

Just compare the traditional VRML (POV-Ray-like) syntax version to the XML
syntax version of X3D. It will give you a very good idea why XML is
unsuitable for describing 3D data.  In fact, X3Ds XML representation is
probably one of the best examples of pointless use of XML.  Just consider
how lists of vectors are expressed in X3D XML syntax and you should really
notice.  Of course, the problem with keeping them in strings is the result
of an inherent limitation of XML expressing data only as complex, nested
collections of strings.

>  You cannot do
> this at all with POVRay since you cannot access scene objects.

That is true, you cannot do this in POV-Ray currently, but it is not a
limitation of the SDL (scene description language) but the parser design,
which is 15 years old and fairly outdated (and the 4.0 rewrite will take
care of this).

    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

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

> And POVRay can do namespaces how? If it can do namespaces: Why isn't

Macros provide namespaces (#local), as do include files (#local in an
include file stays local to that file).  That there are no named namespaces
(which is what you are effectively asking for) is simply a matter of nobody
having written code for it.  It is easy to add even to the current parser.

Of course, namespaces are not an answer to naming convention problems.  You
can have the same namespace name in two files and run into the exact same
problem you created namespaces for in the first place.

The documentation advises users to not use all lower-case identifiers for
user defined declares and macros as lower-case identifiers are reserved for
use by POV-Ray.  This leaves plenty of names for users.  Prefixing has
almost the same effect as using namespaces, and looking at APIs of modern
operating systems, they do really well without need for namespaces despite
using tens of thousands of identifiers.  Of course named namespaces offer a
very valuable extension to any language, including POV-Ray SDL, not having
them is only a minor annoyance, not a huge problem.

    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

Thorsten Froehlich wrote:
> In article <41d6806b$1@news.povray.org> , Bernd Fuhrmann 
> <Sil### [at] gmxde>  wrote:
> 
> 
>>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".
> 
> 
> No, only the marketing department will.  Just like marketing departments
> told everybody that Java is the best general programming language five years
> ago.  XML is nothing but a huge hype producing documents several times the
> size of a well-designed binary counterpart that can be just as "easy" to
> parse (that that XML is trivial to parse).  XML certainly has its
> applications, but they are limited, not universal.

There is a hype for XML, yes. XML is not universal, true. To give a 
simple example: XML will never be suited to save MPEG movies. It's just 
a matter of space and decoding speed. XML is not suited to contain 
executable files since they don't really interoperability. But POVRay 
files are rather small. Parsing speed does not matter that much. They 
contain highly structured data. So XML is suited to contain that data. 
XML is, however, a bit hard for newbies to write, I admit.

But who was desperately in need of some harddrive space and started to 
tweak his POVRay files? Who used shorter identifiers to save some drive 
space? Use of XML will result in files that have three or four times the 
size of normal POVRay files. So what?

Besides: There is a binary version of XML under development. If it might 
be used to contain binary data it will rock like hell, if used properly.

> Just compare the traditional VRML (POV-Ray-like) syntax version to the XML
> syntax version of X3D. It will give you a very good idea why XML is
> unsuitable for describing 3D data.  In fact, X3Ds XML representation is
> probably one of the best examples of pointless use of XML.  Just consider
> how lists of vectors are expressed in X3D XML syntax and you should really
> notice.  Of course, the problem with keeping them in strings is the result
> of an inherent limitation of XML expressing data only as complex, nested
> collections of strings.

XML is just a way to give a document (which does include programs 
aswell) structure that is easy to parse. It does not specify the 
structure itself. I'd make the structure almost equivalent to POVRay's 
structure. So there wouldn't be that much overhead to vectors, numbers 
and things. But one would have instantly have some powerful parser that 
are able to assemble scenes. You'd have to write such a parser in POVRay 
which is a hard task.

>> You cannot do
>>this at all with POVRay since you cannot access scene objects.
> 
> That is true, you cannot do this in POV-Ray currently, but it is not a
> limitation of the SDL (scene description language) but the parser design,
> which is 15 years old and fairly outdated (and the 4.0 rewrite will take
> care of this).

Interesting: So you suggest to keep the SDL while adding commands to 
access scene objects, right? But how can one access scene objects 
without some kind of object model? Example:

Assume you have some scene like this:

---
camera {location <10,20,10> look_at <0,0,0>}
light_source {<-140,200,300> rgb <1.0, 1.0, 1>*2}
sphere {<-2,0,0> 1 pigment {rgb <1,0,0>}}
sphere {<0,0,0> 1 pigment {rgb <0,1,0>}}
sphere {<2,0,0> 1 pigment {rgb <0,0,1>}}
---

So how would you write a transformation like "Replace all sphere by a 
certain mesh"? Suggest a syntax! Do you know any programming language 
what is able to access it's own objects that way?

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?

Regards,
Bernd Fuhrmann

Post a reply to this message

in news:41d51598@news.povray.org Bernd Fuhrmann wrote:

> What do you think about this idea?
> 

After reading most of the thread, I get the impression that you have a 
"problem" and that your "solution" to that "problem" is XML. I think I 
have a simmilar "problem", 'all one can do with a .pov file is render it 
with POV-Ray'.

I.m.o XML itself is not the solution. You gave one reason: "Obviously 
this works only in one direction". Others gave many other reasons.

What we'd need is a POV-Ray parser, and currently the only one available 
is POV-Ray and we can't use that for other purposes. I tried writing one 
in Python, but gave up due to severe lack of skills.

Once you have a POV-parser (with a liberal enough licence and with some 
API or bindings or ...) you can do many things with a scene, even 
convert it to some form of XML if you like.


Ingo

Post a reply to this message

Warp wrote:
> 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?

POVXML(with a lot of extensions) -> POVXML(with fewer extensions) -> 
POVXML(with no extensions) -> POVRay SDL -> BMP
> 
>   You have to still remember that the SDL is a programming language, not
> a document.

What's the difference?

>>>>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++?

C++ is VERY capable of using namespaces (and it totally rocks). I use 
them everytime. C++ namespaces in POVRays SDL would be cool. They would, 
if used properly, add a lot usability to POVRay. But how are you going 
to do them without changing POVRay itself?

>>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)?

XML offers all these things in one standard that many people know of. Of 
course you might also develop some standard conventions, but: Hell, am I 
the first one who preaches people to develop and use such conventions? 
Where are those people? Why isn`t it in the POVRays manual on the first 
page then? If you think this is the way to go then let's go that way! 
Let's develop such a naming scheme. It's about time!

You can on the other hand use a standart that is already there, like XML 
instead of developing a new one.

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

XML can also be used for programming languages. It is a _general_ markup 
language. It's not limited to documents. Just look at XSLT.

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

Because there is already a general transformation language that can 
access any XML document. It's called XSLT. So why invent the wheel twice?

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

Bad example. No, I'm not suggesting to do something like this:

<sphere>
	<center>
		<vector>
			<x>0</x>
			<y>0</y>
			<z>0</z>
		</vector>
	</center>
	<radius>5</radius>
</sphere>

but rather this:
<sphere center="0,0,0" radius="5"/>

compare this to:
sphere {<0,0,0> 5}

The structure doubles the size. This is still feasable. You spend more 
that much time typing sphere anyway. Most time will be spent thinking 
and rendering. So: Why not using XML instead of developing all kinds of 
naming schemes, another document object model and so on?

Regards,
Bernd Fuhrmann

Post a reply to this message

Thorsten Froehlich wrote:

> Of course, namespaces are not an answer to naming convention problems.  You
> can have the same namespace name in two files and run into the exact same
> problem you created namespaces for in the first place.

Which is why I prefer the way namespaces are done in XML instead of C++. 
If you have a domain you have your own namespace. Just that simple. Any 
idea if it can be done better than that?

I know who I am. I know what I will develop. So what prefix should I 
use? This isn't in the manual.

> The documentation advises users to not use all lower-case identifiers for
> user defined declares and macros as lower-case identifiers are reserved for
> use by POV-Ray.  This leaves plenty of names for users.  Prefixing has
> almost the same effect as using namespaces, and looking at APIs of modern
> operating systems, they do really well without need for namespaces despite
> using tens of thousands of identifiers.  Of course named namespaces offer a
> very valuable extension to any language, including POV-Ray SDL, not having
> them is only a minor annoyance, not a huge problem.

Prefixes are fine, at least partially. They can add a lot of overhead. 
Namespaces would be better. But you are certainly right: It's not a huge 
problem. On the other hand: Why not doing things right as soon as possible?

Regards,
Bernd Fuhrmann

Post a reply to this message

ingo wrote:
> in news:41d51598@news.povray.org Bernd Fuhrmann wrote:
> 
> 
>>What do you think about this idea?
>>
> 
> 
> After reading most of the thread, I get the impression that you have a 
> "problem" and that your "solution" to that "problem" is XML. I think I 
> have a simmilar "problem", 'all one can do with a .pov file is render it 
> with POV-Ray'.

Exactly. You got my point. I want to do more with my scenes.

> I.m.o XML itself is not the solution. You gave one reason: "Obviously 
> this works only in one direction". Others gave many other reasons.

Depends on what you see as solution. It's might be possible to parse 
POVRay SDL with XSLT. But it's slow and a lot of work. As long as there 
are no other solutions XML might be the best of many bad ones.

> What we'd need is a POV-Ray parser, and currently the only one available 
> is POV-Ray and we can't use that for other purposes. I tried writing one 
> in Python, but gave up due to severe lack of skills.

With the right help this is possible. Are you interested in anything 
like this? Write me an email.

> Once you have a POV-parser (with a liberal enough licence and with some 
> API or bindings or ...) you can do many things with a scene, even 
> convert it to some form of XML if you like.

Is (L)GPL ok?

Regards,
Bernd Fuhrmann

Post a reply to this message

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

>> Once you have a POV-parser (with a liberal enough licence and with some
>> API or bindings or ...) you can do many things with a scene, even
>> convert it to some form of XML if you like.
>
> Is (L)GPL ok?

No, only a BSD license would be OK to facilitate use of a format in
commercial applications and allow them to make changes to the code (not the
format, but that cannot be prevented by either license).

    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

Thorsten Froehlich wrote:
  > No, only a BSD license would be OK to facilitate use of a format in
> commercial applications and allow them to make changes to the code (not the
> format, but that cannot be prevented by either license).

BSD? Agreed. Interested?

Regards,
Bernd Fuhrmann

Post a reply to this message

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

> XML is just a way to give a document (which does include programs
> aswell) structure that is easy to parse. It does not specify the
> structure itself. I'd make the structure almost equivalent to POVRay's
> structure.

OK, please provide XSLT that transforms a non-trivial X3D XML mesh to a
POV-Ray mesh.  Just the geometry.  I would love to see the XSLT and its
complexity ... so show me that I am wrong if you can!

    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

Thorsten Froehlich wrote:
> In article <41d6ae1a$1@news.povray.org> , Bernd Fuhrmann 
> <Sil### [at] gmxde>  wrote:
> 
> 
>>XML is just a way to give a document (which does include programs
>>aswell) structure that is easy to parse. It does not specify the
>>structure itself. I'd make the structure almost equivalent to POVRay's
>>structure.
> 
> 
> OK, please provide XSLT that transforms a non-trivial X3D XML mesh to a
> POV-Ray mesh.  Just the geometry.  I would love to see the XSLT and its
> complexity ... so show me that I am wrong if you can!

No I won't. Its quite a task to write such a XSLT. I have never worked 
with X3D. It would take me weeks to learn X3D just to proove that it is 
possible.

But if you want to see XSLT in action:

I have attached a little XSLT transformation that transforms data from a 
log file (almost plaintext, written by a simple PHP script), analyzes it 
and displays some statistical information about it. I hope the power of 
XSLT becomes visible. XSLT can also output plain text. So I could even 
render this data with POVRay. That would just be a few lines. Ok it 
would be useless. But at least it's possible. And I wouldn't have to 
write my own parser for it. This saves me a LOT of time. It would be 
cool if I could access POVRay SDL the same way and display automatic 
generated data from it aswell. That is what I try to achieve (among 
other things).

Regards,
Bernd Fuhrmann

Post a reply to this message

Attachments:
Download 'us-ascii' (3 KB)

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

> No I won't. Its quite a task to write such a XSLT.

Exactly that was my point ;-)

> I have never worked
> with X3D. It would take me weeks to learn X3D just to proove that it is
> possible.

Well, the only real difference is that there are no commas (well, they are
optional in VRML, they are just like spaces) and no < > around vectors, and
X3D keeps all coordinates in a *single* string.  It takes almost nothing to
transform a classic VRML-style X3D mesh to POV-Ray (one can do it with a
simple regular expression), but to transform the same X3D XML lots of manual
tweaking is needed to just *remove* redundant XML syntax that serves no
useful purpose at all!

    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

Thorsten Froehlich wrote:
> In article <41d6c310$1@news.povray.org> , Bernd Fuhrmann 
> <Sil### [at] gmxde>  wrote:
> 
> 
>>No I won't. Its quite a task to write such a XSLT.
> 
> 
> Exactly that was my point ;-)
> 
> 
>>I have never worked
>>with X3D. It would take me weeks to learn X3D just to proove that it is
>>possible.
> 
> 
> Well, the only real difference is that there are no commas (well, they are
> optional in VRML, they are just like spaces) and no < > around vectors, and
> X3D keeps all coordinates in a *single* string.  It takes almost nothing to
> transform a classic VRML-style X3D mesh to POV-Ray (one can do it with a
> simple regular expression), but to transform the same X3D XML lots of manual
> tweaking is needed to just *remove* redundant XML syntax that serves no
> useful purpose at all!

I just wrote a little demo XSLT that puts commas where once were spaces 
in transform/translation attributes and adds < and > to the beginning 
and end. If you want anything more complex please send me an example 
what transformation you want. Btw: I'm not a very good XSLT programmer. 
I just use it for the creation of my small private webpage. So don't 
expect me to write complex parsers that would take a pro months.

<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet	version="2.0" 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns=""
 >

<xsl:output method="xml" encoding="iso-8859-1"/>

<xsl:template match="*|@*|text()|processing-instruction()">
<xsl:copy>
<xsl:apply-templates select="*|@*|text()|processing-instruction()"/>
</xsl:copy>
</xsl:template>

<xsl:template match="Transform">
<Transform>
<xsl:attribute name="translation"><<xsl:analyze-string 
select="@translation" regex=" +">
<xsl:matching-substring>,</xsl:matching-substring>
<xsl:non-matching-substring><xsl:value-of 
select="."/></xsl:non-matching-substring>
</xsl:analyze-string>></xsl:attribute>
</Transform>
</xsl:template>
</xsl:stylesheet>

Tested with this input:
---
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.0//EN"

"http://www.web3d.org/specifications/x3d-3.0.dtd">

<X3D profile='Immersive' 
xmlns:xsd='http://www.w3.org/2001/XMLSchema-instance'

xsd:noNamespaceSchemaLocation='http://www.web3d.org/specifications/x3d-3.0.xsd'>
<head>
<meta name='filename' content='Figure02.1Hut.x3d'/>
<meta name='author' content='The VRML 2.0 Sourcebook, Copyright [1997] 
By Andrea L.

Ames, David R. Nadeau, and John L. Moreland'/>
<meta name='translator' content='Don Brutzman'/>
<meta name='created' content='6 August 2000'/>
<meta name='revised' content='9 July 2003'/>
<meta name='description' content='Your first VRML world - a brown hut.'/>
<meta name='url'

content='http://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter02-Introdu

ction/Figure02.1Hut.x3d'/>
<meta name='generator' content='X3D-Edit,

http://www.web3d.org/x3d/content/README.X3D-Edit.html'/>
</head>
<!--
Index for DEF node: BROWN
-->
<Scene>
<!-- This NavigationInfo node is added to many scenes, making 
examination of objects

easier -->
<NavigationInfo type='"EXAMINE" "ANY"'/>
<Group>
<Shape>
<Appearance DEF='BROWN'>
<Material diffuseColor='0.8 0.6 0.3'/>
</Appearance>
<!-- Default Cylinder height=2, centered about origin -->
<Cylinder radius='2'/>
</Shape>
<Transform translation='0 2 0'>
<Shape>
<Appearance USE='BROWN'/>
<!-- Default Cone height=2, centered about local origin -->
<Cone bottomRadius='2.5'/>
</Shape>
</Transform>
</Group>
</Scene>
</X3D>
---
[Taken from 
http://www.web3d.org/x3d/content/examples/Vrml2.0Sourcebook/Chapter02-Introduction/_pages/page01.html]
I know this is not what you wanted. But this script could be extended so 
that it might do things more complete. I do not yet know enough about 
X3D to write anything that actually makes sense. Please provide an 
example if you are interested.

Regards,
Bernd Fuhrmann

Post a reply to this message

Bernd Fuhrmann wrote:
> But POVRay 
> files are rather small. Parsing speed does not matter that much.

I just wanted to point out this particular statement for those who do 
not follow this thread very closely...

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Darren New wrote:
> Bernd Fuhrmann wrote:
> 
>> Do you know any programming language what is able to access it's own 
>> objects that way?
> 
> 
> Quite a few. LISP, Tcl, Forth, etc. The term you're looking for is 
> either "introspection" or "reflection", depending on precisely what 
> kinds of data you're looking for.
Thanks for that hint. You're right. Some commonly used languages are 
indeed introspective.

Regards,
Bernd Fuhrmann

Post a reply to this message

in news:41d6b8d7$1@news.povray.org Bernd Fuhrmann wrote:

>> I tried writing one in Python, but gave up due to severe lack of
>> skills. 
> 
> With the right help this is possible. Are you interested in anything 
> like this? Write me an email.

I'm interested in a POV-Ray parser, but I have no time to work on anything 
like that at the moment. And, I've set my hopes on POV-Ray 4, let it come 
with a libpovparse, libpovwrite (so we can have decent and uniform output 
from modellers), libpovNURBSs, libpovspline, .... (dream on).

>> Once you have a POV-parser (with a liberal enough licence and with
>> some API or bindings or ...)
> Is (L)GPL ok?

Nope, BSD/MIT or Public Domain.

Ingo

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> >   Transform to what?

> POVXML(with a lot of extensions) -> POVXML(with fewer extensions) -> 
> POVXML(with no extensions) -> POVRay SDL -> BMP

  So what you want is a *separate* application which converts your
pov-XML to SDL and then uses POV-Ray to render the image?

  Then why not just go ahead and create such XML specification? Let's see
how much people will be using it...

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

> What's the difference?

  By definition in a markup language you have to tell for each distinct
item its type (in XML in the most cumbersome way with starting and
ending tags). An XML parser can then do something with each type
according to some specification of how each type should be interpreted.

  In a programming language you don't need to specify the type of
each item which appears in the program source code. This is because
a programming language is typically not designed so that it can be
parsed with a generic markup parser but needs a parser specific to
that programming language. The advantage of this is, naturally, that
it makes it easier for the user to write programs using this language
because it's the language parser which performs the task of tokenizing
the input, not the user.

  If you write XML by hand you are burdened with this extra task which
should be something the parser does.

  Besides, being a very generic markup language which does not offer
anything specific to any programming language, most programmatical
constructs need to be done either with extremely bloated syntax
where you (not the parser) tell the program for each single item
what it is, or either you use a very artificial syntax of putting
the whole thing into a string (which you should not be required to do
in the first place; just the fact that the quotation marks and other
extra syntax around these strings are not part of the expression should
immediately give you a hint that there's something unneeded there).

  In a programming language you say typically: a=b;
  Now, just think about how you would do that same thing in XML and
how much of that line will be additional bloat which is not really
part of the command but is required by XML. Also think why the user
should write that extra stuff when there's no need.

  The user and the program (in this case POV-Ray) are not interested
in the markup of the input, they are only interested in its meaning.
It just doesn't make any sense to force the user to specify any
markup on the input since none is needed for anything.

> XML offers all these things in one standard that many people know of.

  Can't you understand that XML is not the right tool for writing a
program? Programs are usually written by hand, and this task should be
made as easy as possible.

  What you are suggesting is making the life of the users harder in order
to make the life of the programs easier.

> <sphere center="0,0,0" radius="5"/>

> compare this to:
> sphere {<0,0,0> 5}

  Why should the user be burdened with all that additional syntax?
What does it benefit the user that he is forced to write all those
extra symbols and keywords?

  Besides, that extremely simplistic example is too naive. How would
you write this in XML so that it makes the life easier for someone
(for the user, or the parser, or the renderer or anyone):

union
{ #declare IndX = 0;
  #while(IndX < MaxX)
    #declare IndY = 0;
    #while(IndY < MaxY)
      sphere
      { <IndX*5+1, IndY*0.25-1.25, -5>, IndX*IndY/10
        #if(IndX < MaxX/2)
          pigment { rgb <IndX/MaxX, IndY/MaxY, 0> }
        #end
      }
      #declare IndY = IndY*.125;
    #end
    #declare IndX = IndX*.5;
  #end

  pigment { rgb x } finish { specular .5 roughness .03 }
}

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

Christoph Hormann <chr### [at] gmxde> wrote:
> > But POVRay 
> > files are rather small. Parsing speed does not matter that much.

> I just wanted to point out this particular statement for those who do 
> not follow this thread very closely...

  Thanks for the ROTFL. I missed that one. :)

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

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>>  Transform to what?
> 
> 
>>POVXML(with a lot of extensions) -> POVXML(with fewer extensions) -> 
>>POVXML(with no extensions) -> POVRay SDL -> BMP
> 
> 
>   So what you want is a *separate* application which converts your
> pov-XML to SDL and then uses POV-Ray to render the image?

Exactly!

>   Then why not just go ahead and create such XML specification? Let's see
> how much people will be using it...

I can do that, sure. I'd have to spend a lot of time for that. But why 
should I do that if I would become the only user of this specification? 
If one single person (me) works on such a specification it would 
certainly have errors. I need people to correct it and just test it. So 
I thought: "Maybe it's a good idea to search for other people who are 
interested in such a thing for it might prove really useful". That is 
why I posted.
So: Is there anybody interested?

>>>  You have to still remember that the SDL is a programming language, not
>>>a document.
> 
> 
>>What's the difference?
> 
> 
>   By definition in a markup language you have to tell for each distinct
> item its type (in XML in the most cumbersome way with starting and
> ending tags). An XML parser can then do something with each type
> according to some specification of how each type should be interpreted.
> 
>   In a programming language you don't need to specify the type of
> each item which appears in the program source code. This is because
> a programming language is typically not designed so that it can be
> parsed with a generic markup parser but needs a parser specific to
> that programming language. The advantage of this is, naturally, that
> it makes it easier for the user to write programs using this language
> because it's the language parser which performs the task of tokenizing
> the input, not the user.
> 
>   If you write XML by hand you are burdened with this extra task which
> should be something the parser does.
> 
>   Besides, being a very generic markup language which does not offer
> anything specific to any programming language, most programmatical
> constructs need to be done either with extremely bloated syntax
> where you (not the parser) tell the program for each single item
> what it is, or either you use a very artificial syntax of putting
> the whole thing into a string (which you should not be required to do
> in the first place; just the fact that the quotation marks and other
> extra syntax around these strings are not part of the expression should
> immediately give you a hint that there's something unneeded there).
> 
>   In a programming language you say typically: a=b;
>   Now, just think about how you would do that same thing in XML and
> how much of that line will be additional bloat which is not really
> part of the command but is required by XML. Also think why the user
> should write that extra stuff when there's no need.
> 
>   The user and the program (in this case POV-Ray) are not interested
> in the markup of the input, they are only interested in its meaning.
> It just doesn't make any sense to force the user to specify any
> markup on the input since none is needed for anything.

I think I start to get your point. As you observed: I don't think it is 
wise to force anybody to another syntax. I just think there should be an 
alternative. POVRay SDL is ok for a wide range of tasks. But not for all.

So it's basically a trade-off between parser complexity and 
syntax-ease-of-use. But there are cases in which I want to parse a 
POVRay SDL myself, for example to do certain conversions or adaptions. 
If there was some API for that parser my problem would be (almost) 
solved. But there is none. There are still features missing in that damn 
thing and POVRay 4.0 isn't even in development yet. At least I couldn't 
find a bit of information about it except that it is supposed to be 
great and so on; nothing specific. What do you suggest to solve this 
problem? Write an own parser for POVRay SDL? Change POVRay SDL?

>>XML offers all these things in one standard that many people know of.
> 
> 
>   Can't you understand that XML is not the right tool for writing a
> program? Programs are usually written by hand, and this task should be
> made as easy as possible.

I do understand that. But POVRay SDL isn't a full featured programming 
langugage. It seems to me to be comparable to BASIC but not even to 
Pascal or gems like C++. So POVRay SDL has to move on, definately. But I 
don't see that neccessary movement yet.

>   What you are suggesting is making the life of the users harder in order
> to make the life of the programs easier.

Almost right. If you write parsers you will be glad of this.

>><sphere center="0,0,0" radius="5"/>
> 
> 
>>compare this to:
>>sphere {<0,0,0> 5}
> 
> 
>   Why should the user be burdened with all that additional syntax?
> What does it benefit the user that he is forced to write all those
> extra symbols and keywords?
> 
>   Besides, that extremely simplistic example is too naive. How would
> you write this in XML so that it makes the life easier for someone
> (for the user, or the parser, or the renderer or anyone):
> union
> { #declare IndX = 0;
>   #while(IndX < MaxX)
>     #declare IndY = 0;
>     #while(IndY < MaxY)
>       sphere
>       { <IndX*5+1, IndY*0.25-1.25, -5>, IndX*IndY/10
>         #if(IndX < MaxX/2)
>           pigment { rgb <IndX/MaxX, IndY/MaxY, 0> }
>         #end
>       }
>       #declare IndY = IndY*.125;
>     #end
>     #declare IndX = IndX*.5;
>   #end
> 
>   pigment { rgb x } finish { specular .5 roughness .03 }
> }
> 


Hm, interesting example. You might have a 1:1 translation like this:

<union>
<declare l="IndX" v="0"/>
<while cond="IndX<MaxX">
<declare l="IndY" v="0"/>
<while cond="IndY<MaxY">
and so on...
</while>
</union>

You also might also leave it to XSLT to execute your programming stuff. 
That might look like this:

<!-- MaxX and MaxY have to be known at transformation time-->
<xsl:template name="myloopinner">
<xsl:param name="IndY"/>
<xsl:param name="IndX"/>
<xsl:if test="$IndX < $MaxX"/>
<sphere center="$IndX*5+1, $IndY/4-1.25, -5" radius="$IndX*$IndY/10">
<rgbpigment value="$IndX/$MaxX, IndY/MaxY, 0"/>
</sphere>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX"/>
<xsl:with-param name="IndY" select="$IndY/8"/>
</xsl:if>
</xsl:template>

<xsl:template name="myloopouter">
<xsl:param name="IndX"/>
<xsl:if test="$IndX < $MaxX"/>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX"/>
<xsl:with-param name="IndY" select="0"/>
</xsl:call-template>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX/2"/>
</xsl:call-template>
</xsl:if>
</xsl:template>

<union>
<xsl:call-template name="myloopouter"/>
<xsl:with-param name="IndX" select="0"/>
</xsl:call-template>
<rgbpigment and so on>
</union>

This is terrible code. I do hate pure XSLT. There are, however, some 
systems that simplify the use of loops and so on. I just haven't had a 
closer look at them yet. A very promising project seems to be here: 
http://sourceforge.net/projects/xsltsl/

One other thing: I haven't tested this code. It's quite likely that it 
won't work. But I hope you see that it is at least possible. People who 
are used to work with XSLT will most likely find much cleaner and 
simpler solutions.


Besides: Your code is nonsense. 0*0.125 is always 0. Your code will 
either do nothing or never finish.

Regards,
Bernd Fuhrmann

Post a reply to this message

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

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

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

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.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

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

Post a reply to this message

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

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

Sorry, but you just disqualified yourself. There is no point to continue
this whole thread based on your current knowledge.

    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

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> But POVRay SDL isn't a full featured programming langugage.

  What is, in your opinion, a "full featured programming language"?
  The SDL is turing-complete.

> and so on...

  Exactly my point. Too tedious to write?

  Besides, you conveniently skipped the hard parts of the code, for
example the conditional inside the sphere.

  What good does it do to simply put the code into quotation marks and
add some extra junk around them? That doesn't help the user nor the
program trying to interpret the code (it simply gets the code as a
bunch of strings which it has to parse and interpret anyways, without
the help of any XML parser).

> Besides: Your code is nonsense. 0*0.125 is always 0. Your code will 
> either do nothing or never finish.

  Besides the point. It was just an abstract example. Set the initial
values to 1 if you want to feel better about it. ;)

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

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>But POVRay SDL isn't a full featured programming langugage.
> 
>   What is, in your opinion, a "full featured programming language"?
>   The SDL is turing-complete.

Yes, it is. There are a lot of features missing that are used in a lot 
of modern programming languages. Examples:
* Structs/Classes
* References, esp. to functions
* Namespaces
* strict type checking

Other possibly cool features
* Inheritance
* Java-like classes inside classes
* C++ like multiple inheritance
* Lambda expressions (Scheme)

>>and so on...
> 
> 
>   Exactly my point. Too tedious to write?

Well, yes. But I'm even more tedious to rewrite that POVRay parser.

>   Besides, you conveniently skipped the hard parts of the code, for
> example the conditional inside the sphere.

Ooops. Sorry for that. What you're missing is this:
[...]
<sphere center="$IndX*5+1, $IndY/4-1.25, -5" radius="$IndX*$IndY/10">
<xsl:if test="$IndX<MaxX/2">
<rgbpigment value="$IndX/$MaxX, IndY/MaxY, 0"/>
</xsl:if>
</sphere>
[...]

But as I just found out: XSLT won't be able to do all transformations 
that POVRay would be able to do, since POVRay knows sometimes more about 
objects (like max_extent) and so on. Sorry for not knowing this.

Still, this does not solve those namespace and data access problems. 
There still needs something to be done. I just have to think about 
another way...

>   What good does it do to simply put the code into quotation marks and
> add some extra junk around them? That doesn't help the user nor the
> program trying to interpret the code (it simply gets the code as a
> bunch of strings which it has to parse and interpret anyways, without
> the help of any XML parser).

XSLT can process it. Nothing more nothing less.

>>Besides: Your code is nonsense. 0*0.125 is always 0. Your code will 
>>either do nothing or never finish.
> 
> 
>   Besides the point. It was just an abstract example. Set the initial
> values to 1 if you want to feel better about it. ;)

Ok, never mind.

I must admit that using XML/XSLT exclusively for scene design and 
parsing is mad. But on the other hand I will still require a SDL that 
has more features, with configurable preprocessing levels. To give you a 
nice example: What about a JavaDoc/Doxygen-like processing? Wouldn't 
that be cool?

Regards,
Bernd Fuhrmann

Post a reply to this message

Darren New wrote:
> Bernd Fuhrmann wrote:
> 
>> Yes, it is. There are a lot of features missing that are used in a lot 
>> of modern programming languages. Examples:
>> * Structs/Classes
>> * References, esp. to functions
>> * Namespaces
>> * strict type checking
> 
> 
> There are plenty of large high-performance production servers as well as 
> end user desktop software written in languages that lack most or all of 
> these features. Their lack doesn't make programming languages "not real".
> 
>> <xsl:if test="$IndX<MaxX/2">
> 
> 
> The problem with doing something like this is, you then get to ask a 
> question like "transform this scene to remove items that fail this 
> condition."  How about "select in this scene objects that don't 
> intersect the sphere"?

This is not possible without giving XSLT some information about what a 
sphere is. This is possible, but it will get

> If you're not going to code everything in XML, anything you don't code 
> in XML is going to be opaque to whatever transforms you want to do. You 
> won't even be able to say "shift this element 10 units right."

Right.

>> Still, this does not solve those namespace and data access problems. 
>> There still needs something to be done. I just have to think about 
>> another way...
> 
> Write a parser for SDL. Since the help files describe the SDL using 
> basically BNF notation, you can use yacc/bison to write a parser for it. 
> I'm not understanding why it would be difficult, unless the docs don't
> match the reality, in which case you have a bug report. I mean, you
> even get the source to an existing parser, yes? :-)

I could write my own parser, sure. But that wouldn't fix the problem. 
I'd still have unprocessable code.

As mentioned earlier: I will have to think about something different to 
solve my problem. XML is a solution but due to certain limits of XSLT 
not the best one.

Regards and thanks for all your comments,
Bernd Fuhrmann

Post a reply to this message

This thread was intersting to read.
I think you guys both (Warp, Bernd) made the point.
I really did think that xml might be more universal way to code.
Povray is just very specific and only for 3d modeling.
But then you realize all the drawbacks... XML is really bloated and less 
convenient to read and code, no doubts, even though it may have some 
advanced features, which most of people will use very rarely.
It took me 3-4 days to learn and start understanding Povray codings, but 
xml I'm not sure at all. For me it would be annoying even to always 
write < /> and at the same time it is really easy to learn Povray (if 
you familiar with progr. languages).

Another point made by Bernd and he is right that Povray SDL indeed needs 
more features to be implemented, I very much support his idea about
1.Namespaces
2.Classes and inheritance
3.References
So you see closer to C++ cooler:)

And they should be easier and more intersting to implement than to write 
another parser (for the language which standart may change). Sure that's 
a heck of a work, but eventually it should be done.
I'd love too see some of these features in the next version of Povray.

Andrey Skvortsov

Post a reply to this message

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

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

I think you are wrong and really underestimate current povray 
capabilities!  What you have written (except discussed namespaces)  can 
be done without a problem right   now. Not exactly the way you wrote but 
similar, there are such things in Povray called objects... RTFM.
You can create your arrays of humans and pass the through the mesh() and 
    not too ugly.

Andrey Skvortsov

Post a reply to this message

In article <41d7e026$1@news.povray.org>, Sil### [at] gmxde says...
> 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.
> 
Ah, but the parser can be used the SDL to generate multiple objects, each 
needing to be parsed as well. You can, for objects like trees, where 
there already exists a program to make SDL for them, use such an external 
application. But what if you wanted sea anemones? The tree program isn't 
designed for that, but you 'could' code maybe 50 lines of code in the SDL 
and have it generate the needed objects as it parses. There are examples 
of things like this, where very complex objects with thousands of parts 
are 'parsed' into existence, using simple math or rules to define them. 
On such complex structures it is also **extremely** impractical, if not 
impossible to "simplify your scene a bit" and get the same result. This 
is bound to take a lot of time to do.

There is even, if I remember right, at least one (I think more) example 
that comes with POV-Ray which has this problem. The parse time is quite 
easily significantly longer than the actual render time in them. And 
there is no way to 'simplify' it. Nor is it practical to just buy a 
faster computer. The parser needs to be efficient 'period'.

Besides, as someone else points out, you have given no real argument for 
why it would be easier to implement a custom XML parser that included the 
'missing' features, than to simply extend the existing parser and the 
programs functionality to support them. That is the point of my last 
post, you are more interested in 'how it looks' than 'how it works', 
which is *always* a far more important issue.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message