Sign in to follow this  
valoh

doom3 file format specs?

Recommended Posts

valoh    122
Hi, as with the release doom3 are there already any specs or example sources for the different file formats used in doom3? I don't mean the standard graphics or sound file formats but nonstandard id file formats. I'm especially interested in the level file format (quake .bsp equivalent of doom3). Exist there something about that already?

Share this post


Link to post
Share on other sites
Etnu    880
It was about 6 months after Q3 was released before people knew how to load the levels. I'd expect the same here.

Share this post


Link to post
Share on other sites
Mezz    571
But Q3 levels were binary, Doom3 ones seem to be text ;)

Around the time of the shady leaked alpha, some of the clever folks on the opengl.org forums had parsed the file formats and loaded the data into their own renderers. The files structure might have changed since then, but I still think it'll all be text (I seem to remember Carmack going on about banishing binary file formats apart from stuff like images & sound).

-Mezz

Share this post


Link to post
Share on other sites
valoh    122
text files?

perhaps because it was a leaked alpha!? I mean what advantage would a text format have over a binary format that would justify the slower loading/saving?

Has anybody definite infos on this? Text or binary? If text: XML or proprietary format?

Share this post


Link to post
Share on other sites
frostburn    380
Quote:
Original post by valoh
text files?

perhaps because it was a leaked alpha!? I mean what advantage would a text format have over a binary format that would justify the slower loading/saving?

Has anybody definite infos on this? Text or binary? If text: XML or proprietary format?


Nope.. I checked. The game packages are called pak###.pk4 and are zip files with a different extension.
pak000.pk4 -> maps, gui, videos, fx etc
pak001.pk4 -> dds (dds textures)
pak002.pk4 -> models
pak003.pk4 -> sound
pak004.pk4 -> textures

In the maps folder in the zip file (pak000.pk4/maps/game) there are 3-5 files fore each map (example: admin.cm, *.map, *.proc, *.aas48, *.aas96). All of these files are text files.
*.cm is the collision model, *.map contains texture/surface info (no position data) and *.proc contains models. (This may be incorrect - I just looked quickly through some of the files).

Most models are of the md5 format and is also text based. There are some .LWO (binary Lightwave objects) files though, but I'm not sure if they're used or low poly mockups. I looked at some of them and they looked extremely low poly and not at all like they do in the game.

I don't think it will take 6 months before someone figures out these file formats :)

EDIT: some more info and changed some stuff for readability.

[Edited by - frostburn on August 3, 2004 4:11:12 PM]

Share this post


Link to post
Share on other sites
Mastaba    761
Quote:
Original post by Etnu
It was about 6 months after Q3 was released before people knew how to load the levels. I'd expect the same here.


Actually, I was able to load the levels within 2 weeks after the first release of Q3Test. Though I wasn't loading them, I was saving them, i.e. converting Quake 2 levels to Q3Test levels. [razz]

Share this post


Link to post
Share on other sites
Megahertz    286
I think a few years ago Carmack stated he was going with a text based map format for Doom3 rather than a binary one, so if thats what was done, then it is not surprising.

Notepad anyone? =P

-=[ Megahertz ]=-

Share this post


Link to post
Share on other sites
Sunray    188
Doom 3 models are in .md5mesh format, which is plain text. In Doom 3 Alpha MD5Version was 6, in the release it's 10, which is slightly different.

Share this post


Link to post
Share on other sites
Nemesis2k2    1045
I don't understand why you'd go with a plain text format for things like 3D models in a final version of a game. They'll be a billion times the size, and be a billion times slower to load. If you really want people to be able to mod your games easily, why not release the file format specs with the game?

Share this post


Link to post
Share on other sites
thedevdan    210
Quote:
Original post by _the_phantom_
also, wouldnt txt loading get around the whole byte swapping issue? (big/little endian)


That's the real reason that text loading is so much better. It's almost certainly why he is doing it, too.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
What?

Of course binary is WAYS smaller than text format. Simple example: -3.141592 is 9 bytes long and nowhere near the 4 bytes precision of a float32.

And for having done both a good number of times size and speed difference are not considerable, they are HUGE. A 1mo binary mesh easily go up to 50+mo in text format and it will almost never compress back to 1mo (you try that). So you're loosing access time + CPU time for compression where swaping endian is like free.

That's a very strange choice indeed. It looks like we're going to see multi-dvd games and 500mo shareware pop everywhere very soon...

Share this post


Link to post
Share on other sites
mckoo    122
In pak000.zip\script
i found most of the scripts were written in cpp
it could be useful for developing mods

--------------------------------------------
I think most of the scripts were complied in real time.....so on some low-end machines, they will meet stack overflow problem

Share this post


Link to post
Share on other sites
Kentamanos    122
The size difference probably isn't as bad as you think considering the files are stored in a compressed format. Text compresses a LOT more than binary data (granted, binary would almost certainly still be smaller when compressed).

Share this post


Link to post
Share on other sites
Mastaba    761
Quote:

Of course binary is WAYS smaller than text format. Simple example: -3.141592 is 9 bytes long and nowhere near the 4 bytes precision of a float32.


Except, when the text is compressed. In which case that very same float could be much less than 4 bytes. Though in general would typically be no bigger than 6 bytes.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
If you haven't taken the time to think about it, all of the files in Doom3 are compressed.

Ascii or not, they became binary when they were compressed-- Completely getting rid of the slow processing of text files, and the size of a zipped text file is A LOT smaller than a zipped binary.

No doubt!?

- Blue Fire

Share this post


Link to post
Share on other sites
benryves    1999
Nah, Doom3 isn't compressed on my system- to get a decent frame rate I had to decompress all the .pk4's and defrag my hard disk. Now I get 20-30 FPS instead of 10.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mezz
Necroing is bad enough, but necroing with hideously incorrect information is even worse.

-Mezz

Yeah. Blue Fire, you are incorrect. A text file can be compressed more than most binary files, but it won't actually be smaller than the binary file when both are compressed -- it will still be bigger. And while loading compressed text files saves how much you have to load from disk, you still need to uncompress it and then parse the text data. Binary files are not parsed. Text files are always slower than binary, and there's little point using them if you don't expect people to edit the files by hand, but it's possible Carmack went with text so people can more easily figure out how the file format works.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this