Okay well, as often happens when I've got a ton of work to get done, I've 
come up with a ton of ideas that I probably won't have the opportunity to 
implement, completely unrelated to anything I have to do. Fun.

So, I know that there's been much talk about using XML for povray scene 
description language, and a lot of sunk in povray purists will have none 
of it! Well, I'm sure there's really good reasons for it, but hear me out 
anyway. I'd like to share, and I figured I need someone to either tell me 
I'm being retarded, or that it's a great idea, or whatever and maybe I'll 
be able to move on to some real work!

I've been reading quite a bit about XML, X3D (new vrml), XSLT, and DTD, 
all  are very neat technologies, most with a tiny drawback. They're 
terrible at handling binary format. Apparently X3D will have 3 versions. 
A classic curly bracket version of syntax, an XML compatible syntax, and 
a binary syntax, each with it's own advantages. This got me thinking 
about povray, of course.

My idea is that it may be possible to implement the same type of idea for 
povray.  

Suppose a standard XML syntax were established that implemented most or 
all of the features of povray SDL, with correct nesting and such and all 
that, with its own DTD and everything. 

Then, you could use XSLT language to create a converter, which would be 
able to translate between standard SDL, and this XML version, easily and 
quickly.

now this is the part that's really weird, and very likely dumb:


The DTD for the XML syntax could be used to create a binary version of 
the povray language. That is, each opening and closing tag could be 
assigned its own byte, or word, and be assembled into sort of a binary 
shorthand of the XML syntax. 

This by itself brings the advantage of smaller filesizes for huge 
datasets like meshes, and such, which at this point uses huge amounts of 
data, uneccesarily by storing vector and context information as ascii 
characters. 

This would also bring the advantages that XML brings, of easy 
portability, parsing, and flexibility of presentation, eliminating the 
difficulties involved in creating alternative rendering engines for quick 
preview of povray scenes. 

Suppose then that a patch in povray would allow the automatic translation 
between these 3 formats, and the direct parsing of the formats into 
internal tokens. 

This may bring a number of other advantages that I won't mention here.

Anyways, I'd be interested in hearing why this is a stupid idea.


-Zen

Post a reply to this message

In article <Xns94B1A5863FF0DZenZenPsychocom@203.29.75.35>, 
Zen### [at] ZenPsychocom says...
> Anyways, I'd be interested in hearing why this is a stupid idea.
> 

Not sure if it is stupid exactly. However, XML is not a language so much 
as a container. You can organize things with it, but nearly all 
implementations use a <SCRIPT> block of some sort to provide the 'real' 
code that makes all of the stuff work. That block contains all the stuff 
that actually provides functions, program control, etc. In other words, 
it is still a container, it just happens to contain the code that ties 
all the pieces together. If you make it so it does more, then it really 
isn't XML anymore.

The other issue is the discussion being done about object oriented 
design. XML can provide a 'known' structure, but it contains no 
implementation for changing that structure dynamically during use. So, 
you could do:

<union>
  <box ...>
  <box ...>
  <sphere ...>
</union>

but not programmatically use if/then or other mechanisms that provide 
flow control to selectively remove one of those objects. The XML only 
provides the structure and data, not a means to manipulate it. Again, if 
you change it to allow this, then it isn't XML anymore. The result would 
either end up being nothing more that a drastic redesign of the existing 
SDL that adds a lot of extra junk, but with the same function, or if you 
stuck to more strict XML standards, you would make it too inflexible to 
do even half of what the existing system allows.

XML is useful for what is was designed to do, but for some reason 
everyone thinks it is the answer to every problem now. It isn't, nor was 
it ever intended to.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Actually, I was thinking along the lines that either the XML version of
the language would either unroll the traditional SDL, so when deriving
XML from from a #while, statement for instance, it would merely run the
while loop to create the XML, so and so times. 

Either that, or the conditionals in povray seem like they may be simple
enough to just make them container elements. This wouldn't invalidate it
as XML. it would merely be a way of containing the information relevent
to the scene description. 

like for instance

<if value="true">
<box a="1", b="-1"><pigment><color r="1"/></pigment></box>
</if>

As far as I know, this is valid xml, and it would simply be a matter of
interpretation to convert this into the proper scene. 

However, I am not suggesting XML as a replacement of SDL, as you say,
the loops and conditionals and programmatic elements are not so easy to
implement in XML. however, XML could possibly be a solution to a very
specific problem POVRAY has..... interoperability with other 3d
programs. 

For instance, we no longer have polyray to fall back on for previewing
our scenes before doing a full raytraced render.  The closest thing is
the patched povray with limited openGL support. 

If it were possible to unroll povray's "compile time" programmatic
elements into an XML file with some level of automation, conversion to
other formats for preview would be that much easier. 

Patrick Elliott <sha### [at] hotmailcom> wrote in
news:MPG.1ac56ef08bcbb1779899ed@news.povray.org: 

> In article <Xns94B1A5863FF0DZenZenPsychocom@203.29.75.35>, 
> Zen### [at] ZenPsychocom says...
>> Anyways, I'd be interested in hearing why this is a stupid idea.
>> 
> 
> Not sure if it is stupid exactly. However, XML is not a language so
> much as a container. You can organize things with it, but nearly all 
> implementations use a <SCRIPT> block of some sort to provide the
> 'real' code that makes all of the stuff work. That block contains all
> the stuff that actually provides functions, program control, etc. In
> other words, it is still a container, it just happens to contain the
> code that ties all the pieces together. If you make it so it does
> more, then it really isn't XML anymore.
> 
> The other issue is the discussion being done about object oriented 
> design. XML can provide a 'known' structure, but it contains no 
> implementation for changing that structure dynamically during use. So,
> you could do:
> 
> <union>
>   <box ...>
>   <box ...>
>   <sphere ...>
> </union>
> 
> but not programmatically use if/then or other mechanisms that provide 
> flow control to selectively remove one of those objects. The XML only 
> provides the structure and data, not a means to manipulate it. Again,
> if you change it to allow this, then it isn't XML anymore. The result
> would either end up being nothing more that a drastic redesign of the
> existing SDL that adds a lot of extra junk, but with the same
> function, or if you stuck to more strict XML standards, you would make
> it too inflexible to do even half of what the existing system allows.
> 
> XML is useful for what is was designed to do, but for some reason 
> everyone thinks it is the answer to every problem now. It isn't, nor
> was it ever intended to.
>

Post a reply to this message

In article <Xns94B1A5863FF0DZenZenPsychocom@203.29.75.35> , Breton Slivka 
<Zen### [at] ZenPsychocom>  wrote:

> Suppose a standard XML syntax were established that implemented most or
> all of the features of povray SDL, with correct nesting and such and all
> that, with its own DTD and everything.
>
> Then, you could use XSLT language to create a converter, which would be
> able to translate between standard SDL, and this XML version, easily and

You cannot easily create a converter using XSLT for anything.  Ever seen a
XSLT that converts some simple piece of data contained in XML to PDF?  Just
forget it!  XML/XSLT are a late internet-bubble hype that create bloated,
slow and complex programs in absolutely every place they have ever been
used.  Consequently, every responsible designer and programmer should avoid
this combination like the plague!  They are no good for anything they have
ever been used for.  XHTML is the perfect example - HTML was for everyone to
learn and use.  XHTML needs a fancy editor for the plain user as only
programmers can grasp the strict validation rules it enforces.  Of course,
if you don't want humans to edit your data, it is a waste of resources to
use text as interchange format in the first place.  The frequently cited
easy conversion of XML is just more hype, as it has exactly zero to do with
the problem of data interchange.  It only adds yet another layer of
problems.

Consequently, even the suggestion to use XML is a total waste of time!

    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 <Xns94B1DBBA41E8ZenZenPsychocom@203.29.75.35> , Breton Slivka 
<Zen### [at] ZenPsychocom>  wrote:

> However, I am not suggesting XML as a replacement of SDL, as you say,
> the loops and conditionals and programmatic elements are not so easy to
> implement in XML. however, XML could possibly be a solution to a very
> specific problem POVRAY has..... interoperability with other 3d
> programs.

You are confusing chicken and egg here:  POV-Ray is older than almost all
commercial non-CAD 3D render programs you can buy today.  Hence, it is not
that POV-Ray does not interoperate with them, but that they do not
interoperate with POV-Ray! ;-)

    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

news:Xns94B1A5863FF0DZenZenPsychocom@203.29.75.35...
> So, I know that there's been much talk about using XML for povray scene
> description language, and a lot of sunk in povray purists will have none
> of it!

The problem is less purism than the fact that the benefits of XML for
POV-Ray hand-coded scene development aren't exactly obvious while I wouldn't
rank the other (very theoretical) benefits as a top priority.
In any case, YafRay is a new free raytracer that uses XML for scene coding
(usually in combination with Blender). You may want to have a look and see
how it works.
http://www.coala.uniovi.es/~jandro/noname/


G.

-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

On Fri, 19 Mar 2004 18:15:39 -0500, Breton Slivka wrote:

> Okay well, as often happens when I've got a ton of work to get done, I've 
> come up with a ton of ideas that I probably won't have the opportunity to 
> implement, completely unrelated to anything I have to do. Fun.
> 
> So, I know that there's been much talk about using XML for povray scene 
> description language, and a lot of sunk in povray purists will have none 
> of it!

Look at a file for yaf-ray sometime, it's XML based. You'll see why it's a
bad idea.

For the sake of convience, here is an example file for the yaf-ray docs:

<scene>

<shader type = "generic" name = "Default">
        <attributes>
                <color r="0.750000" g="0.750000" b="0.800000" />
                <specular r="0.000000" g="0.000000" b="0.000000" />
                <reflected r="0.000000" g="0.000000" b="0.000000" />
                <transmitted r="0.000000" g="0.000000" b="0.000000" />
        </attributes>
</shader>
<transform
m00 = "8.532125" m01 = "0.000000" m02 = "0.000000" m03 = "0.000000"
m10 = "0.000000" m11 = "8.532125" m12 = "0.000000" m13 = "0.000000"
m20 = "0.000000" m21 = "0.000000" m22 = "8.532125" m23 = "0.000000"
m30 = "0.000000" m31 = "0.000000" m32 = "0.000000" m33 = "1.000000"
>

<object name = "Plane" shader_name = "Default" >
        <attributes>
        </attributes>
                <mesh>
                <include file = ".\Meshes\Plane.xml" />
                </mesh>
</object>
</transform>

<light type="pathlight" name="path" power= "1.000000" depth "2" samples = "16" use_QMC
= "on" cache"on"  cache_size="0.008000"  angle_threshold="0.200000" 
shadow_threshold="0.200000" >
</light>

<camera name="Camera" resx="1024" resy="576" focal="1.015937" >
        <from x="0.323759" y="-7.701275" z="2.818493" />
        <to x="0.318982" y="-6.717273" z="2.640400" />
        <up x="0.323330" y="-7.523182" z="3.802506" />
</camera>

<filter type="dof" name="dof" focus = "7.97854234329" near_blur "10.000000" far_blur
"10.000000" scale "2.000000">
</filter>

<filter type"antinoise" name"Anti Noise" radius = "1.000000" max_delta = "0.100000">
</filter>

<background type = "HDRI" name = "envhdri" exposure_adjust = "1">
        <filename value = "Filename.HDR" />
</background>

<render camera_name = "Camera" AA_passes = "2" AA_minsamples = "2" AA_pixelwidth =
"1.500000" AA_threshold = "0.040000"
        raydepth = "5" bias = "0.300000" indirect_samples = "1" gamma = "1.000000"
exposure = "0.000000" background_name"envhdri" >
        <outfile value="butterfly2.tga"/>
        <save_alpha value="on"/>

</render>
</scene>

Post a reply to this message

In article <Xns94B1A5863FF0DZenZenPsychocom@203.29.75.35>,
 Breton Slivka <Zen### [at] ZenPsychocom> wrote:

> So, I know that there's been much talk about using XML for povray scene 
> description language, and a lot of sunk in povray purists will have none 
> of it!

It isn't purism, it's pragmatism...try to imagine what it would be like 
to code scenes in XML. Or to read scenes coded in XML. It's a terrible 
language for human editing, and not a very good one for machines.


> Suppose a standard XML syntax were established that implemented most or 
> all of the features of povray SDL, with correct nesting and such and all 
> that, with its own DTD and everything. 

Okay...now you have a much less readable, much longer form of the same 
scene. Now what?


> The DTD for the XML syntax could be used to create a binary version of 
> the povray language. That is, each opening and closing tag could be 
> assigned its own byte, or word, and be assembled into sort of a binary 
> shorthand of the XML syntax. 

You could just as well create a binary version of the script itself. Or 
better, create a binary scene format...a straight binary representation 
of a script would still be wasteful of space.


> This by itself brings the advantage of smaller filesizes for huge 
> datasets like meshes, and such, which at this point uses huge amounts of 
> data, uneccesarily by storing vector and context information as ascii 
> characters. 

I agree that a binary format would be useful for things like large 
models. XML is hardly a space-saver, though, and is not needed as an 
intermediate step between POV script and a binary file.


> This would also bring the advantages that XML brings, of easy 
> portability, parsing, and flexibility of presentation, eliminating the 
> difficulties involved in creating alternative rendering engines for quick 
> preview of povray scenes. 

But it doesn't do that. Another rendering engine will still need to know 
what data is there, and it can't do anything with data that isn't there. 
XML doesn't fix this. You end up with another subsystem in POV Ray that 
doesn't really do anything but take up developer time and confuse users.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <Xns94B1DBBA41E8ZenZenPsychocom@203.29.75.35>,
 Breton Slivka <Zen### [at] ZenPsychocom> wrote:

> <if value="true">
> <box a="1", b="-1"><pigment><color r="1"/></pigment></box>
> </if>

It'd be a bit more complex than that. Maybe something like:

<if>
    <condition>
        <equal>
            <lhs><varref identifier="foo"></lhs>
            <rhs><boolean value="true"></rhs>
        </equal>
or maybe:
        <compare type=equal lhs="foo" rhs="true">
    </condition>
    <then>
        <box x1="1" y1="1" z1="1" x2="-1" y2="-1" z2="-1">
            <plainpigment red="1"/>
        </box>
    </then>
</if>

This would be equivalent to:
#if(foo = true)
    box {< 1, 1, 1>, <-1,-1,-1>
        pigment {color red 1}
    }
#end

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <cjameshuff-EE45D7.14050220032004@news.povray.org>, 
cja### [at] earthlinknet says...
> In article <Xns94B1DBBA41E8ZenZenPsychocom@203.29.75.35>,
>  Breton Slivka <Zen### [at] ZenPsychocom> wrote:
> 
> > <if value="true">
> > <box a="1", b="-1"><pigment><color r="1"/></pigment></box>
> > </if>
> 
> It'd be a bit more complex than that. Maybe something like:
> 
> <if>
>     <condition>
>         <equal>
>             <lhs><varref identifier="foo"></lhs>
>             <rhs><boolean value="true"></rhs>
>         </equal>
> or maybe:
>         <compare type=equal lhs="foo" rhs="true">
>     </condition>
>     <then>
>         <box x1="1" y1="1" z1="1" x2="-1" y2="-1" z2="-1">
>             <plainpigment red="1"/>
>         </box>
>     </then>
> </if>
> 
> This would be equivalent to:
> #if(foo = true)
>     box {< 1, 1, 1>, <-1,-1,-1>
>         pigment {color red 1}
>     }
> #end
> 
> 
Yep. All you really accomplish is replacing a slightly more obscured 
syntax with one that is simpler to read, but takes up more space and more 
time to parse. It doesn't really improve matters to fiddle with XML.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message