[Gtkradiant] Re: xml?
Timothee Besset
gtkradiant@zerowing.idsoftware.com
Wed, 26 Sep 2001 09:58:38 +0200
I understand the issue about having a file format that can be easily
extended, but the issue of <primitive type="brush"> or <brush> is still
off-topic there.
What happens when you want to parse a polymesh or a patch?
With your approach:
if (nodename == primitive)
if (type == brush)
being surface (node this node is useless, just adds a level)
parse the vector into planepoints
parse texdef
end surface
else if (type == polymesh)
being surface
parse the vector into the struct we use for polymesh (not compatible with planepts parse)
parse texdef
end suface
else if
<..> add a mechanism to recognize other types and dispatch the parsing to appropriate plugins
end
end
With my previous version:
if (nodename == brush)
parse the node data into planepoints
parse texdef
else if (nodename == polymesh)
parse the vector into the polymesh struct
parse texdef
else if
<..> add a mechanism to recognize other node names and dispatch the parsing to plugins
end
It still looks to me that my version does the same thing and has the same
extendability capabilities. As a side effect, it's also smaller. As I
explained in previous mails, the choice between telling what the node is
directly in it's name and telling what it is in a type attribute only
matters if the underlying layout of elements in the node is the same and
doesn't depend on the type. (read that twice!).
Explanation:
if we have
<node type="1">
<subnode1>
<..>
</subnode1>
<subnode2>
<..>
</subnode2>
</node>
Then if whatever the value of type there is always <subnode1> followed by
<subnode2>, it is possible to use the same parsing function for all types.
But if we have
<node type="2">
<subnode3>
<..>
</subnode3>
</node>
then depending on type we will need to use a different parsing function.
In this case it will be easier (as shown first in the mail) to use
different node names.
Let's stress that one more time: using the direct name of the primitive in
the node doesn't change the extendability capabilities. And using
primitive doesn't make the parser any easier.
TTimo
On Tue, 25 Sep 2001 22:50:23 +0100
"Joseph, William" <WJoseph@europe.ea.com> wrote:
> I'm experimenting with loading code for files using the format below - to
> see if the <primitive type="bleh"> <surf> arrangement is actually any better
> than using <brush> <plane> and <patch> <matrix>. One reason i like the
> abstract primitive/surf idea is demonstrated below with a "polymesh"
> primitive using the same format. My hope is that i can use a standard set of
> functions to convert the xml tree data into the format desired by each
> primitive, instead of some custom-made specific functions for each
> primitive. This should make things generally more extensible in theory..
>
>
> <?xml version="1.0"?>
>
> <!DOCTYPE map [
>
> <!--entity contains one or more epairs, and zero or more primitives-->
> <!ELEMENT map (entity+)>
> <!ATTLIST map type CDATA #REQUIRED>
>
> <!--entity contains one or more epairs, and zero or more primitives-->
> <!ELEMENT entity (epair+, prim*)>
>
> <!ELEMENT epair EMPTY>
> <!ATTLIST epair key CDATA #REQUIRED>
> <!ATTLIST epair value CDATA #REQUIRED>
>
> <!--primitive contains one or more surfaces-->
> <!ELEMENT primitive (surf+)>
> <!ATTLIST primitive type CDATA #REQUIRED>
>
> <!--surface contains vector and an optional texdef-->
> <!ELEMENT surface (vector, texdef?)>
>
> <!--vector contains geometric data in #PCDATA-->
> <!ELEMENT surface (#PCDATA)>
> <!ATTLIST surface numdim CDATA #REQUIRED>
> <!ATTLIST surface dimensions CDATA #REQUIRED>
>
> <!--texdef contains texdef data in #PCDATA-->
> <!ELEMENT texdef (#PCDATA?)>
> <!ATTLIST texdef shader CDATA #REQUIRED>
> <!ATTLIST texdef type CDATA "default">
> <!ATTLIST texdef flags CDATA "0">
>
> ]>
>
>
> <map type="quake3">
> <!--Entity 0-->
> <entity>
> <epair key="classname" value="worldspawn"/>
> <epair key="message" value="bleh"/>
> <!--Brush 0-->
> <primitive type="brush">
> <surface>
> <vector numdim="2" dimensions="3 3">x y z x y z x y z</vector>
> <texdef shader="textures/radiant/notex" type="quake3" flags="15">0 0
> 0.5 0.5 0</texdef>
> </surface>
> </primitive>
> <!--Brush 1-->
> <primitive type="patch">
> <surface>
> <vector numdim="3" dimensions="3 3 5">x y z s t x y z s t x y z s t
> x y z s t x y z s t x y z s t x y z s t x y z s t x y z s t</vector>
> <texdef shader="textures/radiant/notex"></texdef>
> </surface>
> </primitive>
> <!--Brush 1-->
> <primitive type="polymesh">
> <surface>
> <vector numdim="2" dimensions="3 8">x y z nx ny nz s t x y z nx ny
> nz s t x y z nx ny nz s t</vector>
> <texdef shader="textures/radiant/notex"></texdef>
> </surface>
> </primitive>
> </entity>
> <!--Entity 1-->
> <entity>
> <epair key="classname" value="info_player_deathmatch"/>
> <epair key="origin" value="x y z"/>
> <epair key="angle" value="90"/>
> </entity>
> <!--Entity 2-->
> <entity>
> <epair key="classname" value="item_armor_combat"/>
> <epair key="origin" value="x y z"/>
> </entity>
> </map>
>
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant@zerowing.idsoftware.com
> http://zerowing.idsoftware.com/mailman/listinfo/gtkradiant