3DS Max file format (part 1:the outer file format; OLE2)

The 3DS Max file format, not too much documentation to is found about it. There is some hints here and there about how it's built up, but there exists no central documentation on it.

Right now we is in the following situation. A few thousand of max files, created by a very old version of Max (3.x), containing path references to textures and other Max files that has been renamed and relocated or which simply no longer exist. Yes, we have a maxscript this can go through them all, and the manages to fix a large number of paths. However, there is a lot of paths that is stored as part as fields in plugins and material scripts that don ' t get noticed , and the performance of opening and closing this number in the files from 3DS Max directly are horrible. The obvious solution? Figure out how we can read and save the max file with modified contents, without have to understand all of the actual da Ta it contains. Fortunately, this was actually possible without too much work.

Some Online brings up the following blog post, relating to a change in the max file format in version, which Would make it easier to update asset paths:http://www.the-area.com/blogs/chris/reading_and_modifying_asset_file_paths _in_the_3ds_max_file. That's nice and all, but it's only from version in, and it very likely won ' t contain any assets referenced by path by Old plugins and such.

So, starting at the beginning. The blog post I referred to above nicely hints us to the OLE structured file format. Since there exist a wide range of implementations for that, we can pretty much skip this, and accept that it ' s basically a FileSystem in a file, so it ' s a file containing multiple file streams. A Reliable open Source implementation of this container format can is found in LIBGSF. When scanning a fairly recent Max file, using the command @ @gsf [email protected]@, we can find the following streams Inside this file:

123456789

f        -videopostqueue f     147230 Scene f         366 FileAssetMetaData2 f       2198 dlldirectory f      29605 Config f       3438 ClassDirectory3 f         691 classdata f       29576 summaryinformation f       2320 Documentsummaryinformation

The FILEASSETMETADATA2 is new in 3DS Max 2010.

One step further, we can start examining the contents of these streams. And it ' s usually easiest to start off with one of the more simple ones. Videopostqueue seems small enough to figure out the overall logic of the file format, hoping that the rest is serialized I n a similar. Using the command @ @gsf [email protected]@ we can get a hex output of one of the streams, and using a simple text editor W E can find how it ' s structured. Binary formats often contain-bit length values, which is usually easy-to-spot in small files, since they ' ll contain a Large number of values. It ' s basically a matter of finding possible 32bit length integers, and matching them together with various fixed length fi ELDs and other typical binary file contents, until something programatically logical turns up. Here's a manually parsed Videopostqueue storage stream:

12345678910111213141516171819202122232425

[    50 00 (id: 0x0050)    0a 00 00 00 (size: 10 - 6 = 4)    [        01 00 00 00 (value: 1)    ]][    60 00 (id: 0x0060)    2a 00 00 80 (size: 42 - 6 = 36) (note: negative bit = container)    [        10 00 (id: 0x0010)        1e 00 00 00 (size: 30 - 6 = 24)        [            07 00 00 00 (value: 7)            01 00 00 00 (value: 1)            00 00 00 00            00 00 00 00            20 12 00 00 (value: 4610)            00 00 00 00        ]        20 00 (id: 0x0020)        06 00 00 00 (size: 6 - 6 = 0)    ]]

The storage streams in the Max container file contain a fairly simple chunk based file format (and in fact similar in F Ormat to the fairly well known. 3ds file format). Being based on chunks was what allows 3DS Max to open a file for which certain plugins was missing. It's basically a tree structured format where every entry have an identifier and a size, so if an identifier is unknown, Or when it's contents is incompatible, it can simply being kept as is or discarded. The only exceptions in the file that does don ' t use this structure is summaryinformation and documentsummaryinformation, which was supposedly in a standard Windows format, and the new FILEASSETMETADATA2 section was formatted differently as well Unfo rtunately.

In this format, the chunk header consists of a 2-byte unsigned integer which is the identifier, and a 4-byte unsigned I Nteger, where the least significant bits is the size and the MSB was a flag that helpfully lets us know if the chunk it Self contains more chunks, and thus are a container, or not. For very large files, where the bits are insufficient for the size, the entire size field was set to 0, and the header Increa SES with a additional 64-bit unsigned integer field which is similarly structured as the 32-bit size field. The size field includes the size of the header.

123	0 | 0f 20 (id)          00 00 00 00 (size missing)                      17 fe 01 00 00 00 00 80 (size in 64 bits)

With this information it's possible to read a max file, modify the binary contents of chunks (most of them is fairly bas IC of format), and we should is able to re-save the max file with our modified data. The Dlldirectory section, for example, and parsed programatically starts like this:

12345678910111213141516171819

CStorageContainer - items: 20    [0x21C0] CStorageValue - bytes: 4    786432216    [0x2038] CStorageContainer - items: 2        [0x2039] CStorageUCString - length: 39        Viewport Manager for DirectX (Autodesk)        [0x2037] CStorageUCString - length: 19        ViewportManager.gup    [0x2038] CStorageContainer - items: 2        [0x2039] CStorageUCString - length: 49        mental ray: Material Custom Attributes (Autodesk)        [0x2037] CStorageUCString - length: 21        mrMaterialAttribs.gup    [0x2038] CStorageContainer - items: 2        [0x2039] CStorageUCString - length: 37        Custom Attribute Container (Autodesk)        [0x2037] CStorageUCString - length: 23        CustAttribContainer.dlo...

Of course, it would is interesting if we could go further, and directly manipulate the parameters of our own plugins and S Cripts from our own tools, back to the max files so, everything is centrally stored without any duplicate source data In the. And that's exactly what I'll be doing next.

6 thoughts on ' 3DS Max file format (part 1:the outer file format; OLE2) "

1. pingback: 3ds Max File Format (part 2:the First inner structures; Dlldirectory, ClassDirectory3) | Kaetemi
2. pingback: 3ds Max File Format (part 3:the Department of Redundancy Department; Config) | Kaetemi
3. pingback: 3ds Max File Format (part 4:the first Useful data; Scene, AppData, animatable) | Kaetemi
4. pingback: 3ds Max File Format (part 5:how it all link s together; Referencemaker, INode) | Kaetemi
5. pingback: 3ds Max File Format (part 6:we get signal) | Kaetemi
6. pingback: reverse Engineering the Max file format | Neil Marshall ' s Tech Art Blog

"Turn" http://www.kaetemi.be/wp/2012/08/17/3ds-max-file-format-part-1-outer-file-format-ole2/

3DS Max file format (part 1:the outer file format; OLE2)