 | | | | | |
Hello,
what programming language is used for ldd? Is it allowed, possible or even
welcome that users can develop addons?
Thanks for your replies....
| | | | | | | | | | | | | | | |
In lugnet.cad.ldd, Harry Schmitt wrote:
> Hello,
>
> what programming language is used for ldd? Is it allowed, possible or even
> welcome that users can develop addons?
>
> Thanks for your replies....
I've not heard anything suggesting that addons are possible and I have my doubts
that LEGO will be inclined to open its source (or if they even legally can since
I believe it uses thrid-party libraries).
Tim
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.ldd, Harry Schmitt wrote:
> Hello,
>
> what programming language is used for ldd? Is it allowed, possible or even
> welcome that users can develop addons?
I don't know either, but based on what happened before and after the original
release of LDD 1.0, I'm going to have to say that I'd find it to be unlikely.
Prior to LDD 1.0 being released, someone from Lego contacted a number of LDraw
tool authors (myself included due to LDView). All of us who agreed to it signed
an NDA with respect to information they would provide us about LDD with the goal
of compatibility between LDD and LDraw tools. If I remember correctly, the NDA
had an expiration date.
It never went anywhere, though, and we never actually received any "inside"
information about LDD or its file format. LDD eventually had its own internal
support for LDraw files, so the outcome isn't necessarily bad. While the ldraw
import/export functionality in LDD currently has some serious issues, there is
really no guarantee that any of the tools would have been updated to support the
LDD file format, even had we been given the information. However, the fact that
we weren't ever given any information implies to me that they changed their
minds about 3rd-party support.
--Travis
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.ldd, Travis Cobbs wrote:
> In lugnet.cad.ldd, Harry Schmitt wrote:
> > Hello,
> >
> > what programming language is used for ldd? Is it allowed, possible or even
> > welcome that users can develop addons?
--SNIP--
>
> It never went anywhere, though, and we never actually received any "inside"
> information about LDD or its file format. LDD eventually had its own internal
> support for LDraw files, so the outcome isn't necessarily bad. While the ldraw
> import/export functionality in LDD currently has some serious issues, there is
> really no guarantee that any of the tools would have been updated to support the
> LDD file format, even had we been given the information. However, the fact that
> we weren't ever given any information implies to me that they changed their
> minds about 3rd-party support.
>
> --Travis
Take any LDD 2.0 file and change it's extension from .lxf to .zip. Unzip it
with your favorite unzipper tool. Open IMAGE100.LXFML in your favorite text
editor. It's XML. Go to town.
-PD
PS: Love to see a tool to control the building instruction steps. The XML tags
are all there to support it. Someone just has to do it.
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.ldd, Paul S. D'Urbano wrote:
> In lugnet.cad.ldd, Travis Cobbs wrote:
> > In lugnet.cad.ldd, Harry Schmitt wrote:
> > > Hello,
> > >
> > > what programming language is used for ldd? Is it allowed, possible or even
> > > welcome that users can develop addons?
>
> --SNIP--
> >
> > It never went anywhere, though, and we never actually received any "inside"
> > information about LDD or its file format. LDD eventually had its own internal
> > support for LDraw files, so the outcome isn't necessarily bad. While the ldraw
> > import/export functionality in LDD currently has some serious issues, there is
> > really no guarantee that any of the tools would have been updated to support the
> > LDD file format, even had we been given the information. However, the fact that
> > we weren't ever given any information implies to me that they changed their
> > minds about 3rd-party support.
> >
> > --Travis
>
> Take any LDD 2.0 file and change it's extension from .lxf to .zip. Unzip it
> with your favorite unzipper tool. Open IMAGE100.LXFML in your favorite text
> editor. It's XML. Go to town.
>
> -PD
>
> PS: Love to see a tool to control the building instruction steps. The XML tags
> are all there to support it. Someone just has to do it.
Not to mention the fact that it has some form of submodelling feature that could
probably be hacked.
Tim
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.ldd, Paul S. D'Urbano wrote:
> In lugnet.cad.ldd, Travis Cobbs wrote:
> > LDD file format, even had we been given the information. However, the fact that
> > we weren't ever given any information implies to me that they changed their
> > minds about 3rd-party support.
> >
> > --Travis
>
> Take any LDD 2.0 file and change it's extension from .lxf to .zip. Unzip it
> with your favorite unzipper tool. Open IMAGE100.LXFML in your favorite text
> editor. It's XML. Go to town.
Thanks for the info, but I was actually aware of that. I was just trying to
point out that the actions of LEGO as a company imply to me that they aren't
interested in 3rd party support with LDD.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.ldd, Travis Cobbs wrote:
> In lugnet.cad.ldd, Paul S. D'Urbano wrote:
> > In lugnet.cad.ldd, Travis Cobbs wrote:
> > > LDD file format, even had we been given the information. However, the fact that
> > > we weren't ever given any information implies to me that they changed their
> > > minds about 3rd-party support.
> > >
> > > --Travis
> >
> > Take any LDD 2.0 file and change it's extension from .lxf to .zip. Unzip it
> > with your favorite unzipper tool. Open IMAGE100.LXFML in your favorite text
> > editor. It's XML. Go to town.
>
> Thanks for the info, but I was actually aware of that. I was just trying to
> point out that the actions of LEGO as a company imply to me that they aren't
> interested in 3rd party support with LDD.
>
> --Travis
Sure, I understand and not surprised you already knew this. I just thought
maybe Harry (or others reading the post) may not be aware of it.
But, since you replied... Any chance of LDView reading and rendering from LXFML
in the future? I'm thinking this would be very handy for folks who want to
write quick and dirty apps to manipulate the XML but don't have the skills to do
the rendering. They can concentrate on playing with the XML and use LDView to
view the results of their manipulations.
Just a thought.
Thanks!
-Paul
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.ldd, Paul S. D'Urbano wrote:
> But, since you replied... Any chance of LDView reading and rendering from LXFML
> in the future? I'm thinking this would be very handy for folks who want to
> write quick and dirty apps to manipulate the XML but don't have the skills to do
> the rendering. They can concentrate on playing with the XML and use LDView to
> view the results of their manipulations.
I'd say it's unlikely. It would be a fairly big undertaking, and since the
files can already be viewed in LDD, I'm not sure how much real benefit there
would be. Additionally, do you know of any open source cross-platform libraries
for in-memory zip handling and for XML parsing? I'd really want both in order
to add LXF file support to LDView. If you do know of any, I'd really like to
know about them, even if I don't add LXF support. My current zip handling for
library updates isn't something I'm happy with (it calls out to the unzip
executable when run outside Windows).
--Travis
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.ldd, Travis Cobbs wrote:
> do you know of any open source cross-platform libraries
> for in-memory zip handling and for XML parsing?
How about zziplib (or just zopen) and tinyxml?
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.ldd, Don Heyse wrote:
> In lugnet.cad.ldd, Travis Cobbs wrote:
> > do you know of any open source cross-platform libraries
> > for in-memory zip handling and for XML parsing?
>
> How about zziplib (or just zopen) and tinyxml?
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 look at tinyxml.
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. It's binary, and 9+ MB big. It appears that
the .lif format is one created by Lego as a generic container for other files
(similar to tar). I wasn't able to find any documentation on the net about its
actual format, 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).
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. There's
actually an lxf viewer on sourceforge (written in Java, and not updated in over
a year, so supporting an earlier lxf format). However, it doesn't even try to
use LEGO's geometry data. The project itself includes a small library of parts
in its own format written in XML. The good thing is of course that the LDD
geometry data file isn't needed for the viewer to work. The bad thing is that
there's a serious shortage of parts. LDView would of course be better off just
using the ldraw.xml file to do the conversion, but LDD 2.0 and 2.1 come with an
ldraw.xml file that's pretty much empty, and I'm not going to be the one to fill
it in.
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.
So it seems that the only way LDView would get native LXF support would be if
ldraw.xml were brought up to a useful status. But since that should in theory
allow for proper exporting of LXF files from LDD, it doesn't seem to be all that
useful of a feature to add to LDView.
--Travis
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | | |
In lugnet.cad.ldd, Harry Schmitt wrote:
| |
Hello,
what programming language is used for ldd? Is it allowed, possible or even
welcome that users can develop addons?
Thanks for your replies....
|
When their site comes back online (currently experiancing Database errors when I
try to acess the page for the toolkit and information), it would be Qube
Software’s Qube developer kit. Basiclly a complete all in one Open GL graphics
engine that can be modified to ones heart’s content (provided you have the
complete version). Though the free version allows viewing of the library files
used by it. Also one can create their own library files. Its best to investigate
the developer kit for your self, then to have me try to explain it, or a Library
file.
http://www.qubesoft.com/
| | | | | | |
