[Gtkradiant] Re: xml?

[Joseph, William]

You're right, I've written the xml<->.map parser/writer and it still needs a
unique function to parse/write a patch <surface> or a plane <surface> in
.map format.
You're right that using a generic primitive format requires that the
structure below the <node type="bleh"> needs to be the same all the time -
that's what i've done.

surface is not a useless node, because there can be n surfaces in a
primitive. Likewise there can be n primitives in an entity and n epairs.

The way i've done it, the map module (xml tree -> .map file) becomes...

if(type=="brush") write a brush to .map
else if (type=="patch") write a patch to .map

and .map file -> xml tree is:

if(token=="patchDef2") parse a brush from .map
else parse a brush from .map

the map module passes the complete xml tree to radiant, or recieves one to
write to a file.

of course, the xmltree -> xmlfile plugin is even simpler, it's just
"xmlDocDump(file, xmltreedoc);"
and the reverse is "xmltreedoc = xmlParseFile(filename);"

Radiant traverses the xml tree, and passes each <primitive> node to the
plugin supporting that primitive type, which returns a brush/patch/whatever.
Radiant doesn't need to know what kind of primitive it is (this would be
exactly the same as using <patch> and <brush>). An alternative way to do it
would be to use a generic primitive node in radiant and send each <surface>
to the relevant plugin. This might cause some headaches with brush plane
<surface> nodes that need to have access to the other <surface> nodes in the
primitive in order to create windings or to do ray intersections, but I'd
like to experiment to see if this can be resolved in an elegant way. I'd
like to get rid of the brush_t entirely and go with a face_t class of
objects that have knowledge of the other face_t objects in their parent
generic-primitive object.

If we don't change anything in radiant, it doesn't really matter what the
xml parser code does, because radiant won't be extendable. I'm suggesting
(slightly) changing the way primitives are stored in radiant, to make them
more generic, which requires a generic way to store primitives in files.

-SPoG


-----Original Message-----
From: Timothee Besset [mailto:timo@qeradiant.com]
Sent: 26 September 2001 08:59
To: gtkradiant@zerowing.idsoftware.com
Subject: Re: [Gtkradiant] Re: xml?


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