Chris Dee Wrote:I like the idea of the new library being programmatically derived each time the current library is updated, if indeed that is feasible.
So it sounds to me like the existing library could be considered to be conventional "source code" and the new, enhanced version a kind of "compiled" version. Since objects in the new library would never be created manually there's no reason for it to be text format, so it could be binary, and thus possibly smaller (4-byte float numbers support 6 significant decimal digits), although if the complilation inlines all subpart and primitive references that may not be the case. In keeping with the LDraw ethic, I think it should be Open Source or Creative Commons. It also wouldn't need to be 8000+ separate files in one folder, which I'm aware has been mentioned as a scaleability concern.
However, it seems pointless (and ambitious) for us to try and define a new binary graphics file format, if there is already one out there that provides all we need. I don't know enough to evaluate that possibilty myself. I think connectibility might be a missing feature of existing formats, but we haven't really incorporated that into the LDraw file format either, apart from a notional acceptence that studs form a connection point.
If we go for an existing format, we should choose one that permits attaching custom data, so that we can put ldraw-related informations in it, such as connection points (as you said) or condlines, etc.
I think we don't have that complicated of a format, we don't have textures, UV, material related stuff, etc. So a custom format could still be a good (and simple enought) solution.
Actually i think the brevity of ldraw format is not as great as it is pictured. Sure, the recursive nature saves space, but the vertices are stored in a very inefficient way: they are repeated in each face instead of being listed beforehand and referenced in faces. This makes "complex" parts very verbose and possibly waste all the gain from primitives.