XGL, potential replacement for DTS?

#1 I've been asking myself that a little lately. Not XGL, specifically, but using XML in general. It would be great for some of the stuff I want to work on (very organized), and easy to edit. But on the other side of the argument, it would be slow (the opposite of DTS, which was intended to be fast loading) and possibly awkward to program. Text-based is good, but when you start getting into organized markup (stop me if I'm wrong), the advantages of easy programmability start to go down. Hmm, and what about Unix vs. Windows vs. Mac text files? That could be a royal pain.

Hmm, sorry. I didn't intend to rain on your parade. This stuff's haunting me a little.

#2 I don't think it would be particularly good for a game format, having done a bit of work with XGL. Very bulky. But as in intermediate format for transferring between apps.. hmm, maybe.

#3 I don't think that any sort of XML based file has to be slow loading. XGL is supposed to mimic OpenGL functionality, which should mean that you can do a minmal amount of conversion. I also haven't looked at the current system, but does it load the models dynamically right now? There is no real reason we couldn't move to a system where the models are loaded/converted/whatever at level load time.

It doesn't look like a lot of programs support XGL output though. I don't know if that is a huge problem, as we could always write plugins for Milkshape/3DSMAX/Lightwave/Maya/Whatever.

The nice thing about an XML based format is that it is easy to add things like vertex shader programs without disrupting current tools.

Josh

#4

Quote:
I've been asking myself that a little lately. Not XGL, specifically, but using XML in general. It would be great for some of the stuff I want to work on (very organized), and easy to edit. But on the other side of the argument, it would be slow (the opposite of DTS, which was intended to be fast loading) and possibly awkward to program. Text-based is good, but when you start getting into organized markup (stop me if I'm wrong), the advantages of easy programmability start to go down. Hmm, and what about Unix vs. Windows vs. Mac text files? That could be a royal pain.

Hmm, sorry. I didn't intend to rain on your parade. This stuff's haunting me a little.

STOP!!!

Ok, I am stopping you :)

I do lots of XML work all of it is seemless and requires less coding than binary formats, because there are lots of api's for automatically binding XML documents to objects and tonnes of ways to do transforms / translations painlessly. Serializing objects to XML and other neat stuff, that is already coded and in libraries.

Also there is no issues with portablity among platforms as all that crap ( line endings and what not ) is ignored by the xml parsers. XML is NOT just TEXT files, there are specific rules they must adhere to, byte encoding and what not, so there are no platform issues.

#5 I stand corrected. =)

How much of a speed hit would you say parsing an XML file adds over the typical binary format?

#6 There is certainly a speed hit, though with the speed of modern computers, it is not all that signifigant.

If we run into huge speed issues, we could always convert to DTS before you ship your final version, though that would require keeping DTS up to date with whatever enhancements we add to the XML format.

Josh

#7 what about libxml? I know someone using it with CL [ClanLib] and it is pretty dang fast.

Also, libxml provides multiplatform support.


Just my $0.0000002

-Ron

#8 speed hit? Unless you are talking about files that in their binary format are 500MB or bigger there is no perceiveable difference in speed.

And if there is who cares?

I guarantee you that network traffic and sync on level changes and people connecting are 100x slower than parsing a SMALL XML file that represents a model and animation.

Because with modern computers ( anything with a DMA33 or faster drive ) network I/O is the limiting factor now days.

Who cares if it takes 108ms to load a local binary file like a .dts and 180ms to load an xml version? Then again, the XML version will compress down to nothing because all the high bytes will get removed when compressed, so network transmission becomes less of an issue either.

The BENEFITS of a self-documenting structured file format far out weight ANY of the issues associated with using them if they are used correctly.

#9 Sheesh, Jarrod, chill out. It was a simple--and I believe perfectly valid--question.

#10 what? I did not call him any names, or anything, what is YOUR problem, I explained in a concise way why size and speed are not an issue with XML data that is small ( < 500MB )??????

He asked about for anyone to "stop" him, what we can't educate on the forums any more, just rant about how crappy the game reviewing community is or the like?

You guys need to learn how NOT to click that submit button.

#11 To be fair, the XML files aren't going to be all that small. Think about it, 6 floats and 2 integers for each vertex times 2000 vertices adds up pretty quick. Then you need faces and animation and whatnot. I would imagine that the files would be fairly large, and parsing them might take some time.

Anyway, I was under the impression that GG wanted to move to a text based XML format anyway, so I was really trying to see how people felt about XGL in particular.

Josh

#12

Quote: He asked about for anyone to "stop" him, what we can't educate on the forums any more, just rant about how crappy the game reviewing community is or the like?

That was me that asked for corrections, and me that asked for a simple speed comparison. You don't sound like you're educating anyone here, though. To me, the emphasis and excessive punctuation make it seem like you're ready to bite peoples' heads off with a rant. Sorry if that wasn't your intention.

#13 Having used XML extensivly on the web myself it has proved to be a very useful and stable mechanism. However I would be very concerned about the size / speed of a XGL file for complex models.

As suggested earlier as a transport mechanism or an intermediate file it's excellent. But I think it would need translating into a runtime format.

Think how torque deals with the script files (compiles them at runtime if they've changed), by having this kind of mechnism we don't have to sacrifice anything really and distribution size and speed aren't compromised.

XGL seems ok, but it seems we'd end up with an aweful lot of EXT tags.

I'd always found on the web though that the communications needed to get the file were orders of magnitude higher than what it took to parse it, and since we could use a streaming system rather than actually parse the entire file memory shouldn't be impacted too much.

Sounds like a plan.

#14 I believe the plan all along was to develop a text interchange format which would could then be converted to dts through a small tool. We wouldn't have to rip the dts code out of the engine which would be very nasty but it would be quick and painless to write an exporter for any modelling package instead of the current headache. I haven't looked at XGL specifically but I think an XML-based format would be a good one.

#15 Can anyone who has been working with XGL please email me. I've been having some issues with textures.

Nevermind, I have them sorted. Btw, I'm using Realitywave's free XGL SDK