Hi,

I am trying to write a Blender exporter for my game engine's data. When I look at other exporters they often use hexadecimal to identify the different chunks and sub-chunks in the binary file. Why is hexadecimal used and what does it represent in the file?

There's nothing special with a hexadecimal value, but its representation is convenient because each digit in a hexadecimal number is exactly 4 bits. Thus, each pair of hexadecimal digits represents 8 bits, or exactly a whole byte. That is, the hexadecimal value 0x1234 represents the byte sequence {0x12, 0x34}, assuming big endian storage, but as a value it is no different from the decimal value 4660.

To add onto what Brother Bob says, since memory is laid out mostly as powers of two*, and 16 is a power of two, it makes it very convenient to describe memory-related values in hexadecimal.

1 byte = 2 digit hex exactly

2 bytes = 4 digit hex exactly

4 bytes = 8 digit hex exactly

Binary would work just as good... but it is too wordy. 11101010 11010101 10010011 11011101 verses just 0xEAD593DD. It's alot more compact to display.

Decimal is also alot more compact to display (3939865565), but it doesn't line up to the powers of two like binary and hexadecimal does.

Some people also use octal (base 8), though I don't see that all too often.

The final benefit of hexadecimal is that you can spell words in it: 0xDEADC0DE

*The basic units of memory (bytes) don't have to be laid out in powers of two, but it almost always is nowadays. Example: 32bit PCs and 64bit PCs. Sure, there's some wierd systems where bytes are 10 bits, but hey,

Thanks for the great replies. There still is something that I don't get. When hexadecimal is used to describe the chunks of a binary format does it represent the size of each chunk in the memory?

Binary files don't have "chunks". I'm more than a little confused by that. A binary file is a string of bytes that span the length of the file. The only time I've seen "chunks" was in a human readable format.

Typically a binary file will be formatted to have a header with offsets to the various data and that header will be immediately followed by the file data. What a binary (hexadecimal) string represents to the file loader is entirely defined by the file format.

Here is a binary file. It is a simple 5x5 pixel TGA file. The first 18 bytes are the file header and the image data starts at byte 19 (the 00 immediately following the 08).

00 00 02 00 00 00 00 00 00 00 00 00 05 00 05 00 20 08 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF

The "02" in the header tells the loader that this is an uncompressed, true-color image.
The first "05 00" defines a 16-bit word that tells the loader the width of the image; In this case, 5 pixels.
The second "05 00" defines a 16-bit word that tells the loader the height of the image.
The "20" that follows is 32 in hexadecimal, telling the loader that each pixel in the pixel data is 32-bits (4 bytes).
The "08" is an encoded byte, whose bits tell the loader if the image is flipped as well as the number of alpha channel bits.
The other bytes that I did not explain have special meaning as well, in certain cases, but are unused in this file.
The image data is stored as BGRA (blue, green, red, alpha) and in this case, each pixel has the values "00 00 00 FF".

If you are seeing anything other than hexadecimal in a file, it isn't a binary file.

The final benefit of hexadecimal is that you can spell words in it: 0xDEADC0DE

One of the versions of the BBC Micro OS had as the two bytes starting at location 0xD0D0 the value 0xD1ED.

So how would I know where the different pieces of the file were to reference in hexadecimal surely that would depend on the size of the data in the file.

Sounds like your problem has nothing to do with hexadecimal or any other number base, but with the format itself. What actual data to write is determined by the format you want to read or write. You said you're trying to write an exporter to your own game engine, so you should have a good idea what has to be written to the file. Can you explain mode detailed what your problem actually is?

Well, my problem is that I need to be able to load model data into my engine (vertices, uvs, lighting attributes, textures) but I also want skeletal animation and most of the formats I found that supported animation were either too bloated (Collada, FBX) and not really suitable for game use or text based (MD5) which I don't really want. So I resolved to make my own (binary) format and after looking at a few example python exporters (3DS, FBX) I found hex was often used and I needed to know exactly how the exporter worked to be able to produce one myself that wasn't just a copy.

I hope this is enough explanation.