Subject:
|
Re: open source ldd?
|
Newsgroups:
|
lugnet.cad.ldd
|
Date:
|
Mon, 21 May 2007 00:18:33 GMT
|
Viewed:
|
30925 times
|
| |
|
|
In lugnet.cad.ldd, Travis Cobbs wrote:
> I glanced at the db.lif file (which I believe contains all the geometry data > for
> the parts for LDD), and came to the conclusion that I don't really want to
> attempt to reverse engineer it.
I spent a couple evenings looking over this when it was first released. For a
proprietary format, it's nicely straightforward (the widespread use of XML
lately helps, of course).
> It's binary, and 9+ MB big.
Interestingly, 2.0 contained more information in than 2.1 did. For instance,
2.0 had bitmaps that were never used. 2.1 cleaned this up.
Also, it's really mixed binary and text. Since it's basically a way to "wrap
up" a directory structure's worth of files into one large piece, it's got a
mixture of elements, among them binary and XML sections.
> It appears that
> the .lif format is one created by Lego as a generic container for other files
> (similar to tar).
I'd actually compare it more directly to EA's IFF (Interchange File Format)
format, first created (mostly) for the Amiga personal computer. It has chunks
and chunk headers that are very similiar to IFF. (LIF = LEGO Interchange Format,
would be my guess at the meaning, as well).
> I wasn't able to find any documentation on the net about its
> actual format,
Me neither, though I pretty much deciphered nearly everything needed to
understand the format.
The greatest blocker was (what appears to be) a CRC value stored with each
object. We (a friend and I) threw everything we could think of at it to try to
match it. That would keep one from reverse-engineering a way to write out new
.LIF files.
> although looking at the files makes it appear that I could decode
> that level enough to get back the original files that are archived inside (it's
> not compressed).
I've managed to determine everything needed to write out ("decode") a db.lif
file into its constituent files, right down to the file dates. That didn't turn
out to be all that useful, and owing to the other issues involved (which you
discuss below), I let it drop.
> But since the actual geometry data is binary, reverse engineering that could
> prove a lot more difficult, and I'm not really into that kind of thing.
With other projects on my plate, I decided not to pursue this either. The thing
is, previous .lxf data was based on the Qube API. It really didn't need to be
reverse engineered, since tools and APIs existed to work with the data. This
latest LDD _seems_ to be based on newer Qube versions, for which a "free"
environment has not been released.
> One final thing. Unless US law exempts me from that clause, the fact that I've
> installed LDD 2.1 (and agreed to the license agreement) means that I agreed not
> to reverse engineer it. While you could argue that reverse engineering lxf
> files is still ok (since they are created by the software, and not actually part
> of the software), the geometry data file is definitely part of the software.
> And unlike the lxf files, which are easy to understand, db.lif is definitely not
> designed to be understood by a human.
This grey area is why I backed off, as well. I would argue that, since the .lif
files are binary mixed with ANSI (XML), then parts of it are fairly readable
without "deciphering", but I would rather have TLG actively release the means
(tools, docs) to access this data, than to commandeer it for little practical
gain.
I would hope that the interfaces become more open via TLG, but I guess we'll
just have to wait and see whether the tide turns again on the issue.
-- joshua
LUGNET #3
|
|
Message is in Reply To:
 | | Re: open source ldd?
|
| (...) Thanks for the tip. I'll take a look. I'll have to do some testing with zziplib to see if it will work with the ldraw.org zip files. It doesn't support all zip compression schemes, but I suspect it will work. If I need XML parsing, I'll take a (...) (18 years ago, 19-May-07, to lugnet.cad.ldd)
|
12 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
