| View previous topic :: View next topic |
| Author |
Message |
jwatte
DeleD PRO user
Joined: 26 Apr 2006
Posts: 513
|
 Posted: Wed Apr 25, 2007 2:18 am Post subject: Suggestions on the XML interface |
 |
|
Let's pick apart the following XML:
| Code: |
<primitive id="4" name="cube6" type="cube" visible="true" snap="none" autoUV="true">
<tag>-</tag>
<vertices>
<vertex id="0" x="-1024" y="-256" z="768" />
<vertex id="1" x="-1024" y="-256" z="-1792" />
<vertex id="2" x="1024" y="-256" z="-1792" />
<vertex id="3" x="1024" y="-256" z="768" />
<vertex id="4" x="-1024" y="-288" z="768" />
<vertex id="5" x="-1024" y="-288" z="-1792" />
<vertex id="6" x="1024" y="-288" z="-1792" />
<vertex id="7" x="1024" y="-288" z="768" />
</vertices>
<polygons>
<poly mid="1">
<vertex vid="0" u0="-4" v0="-2" />
<vertex vid="1" u0="-4" v0="8" />
<vertex vid="2" u0="4" v0="8" />
<vertex vid="3" u0="4" v0="-2" />
</poly>
<poly mid="1">
<vertex vid="5" u0="-4" v0="8" />
<vertex vid="4" u0="-4" v0="-2" />
<vertex vid="7" u0="4" v0="-2" />
<vertex vid="6" u0="4" v0="8" />
</poly> |
The <vertices> tag ought to have the highest ID, or the count of vertices, to allow pre-allocating storage space.
The <polygons> tag also ought to have the number of polygons, again to allow pre-allocating space.
It would also be useful if it had the maximum number of texture coordinates used within any of the polys inside.
The <poly> element ought to have the number of vertices as an attribute, as well.
I think that'll do for now. I'll return later :-) |
|
| Back to top |
|
 |
Daaark
DeleD PRO user
Joined: 01 Sep 2004
Posts: 2696
Location: Ottawa, Canada
|
| Posted: Wed Apr 25, 2007 5:58 am Post subject: |
|
|
I would just stick it in the primitive tag as an attribute, along with a few other things, like center position, size, etc..
_________________
 |
|
| Back to top |
|
|
jwatte
DeleD PRO user
Joined: 26 Apr 2006
Posts: 513
|
| Posted: Wed Apr 25, 2007 6:39 am Post subject: |
|
|
Actually, I think bounding box (from which you can get both size and center :-) would make for an excellent XML element that's a child of primitive. It doesn't quite make it as an attribute, IMO.
Of course, I wanted them to store arrays as just CDATA numbers (similar to Collada), but instead we got this attribute heavy schema. Although I paid my purchase fee a long time ago, so any updates I'm getting are free, so how could I complain :-) |
|
| Back to top |
|
|
jwatte
DeleD PRO user
Joined: 26 Apr 2006
Posts: 513
|
| Posted: Wed Apr 25, 2007 9:24 pm Post subject: |
|
|
To clarify what I meant by CDATA for arrays, something like this would be nice:
| Code: |
<vertices count="3">
<array type="float" stride="3">
1.5 -1.0 2.7
2.2 1.0 1.0
0.0 3.14 69
</array>
</vertices>
|
This would be significantly faster to parse (and easier, as you'd just pre-allocate 3*3 floats in this case, and scan the array in to that allocated array).
But, given that 1.6 is already out with XML, I think it might be hard to change the schema wildly at this point. |
|
| Back to top |
|
|
Paul-Jan
Site Admin
Joined: 08 Aug 2004
Posts: 3066
Location: Lage Zwaluwe
|
| Posted: Thu Apr 26, 2007 7:28 am Post subject: |
|
|
Suggestions are always welcome!
Personally, I am not much in favour of using CData. Having unstructured (or perhaps more accurately: customly structured) text inside XML always seems to kinda defy the whole purpose of using XML in the first place.
How is parsing ("scanning") space-separated data any easier than using data that is readily parsed into floats by the standard XML reader?
Two reasons for using CData I can identify with are:
1. The data inside the CData structure is always used "as is" in the XML consuming applications (don't think that applies here).
2. Performance (also emcompassing things like pre-allocation info).
If/when/once (2) becomes a serious problem (the exact moment is of course up for debate, but the plugin system is the most likely candidate to become problematic) , I think I'd rather skip XML completely and move on to some chunk-based binary format. Instant massive speedup. |
|
| Back to top |
|
|
jwatte
DeleD PRO user
Joined: 26 Apr 2006
Posts: 513
|
| Posted: Thu Apr 26, 2007 11:25 pm Post subject: |
|
|
| Quote: |
| How is parsing ("scanning") space-separated data any easier than using data that is readily parsed into floats by the standard XML reader? |
Faster, for obvious reasons.
Easier (or at least, more straightforward), because you would just allocate an array of floats, and convert numbers from the CDATA text:
| Code: |
float *array = new array[stride*count];
stringstream str(cdata, size);
float *ptr = array, end = ptr + stride*count;
while (ptr != end) {
str >> *ptr;
++ptr;
} |
This is significantly simpler than looking through all attributes for X, Y and Z values (and potentially the ID too, if you don't want to assume they're sequential starting at 0). In my opinion, of course. CDATA is a fine way of storing "bulk" data where the structure has to be known by the user implicitly anyway.
And I don't use the built-in XML parser, because it's pretty darn slow. XMLSCAN is the fastest XML scanner and DOM builder I know of (and I include a copy in the nuxporter 1.6 code on Google, btw). |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
