[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