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