My first 3D data format

News & General Discussion
1

It’s amazing how much fun something like this can be…
I made a simple format for 3D data. It’s very easy to understand, and it hardly takes up any space too. This is the data for four cubes, each with the same material used (only 795 bytes total):

vertices [
0 [-1.0,-1.0,1.0]
1 [-1.0,1.0,1.0]
2 [1.0,1.0,1.0]
3 [1.0,-1.0,1.0]
4 [-1.0,-1.0,-1.0]
5 [-1.0,1.0,-1.0]
6 [1.0,1.0,-1.0]
7 [1.0,-1.0,-1.0]
]
materials [
mat1 [
diffuse
color [1,1,1,1]
]
]
object [
material mat1
worldPosition [0,0,0]
face 0 [0,1,2,3]
face 1 [3,2,6,7]
face 2 [4,0,3,7]
face 3 [2,1,5,6]
face 4 [7,6,5,4]
face 5 [4,5,1,0]
]
object [
material mat1
worldPosition [1,0,0]
face 0 [0,1,2,3]
face 1 [3,2,6,7]
face 2 [4,0,3,7]
face 3 [2,1,5,6]
face 4 [7,6,5,4]
face 5 [4,5,1,0]
]
object [
material mat1
worldPosition [0,1,0]
face 0 [0,1,2,3]
face 1 [3,2,6,7]
face 2 [4,0,3,7]
face 3 [2,1,5,6]
face 4 [7,6,5,4]
face 5 [4,5,1,0]
]
object [
material mat1
worldPosition [0,0,1]
face 0 [0,1,2,3]
face 1 [3,2,6,7]
face 2 [4,0,3,7]
face 3 [2,1,5,6]
face 4 [7,6,5,4]
face 5 [4,5,1,0]
]

Does anyone think this is worth implementing at all?

2

It kinda of looks like the OBJ format.

I know a lot of people who write there own game engines write a binary format that all models they load (FBX, OBJ, 3DS, COLLADA, ect…) get transformed into.

I’d say it’d be worth implementing something like this if you plan on using it outside of Unity in your own engine, or as a learning purpose. I don’t see any purpose if you’ll only be using it with Unity, except for dynamically loading models.

3

Looking over the .obj format, yeah, I guess it is a little too much like it. It takes up about one-fifth of the space, though.
Anyway, it was an interesting learning experience, even if I never use it again. Cheers!

4

Definitely a good learning process. I remember going through a similar exercise on an SGI back in the day.

Just my two cents… if you are thinking of implementing something like this for a transfer format or production format then it is difficult not to choose an XML based approach (that you could easily wrap around your format), which adds compatibility with lots of tools and a human readable object model at a glance.

If you are looking for a run-time game resource it would be hard to beat a binary version of something like this for both storage space. If this is the case, the next exercise would be to analyze what you could do to the format for improving loading speed too.

Ricko

5

Parsing an hierarchical text format can be surprisingly subtle, so I would agree with Ricko here. By using XML, you retain most of the “fun” of designing your own format, but the parsing (and many other advantages) are already available for free.

A binary format typically requires a bit more thought at the design stage, but is a lot easier to code. It is also safer across a variety of use cases. Suppose you wanted to write an importer for your format in your 3D modeller’s scripting language (C4D’s COFFEE, etc). There’s no built-in XML parser and it would be a nightmare to write one. Parsing your own text format might be easier, but would still be a lot of effort. Binary data has less potential to surprise you in new situations.

A problem with binary formats, of course, is that there is no equivalent to a text editor to key the data in directly. It’s therefore difficult to test your importer properly and, without an importer, you can’t easily test an exporter. With this in mind, I strongly recommend you base a binary format on an existing “container” type format such as PNG (you needn’t implement PNG’s complicated image data, compression or checksums, just use the header and chunk structure). That way, you can test the major structure of your importer on existing PNG graphic files.

If you want to reflect a hierarchy of data in your file then a (nostalgic) possibility is IFF and a more modern one is EBML, used with the Matroska video format.

(PS - there is a crude PNG importer attached to this thread, if it’s any use to you.)