[Gtkradiant] Re: xml?

[Timothee Besset]

#1 - I don't like to use shortcut names for the node names. The size of .xmap files is not really a concern. They will be gzipped very well if needed. <ent> should be <entity>, <prim> <primitive> etc. We are not going to have to type those .xmap by hand anyway.

#2 - <surf> as used here should actually be a <plane>

#3 - <q3map> is actually two things: "this is map data" and "it's Q3 style"
the style should be an attribute, the best attribute would be the game name I think

#4 - we use XML to get rid of parsing issues. things like "message"="bleh" or ( x y z ) ( x y z ) ( x y z ) would force us to do some parsing ourselves. The only thing we can afford is a bunch of floats seperated by spaces.

#5 - classname is an annoying issue. It is required for any entity to have a classname, but it should not be kept seperated from other key / values information, it would make it too annoying to manipulate. We'll prolly assert that an entity which doesn't have classname epair is worldspawn.

#6 - epairs. For the reasons mentionned above, no "message"="bleh" kind of stuff. we also need variable number of epairs. But we indeed have a name and value, so <epair name="message" value="bleh" type="string">. type would be an optional keyword to help decide what's there in an epair.

#7 - <primitive type="brush"> or <brush> ?
using type attribute would be interesting if the content of the node was the same. But in the case of brushes and patches we are not going to put the same stuff. A list of planes for brushes, a matrix for patches. It's easier to use <brush> then.

#8 - texturing properties. we have some information that's common to any geometry, the shader name and the flags in the case of Q3. Then we have information specific to brush plane or patch matrix. In the case of brush planes, we can use either brush primitives format or the regular texture format. Since it's just a bunch of numbers we can use a type attribute. <plane_texdef type="old">0 0 0.5 0.5 0</plane_texdef> or <plane_texdef type="BP">bp00 bp01 bp02 bp10 bp11 bp12</plane_texdef>. Then we have a generic <texdef> node, <texdef shader="textures/radiant/notex" flag="0"></texdef>
For patches texturing, we mix the UV coordinates directly in the geometric matrix.

#9 - patches use a generic matrix object, we store row and col size as attributes. Each cell is a vec5_t <matrix row="i" col="j"><vector size="5">x y z s t</vector><vector size="5"> ... </vector> ... </matrix>

grabbing the initial .xml and processing it according to the above rules:

<map type="quake3">
  <!--Entity 0-->
  <entity>
    <epair name="classname" value="worldspawn"></epair>
    <epair name="message" value="bleh"></epair>
    <!--Brush 0-->
    <brush>
      <plane>
	x y z x y z x y z
	<plane_texdef type="old">0 0 0.5 0.5 0</plane_texdef>
        <texdef shader="textures/radiant/notex" flag="0"></texdef>
      </plane>
    </brush>
    <!--Brush 1-->
    <patch>
      <matrix row="3" col="3">
        <vector size="5">x y z s t</vector>
        <vector size="5">x y z s t</vector>
        <vector size="5">x y z s t</vector>
        <vector size="5">x y z s t</vector>
        <vector size="5">x y z s t</vector>
        <vector size="5">x y z s t</vector>
        <vector size="5">x y z s t</vector>
        <vector size="5">x y z s t</vector>
        <vector size="5">x y z s t</vector>
      </matrix>
      <texdef shader="textures/radiant/notex" flag="0"></texdef>
    </patch>
  </entity>
  <!--Entity 1-->
  <entity>
    <epair name="classname" value="info_player_deathmatch"></epair>
    <epair name="origin" value="x y z" type="vector"></epair>
    <epair name="angle" value="90" type="float"></epair>
  </entity>
</map>

TTimo

On Sun, 23 Sep 2001 16:58:42 +0100
spog@planetquake.com wrote:

> another iteration of a possible xmap format.. along with a doctype 
> definition.
> 
> -SPoG
>