Jump to content

Export 3D Model / 3D Model Format


onedaxter

Recommended Posts

Hy guys,

With QuickBMS or also with DragunUnpacker I was able to export the content from the .pak files.

There are all the cool stuff like textures , sound files and also the 3D models.

 

The models have the file extension .drs and their animations are the .ska files.

 

The problem is that I haven't found an exporter for this file format.

My Question : 

Is there some one whos able to export or convert the meshes from this files in something like .fbx ?

I tried to analyse the file format with a hex-editor and find out where the "header" starts and ends.

But yeah, I'm not very good in this topic and I stoped it ;D

 

Link to comment
Share on other sites

Well after hours of research I've still come to a dead end with no real experience in decoding the header for what file type it is supposed to be. Some discovery involves: http://forum.xentax.com/viewtopic.php?f=16&t=9124 where someone is nice enough to explain the header of .drs files that Battleforge uses, and has a decoder for it, but sadly the site the decoder is hosted is no longer available and is not saved on TheWaybackMachine. 

I'll continue researching this, hopefully someone better at this can take this knowledge and use it better.

Link to comment
Share on other sites

I don't know how credible this website is but it looks like it has potential. 

(http://www.solvusoft.com/en/file-extensions/file-extension-drs/)

Excerpt:

"DRS File Analysis Tool™

Unsure about which type of DRS file you have? Do you want to know exactly what it is, who created it, and how to open it?
Finally, you can now discover everything you need to know about your DRS file... instantly!
The revolutionary DRS File Analysis Tool™ scans, analyzes, and reports back every detail about your DRS file. Our patent-pending algorithm quickly analyzes your file, and within moments, presents this information to you in an elegant, easy-to-read format.†
In seconds, you will learn exactly what type of DRS file you have, the software program associated with your file, the publisher who created it, its security safety status, and a variety of other useful information.
To begin your free file analysis, simply drag-and-drop your DRS file inside the dotted lines below, or click "Browse My Computer" and select your file. Your DRS file analysis report will then be displayed directly below in this browser window."

Edited by Majestic
Link to comment
Share on other sites

Thank you Titan for researching this site.

With the information from this forum I figured out following points:

4 bytes 1EF17CC5 -> All files start with this , so they are 4047 DRS files.

4 bytes 01000000 -> Should be an integer 1 as mentioned from the external forum

4 bytes XXXXXXXX -> This is an offset to a list which then contains more informations

4 bytes XXXXXXXX -> This is an offset to a second list which then contains more informations

and after some space 

4 bytes 1EF1544E -> all files end with this at the header , so it must be something  like an ending delimiter.

 

My problem is :

How is at the begining 1EF17CC5 converted to -4047.07 ?

I tried it with the IEEE 754 format but it's not the same.

 

And second :

The offsets for the lists are bigger than the maximum file's offset.

 

Maybe someone can help with these problems.

For testing I used the smallest file I have found.

They are called something like unit_demon_insect.....drs

I will also put the .drs for the swamp drake here so you also have an other example (because the other files are to big to upload)

 

 

hexdump.png

unit_demon_insect_wing_inner_l.drs

unit_bandit_swamp_drake.drs

Link to comment
Share on other sites

Some things that might help:

-Phenomic likes zlib compression: Headers are 78 01 or 78 9C or 78 DA. Maybe search for them in the file.

-Phenomic took many things from their previous game spellforce.  Maybe they used drs files there too and someone wrote a tool for spellforce.

Link to comment
Share on other sites

I've looked into those as well and the only program I can find is the one I linked, and while these are indeed the same DRS files used in Spellforce, the host is no longer available, so there is no program at the moment unless someone that used it and saved it could appear in this community (extremely unlikely); zlib compression is also not present as I searched for the headers and while 78 01 is there, it is not a header.

Also an issue: These are taken from the file greenland_monument_module1_s0.drs and has the following header problems. Then again, these are for non-animated buildings of which Pesmontis had no documentation for anyway.

58nnFCz.png

 

1EF17CC5 is -4047.06982 in a little endian float; 1EF17CC5 is 2.5578471e-20 in a big endian (normal) float. So I suppose the key to looking at this is using little endian, which now that I think of it is quite normal and explains 'srrd' and that the offsets are most likely little endian. 

EDIT: These files are also not compatible with any of the AoK/Age of Empires DRS file openers in case anyone is wondering.

Edited by Titan
Link to comment
Share on other sites

Thank you Titan !

 

I tried your suggestion with the unit_demon_insect_inner_l.drs file.

For little endian conversion I used this site : 

http://www.scadacore.com/field-applications/programming-calculators/online-hex-converter

and i switched the offset from hex to dec in HexDump

So i figured out :

EntryList1_Offset : 1602

EntryList2_Offset : 1794

Total "Elements" : 6

 

The ClassList (EntryList2) contains then following 6 Elements :

-root Node

-CGeoMesh

-CGeoOBBTree

-CDspJointMap

-CDspMeshFile

-DrwResourceMeta

 

The EntryList1 contains , according to Pesmontis , the offsets for the classes.

This is the following list :

0000 00000000 00000000 00000000 0000FFFF FFFF0100 00000500 00000000 0000F8BA FC050100 0000A605 00009C00 00000000 00000000 00000000 00000000 00008C43 BA8E0400 00001C00 0000DE04 00000000 00000000 00000000 00000000 00003685 17B00300 00001400 00000800 00000000 00000000 00000000 00000000 0000EB9E 5BC80200 00002605 00008000 00000000 00000000 00000000 00000000 00000522 17F50500 0000FA04 00002C00 00000000 00000000 00000000 00000000 0000

This are total 384 hex-digits.

Because we have 6 Elements  it could be possible that one element needs 384/6 -> 64 hex-digits.

 

I should check it maybe with a bigger file , but have now no time ;D

 

What do you think Titan ?

Probably , I can check it after 2-3 hours.

Maybe you have til then discoverd something more ;D

 

 

 

 

unit_demon_insect_wing_inner_l.drs

hexdump2.PNG

Link to comment
Share on other sites

Thank you for all the info Onedaxter.

Honestly I haven't looked at it long, but I am already a bit lost as to where I can find the files; But by guessing I'd say:

root node = 0x00000020 - 0x00000023

CGeoMesh = 0x00000024 - 0x00000667 ;Unsure of this number though

 

 

Edited by Titan
fixed my numbers
Link to comment
Share on other sites

I think the root node always starts with 

00FFFF FFFF0100 00

 

P.S I found a model called unit_reaver.drs

And there I also found an image for this unit.

I have never seen this unit before.

Maybe some new units which should have come into the amii edition ?

Looks a bit familiar with amii phantom like they have the same armor.

reaver.PNG

Link to comment
Share on other sites

Well if my math is correct, the root node is only 4 bytes, and the CGeoMesh is 1,588 bytes, and both numbers sound right, but I'm still unsure and my head isn't right today lol.

Indeed would be a cool unit to add along with the multiple other unused units (like my avatar), maybe after we can figure out how to export them anyway.

Edited by Titan
Link to comment
Share on other sites

Indeed would be a cool unit to add along with the multiple other unused units (like my avatar), maybe after we can figure out how to export them anyway.

Your profile picture seems to be a Stone Warrior. Check http://allcards.bfreborn.com/ and compare the two pictures: Same jaw, same arms with two "sharp" points, spikes in the back etc...

Link to comment
Share on other sites

Yeah, but it's a pure ice variant which is why I mentioned it.

Same goes for this: 

https://www.youtube.com/watch?v=reYcvhJWzPU Look at 44 seconds, there you can see the card... Apparently they were supposed to be a rangedsquad fire card, 55 power cost, 100 ranged damage and 55 health. This is very old though... and their names were "Forsaken" . The crossbows from Forsaken and these units look the same so I am guessing that they switched this card to shadow.

Link to comment
Share on other sites

Today I started in school again , so I don't realy have time to further go on this , maybe on the weekends.

 

I think next step could be to write a little progamm , which fechtes and displays our current known informations.

And maybe a simple check , which chracter patterns are in 2 and more files the same. Maybe there are other delimiter in the hexdump.

 

@Titan Have you discovered something new ? ;D

Link to comment
Share on other sites

Good News !

 

I had contact with pesmontis himself.

He gave me his program lightsong and some extra documentation.

I testet the program with an model but it gave me a "no DE FA" error.

 

According to pesmontis , this is a material problem ...

 

He don't want to give me the source code , but maybe someone can reverse engineere the code ;D (it's a VB6 program)

or 

Make a new program with his documentation

 

He gave me also some spellforce 2 .drs files , so we can check their file structure with our battlefroge .drs files.

 

If someone needs more information from pesmontis , I can write to him.

Here's the link

https://mega.nz/#F!kltllJAB!2RMk13XRxV1DRm3KJrbfXQ

 

 

Link to comment
Share on other sites

Looking them over, the SF2 .drs files are alot simpler to read, but they're mostly the same as Battleforge .drs. Why it can read the DE FA out of SF2 and not Battleforge, I don't know because it does have DE FA in the right location; And I'm not a Visual Basic person, so I don't really know what I can do with it.

On the good side, the documentation is really nice on it, though a bit difficult to understand initially. I'll keep working on it and see what I can come up with.

Thanks for all the info!

Edited by Titan
Link to comment
Share on other sites

pesmontis told me that the problem with no DE FA comes with the different Matierials.

He said , that most of the Spellforce 2 .drs Files had different ways to import the materials , so he had to "hardcode" the most things.

And with the Battleforge 2 .drs Files he said :

The files are bigger then the Spellforce 2 Files -> so this could be a problem for parsing through the files.

Edited by onedaxter
Link to comment
Share on other sites

atm. I've added some extra code to LightSong to parse a few DRS files from BattleForge. As Titan says, the 'DEFA' chunks are in the right position, that is at the end of each submesh inside a CDspMeshFile chunk. Hex 0x(DE FA) is actually a marker for the start of some kind of texture sets (or materials). I find these materials difficult to parse, and for SpellForce2 I had to apply many exceptions in the code. So my materials-parsing is really a mess, and any help would be greatly appreciated.

Here's the first DEFA chunk of the model unit_shadow_demon.

To be able to parse such a section is important, because the next submesh inside a CDspMeshFile chunk starts directly after a DEFA chunk.

So far, paring the DEFA chunk is the only way to get to the start of the next submesh.

DEFA_chunk.jpg

Link to comment
Share on other sites

I have no idea about the drs files. but i noticed that the actual header is not DEFA but D0DEFA

parts of this seem not to be correct anymore. NUMtexes seems to be always 8. and after int unknown comes another int.

struct TEXTYPENAME
{
    char ID[4];
    int lenName;
    char* name;
    float*
unknown;       // array size unknown (!): cause of sync. errors.
                                    //  usually just one float, but irregularities here
                                    //   have given cause to hardcoded exceptions
                                    //    (eg. building_beast_altar_main.drs);
};

struct TEXSET
{
    int NUMtexes;                        // value = 1 or 2;
    TEXTYPENAME* texture;     // only seen sets of 1 or 2 texture names;
};

struct DEFATEX
{
    byte drsDEFA[2];    // eg.
0x(DE FA);
    int
unknown;           // value = 0;
    TEXSET* txSet;      //
array size unknown before reading;
};

Link to comment
Share on other sites

It's not actually the DEFA marker that's troubling me. And in the example I gave, there are four texture sets with NUMtexes = 8, 1, 12, and 4 respectively.

One thing that I assumed is that each of the four texture sets has the same structure, but as you can see, the fourth texture set has longer TEXTYPENAME structures with little endian floats behind them. I'm guessing that each TEXTYPENAME can actually hold either a texture file name or a color (three floats for RGB). But then my code must be able to recognize this.

Here's another example with three floats in the second texture set (from the model unit_lostsouls_demon):

DEFA_chunk2.jpg

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Terms of Use