Page 1 of 3
Doom Eternal *.resources unpacker
Posted: Sat Mar 21, 2020 6:24 am
by iOrange
Made a simple command-line unpacker for
Doom Eternal *.resources game archives.
Usage:
Code: Select all
DoomEX.exe path_to_resources_file output_folder
Tool:
DoomEX.zip
Github:
https://github.com/iOrange/DoomEX
Re: Doom Eternal *.resources unpacker
Posted: Sat Mar 21, 2020 2:50 pm
by Ize
Awesome! Will you add support for
eternal to your
doom resources explorer?
What's the best way to convert the meshes to a "usable" format right now? I'd love to 3d print the main menu podest and the
doom slayer on it
Re: Doom Eternal *.resources unpacker
Posted: Sat Mar 21, 2020 2:59 pm
by infogram
Nice work! A friend also got QuickBMS working with it too:
https://zenhax.com/viewtopic.php?p=54753#p54753
(also posted some info about working with the games string files there, if anyone wants to work on translations)
Any idea how hard it'd be to make a repacker for this?
I know DOOMExtract could repack 2016's files but this new IDCL format seems a lot different, maybe more needs to be figured out first before that can be done...
E: BTW it looks like your tool doesn't handle any decompression? I saw that QuickBMS had support for Oodle decompressing, maybe worth looking into adding that too? (unless the game doesn't even use it, that is...)
Re: Doom Eternal *.resources unpacker
Posted: Sat Mar 21, 2020 3:12 pm
by GRiNDERKILLER
Nice work but it doesn't decompress files. Or Am I wrong?
Re: Doom Eternal *.resources unpacker
Posted: Sat Mar 21, 2020 9:14 pm
by OrangeC
Hmm any idea for the .pck .snd files.
Re: Doom Eternal *.resources unpacker
Posted: Sun Mar 22, 2020 12:23 am
by iOrange
infogram wrote: ↑Sat Mar 21, 2020 2:59 pm
E: BTW it looks like your tool doesn't handle any decompression? I saw that QuickBMS had support for Oodle decompressing, maybe worth looking into adding that too? (unless the game doesn't even use it, that is...)
Unfortunately the game is using Oodle for compression, and Oodle SDK is non-free, so I'm not quite sure how to handle this property.
My next step is to make a converter for textures and models
Re: Doom Eternal *.resources unpacker
Posted: Sun Mar 22, 2020 2:13 am
by iOrange
Ok, so I added decompression. Just copy "oo2core_8_win64.dll" from
Doom Eternal folder to DoomEX folder and run as usual.
Download:
DoomEX_v02.zip
Source code:
https://github.com/iOrange/DoomEX
Re: Doom Eternal *.resources unpacker
Posted: Sun Mar 22, 2020 9:40 am
by Ize
Decompression seems to work but i couldn't get any of the lightwave models to load in open 3d model viewer and the textures are in BIM format, whatever that is
Re: Doom Eternal *.resources unpacker
Posted: Sun Mar 22, 2020 11:14 am
by infogram
iOrange wrote: ↑Sun Mar 22, 2020 2:13 am
Ok, so I added decompression. Just copy "oo2core_8_win64.dll" from
Doom Eternal folder to DoomEX folder and run as usual.
Download: DoomEX_v02.zip
Source code:
https://github.com/iOrange/DoomEX
Cool, thanks!
This new IDCL format looks crazy, got no idea how a repacker could be made for this, so many unknowns >.>
Maybe someone will figure out a way to let it load loose files instead of needing to pack, would save a lot of time.
Ize wrote: ↑Sun Mar 22, 2020 9:40 am
Decompression seems to work but i couldn't get any of the lightwave models to load in open 3d model viewer and the textures are in BIM format, whatever that is
I think
DOOM 2016 used bimage files for some textures (not all since a lot were mega-texture crap), I guess maybe BIM is the same thing, pretty sure I saw some work on bimage files being posted before.
Re: Doom Eternal *.resources unpacker
Posted: Sun Mar 22, 2020 12:32 pm
by GRiNDERKILLER
BIM seems to be almost same as MIB struct but in LittleEndian. But i saw that there is only header but no raw data at least at fonts. Looks like they are most probably in *.streamdb. But no clue where are offsets for them.
EDiT:Also seems like resources are somehow protected against editing. I tried edit plain text from false; to true;
and left same size of text and game refuse to start. On second run steam re-download whole resources.
EDiT1: Uff streamdb luckily are not protected. I cut half of last streamdb archive and game loads fine. And it was obvious on first look. Missing textures. So there will be fonts textures.
EDiT2: OK I finally find location of font textures if anyone interested. In: gameresources_0_1.streamdb. Now I must find right raw data. I think some clues should be in BIM headers.
Re: Doom Eternal *.resources unpacker
Posted: Sun Mar 22, 2020 12:36 pm
by CharlieV
Maybe it's just over my head but when I used it all that was extracted were <20kb files referencing the real files in the gameresources .streamdb archives. The tool for
Doom 2016 was a great help to me a few weeks ago, but it seems the Wolfenstein games have been a lot of trouble and this will be closer to those, I'm in no rush I'll just be glad to see something comprehensive made for this eventually too no matter how long it may take
Re: Doom Eternal *.resources unpacker
Posted: Sun Mar 22, 2020 9:03 pm
by ArtyDoesStuff
Wow, the unpacker works like a charm! Thanks for that.
How's the research on texture/model conversion coming, also? I've looked through the unpacked files, and they're all in such strange formats. BITEXTURE, .entities, etc. It looks like It's going to be quite hard getting them ready to extract, though I don't think it's that much different than 2016 except that Mega Textures aren't a thing anymore. But that's just my thoughts, I could be wrong, but it's something to look into.
Re: Doom Eternal *.resources unpacker
Posted: Mon Mar 23, 2020 3:05 am
by infogram
GRiNDERKILLER wrote: ↑Sun Mar 22, 2020 12:32 pm
EDiT:Also seems like resources are somehow protected against editing. I tried edit plain text from false; to true;
and left same size of text and game refuse to start. On second run steam re-download whole resources.
Hmm, I did see some mention of hashes in the code that handles the IDCLs, maybe one of the unknown tables contains hashes/signatures.
I did see some table which had way more entries than the number of files, this could maybe be hashes of blocks inside the files, (no idea what the block-size or anything might be tho), but pretty sure I saw some string mentioning data-blocks anyway.
I saw WolfstoneExtract also has IDCL format pretty detailed too, not sure if it includes much more info than we already know about, but it does handle both version 11 and version 12 IDCLs though:
https://bitbucket.org/ecwolf/wolfstonee ... e_idcl.cpp
(Also kinda off-topic but I decided to try figuring out what all those Oodle unknowns are, but then I found this project which is a pretty detailed disassembly:
https://github.com/powzix/ooz
The kraken.cpp also has prototypes for the Oodle DLL exports (OodleLZ_Decompress / OodleLZ_Compress), which are a lot more complete than any other description I could find on the net:
Code: Select all
typedef int WINAPI OodLZ_CompressFunc(
int codec, uint8 *src_buf, size_t src_len, uint8 *dst_buf, int level,
void *opts, size_t offs, size_t unused, void *scratch, size_t scratch_size);
typedef int WINAPI OodLZ_DecompressFunc(
uint8 *src_buf, int src_len, uint8 *dst, size_t dst_size, int fuzz,
int crc, int verbose, uint8 *dst_base, size_t e, void *cb, void *cb_ctx,
void *scratch, size_t scratch_size, int threadPhase);
Hopefully this'll show up on google if anyone tries looking for them, took me a bit of digging to find, big thanks to powzix of course)
Re: Doom Eternal *.resources unpacker
Posted: Mon Mar 23, 2020 5:37 pm
by GRiNDERKILLER
I did some research on BIM so here is what i got so far. Alot of unk flags and skiped some bytes. But it should parse all BIM header.
- local int i;
int64 id;
int mipmapflag;
int mainwidth;
int mainheigth;
int null;
int mipmapcount;
int64 null;
byte flag;
int flag;
int compchar;
int flag;
FSkip(6);
short flag;
short flag;
short flag;
short flag;
for(i=0;i<mipmapcount;i++) {
struct {
int64 mipnum;
int width;
int heigth;
int flag;
int mipmaplayersize;
int flag;
int64 id; //or something
} mipmap;
};
Re: Doom Eternal *.resources unpacker
Posted: Mon Mar 23, 2020 7:16 pm
by exhaleme