 | | | | | | |
| |
|
I've been tinkering with the "ldraw.xml" file in LEGO Digital Designer (LDD),
and have come up with the following list of fixes for good LDD/LDRAW conversion.
In case you hadn't already discovered, if you append ".ldr" to the end of the
file name when saving from LDD, it will save it in LDRAW format. You can then
load and edit it in MLCAD. If you save a ".ldr" file in your "My Documents\LEGO
Creations\Models" directory, you can open it in LDD. If you tinker with the
parts order and building steps in MLCAD, these are preserved in the LDD native
file format. It's much easier to tweak the instructions with MLCAD than it is
with LDD.
Note: you only get a thumbnail index picture for ".ldr" files if they were
originally saved from LDD. If you load a ".ldr" file in LDD, it will be loaded
with its own parts palette. To upload the model to LEGO Factory, you have to
open the palette window, select the Factory palette, then de-select the model
palette. It will translate the bricks into the Factory palette as best it can;
it's up to you to spot if anything disappears or changes colour.
The big problem is that some parts and colours don't transfer properly at all.
1x1 round tiles are exported as the wrong part, and 1x1 slopes disappear
completely. 1x4 tiles export OK, but when imported back into LDD turn into the
printed train control tile, which can't simply be recoloured as it's an entirely
separate part from the plain version.
Finally, new light and dark grey don't come up as the right colours.
So, to fix all this, go to where you've installed LDD, then go into the
"database" directory. In there you'll find a file named "ldraw.xml". This
controls the part conversions from LDD to LDRAW files and back again. Bring it
up in a text editor.
1x4 Tiles
~~~~~~~~~
The first fix comes courtesy of Christopher Masi (see:
http://news.lugnet.com/trains/?n=27469&t=i&v=a).
First find the line that refers to "2431" and replace with the following:
<!-- 1x4 TILE, fixed by Christopher Masi 24.May.06 -->
<geometry tabulaname="2431">2431</geometry>
This will import and export 1x4 tiles correctly.
1x1 Tiles
~~~~~~~~~
Add the correct mapping at the end of the "geometry" section:
<!-- 1x1 TILE, fixed by Jason Railton 28.Jun.06-->
<geometry tabulaname="30039">3070b</geometry>
This will export 1x1 grooved tiles correctly.
1x1 Round Plates
~~~~~~~~~~~~~~~~
First comment out the remapping entry near the bottom:
<!-- 1x1 ROUND PLATE - REMOVED AND PLACED ABOVE, Jason Railton 28.Jun.06 -->
<!-- remapldraw tabulaname="6141">4073</remapldraw -->
Next add the correct mapping in at the end of the "geometry" section:
<!-- 1x1 ROUND PLATE, fixed by Jason Railton 28.Jun.06 -->
<geometry tabulaname="6141">4073</geometry>
1x1 Slope
~~~~~~~~~
First, go and download part 50746 from the LDRAW parts tracker, put it in your
PARTS directory and run MKLIST again:
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/50746.dat
Next, add the following to the end of the "origin" section:
<!-- 1x1 SLOPE, added by Jason Railton 28.Jun.06 -->
<origin x="0.000" y="0.000" z="0.000" axisx="0" axisy="1" axisz="0"
angle="3.141593">50746</origin>
Then, add the following to the end of the "geometry" section:
<!-- 1x1 SLOPE, added by Jason Railton 28.Jun.06 -->
<geometry tabulaname="50746">50746</geometry>
This will import and export 1x1 slopes correctly, and add them so you can use
them in MLCAD. Note that this may need adjusting once the 1x1 slope becomes an
official part.
Old and New Greys
~~~~~~~~~~~~~~~~~
This is a preference thing, but I like LDD's new light and dark grey to map onto
LDRAW's old light and dark grey, for convenience. If you want the same, here's
how to do it:
First, comment out the old grey translations:
<!-- OLD LIGHT GREY, removed by Jason Railton 28.Jun.06 -->
<!-- colour tabulaname="2">7</colour -->
<!-- OLD DARK GREY, removed by Jason Railton 28.Jun.06 -->
<!-- colour tabulaname="27">8</colour -->
Next, comment out the new grey translations:
<!-- NEW LIGHT GREY, removed by Jason Railton 28.Jun.06 -->
<!-- colour tabulaname="194">71</colour -->
<!-- NEW DARK GREY, removed by Jason Railton 28.Jun.06 -->
<!-- colour tabulaname="199">72</colour -->
Then, paste in these new-old translations at the end of the "colour" section
(note that it's the English spelling of 'colour'):
<!-- NEW TO OLD LIGHT GREY, remapped by Jason Railton 28.Jun.06 -->
<colour tabulaname="194">7</colour>
<!-- NEW TO OLD DARK GREY, remapped by Jason Railton 28.Jun.06 -->
<colour tabulaname="199">8</colour>
This may interfere with any LDD parts that are in the old colours, but so far
that only applies to train track.
The way the XML file works is as follows:
"<colour>" tags - these map a specified LDD colour onto an LDRAW colour, with
varying degress of accuracy.
"<origin>" tags - these describe the translation and rotation of LDD parts to
align the LDRAW equivalent in the same position. The most common fix is a 180°
rotation (Pi radians) about the Y-axis. Note that if a part doesn't appear in
this list, it won't be exported or imported at all.
"<geometry>" tags - these map a specified LDD part shape onto its LDRAW
equivalent. A part must have an "<origin>" tag, but it doesn't need a
"<geometry>" tag if LDD and LDRAW use the same part number.
"<remaptabula>" tags - these are extra LDD import tags, for mapping several
LDRAW parts onto the same LDD part. For example, you could map ungrooved tiles
onto grooved tiles. Unfortunately, you don't seem to be able to do the same
trick with colours.
"<ignoreUnknown />" tag - this is what makes the translator ignore any parts
that don't have an "<origin>" tag.
Please comment and share any fixes you find, so we can build up a running, fully
referenced list. You'll find 'plain text' is best for replying as 'FTX' posts
don't take too kindly to XML.
Jason Railton
| | | | | | | | | | | | | | | |
In lugnet.cad.ldd, Jason J. Railton wrote:
> I've been tinkering with the "ldraw.xml" file in LEGO Digital Designer (LDD),
> and have come up with the following list of fixes for good LDD/LDRAW conversion.
Hey Jason,
If this really works, and I believe you if you say so, would you mind
posting your ldraw.xml file?
It would save people time to retype (and perhaps mistype) your adjustments.
Thanks.
Jaco
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.ldd, Jaco van der Molen wrote:
> In lugnet.cad.ldd, Jason J. Railton wrote:
> > I've been tinkering with the "ldraw.xml" file in LEGO Digital Designer (LDD),
> > and have come up with the following list of fixes for good LDD/LDRAW conversion.
>
> Hey Jason,
>
> If this really works, and I believe you if you say so, would you mind
> posting your ldraw.xml file?
>
> It would save people time to retype (and perhaps mistype) your adjustments.
I wasn't sure of the copyright position; the original file is LEGO's property,
even if it is freely distributed. That's why I only posted the ammendments.
It'd be best if you copy and paste the lines of XML from my message into a copy
of your own file, rather than try to re-type them.
Jason R
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Jason J Railton wrote:
> In lugnet.cad.ldd, Jaco van der Molen wrote:
> > In lugnet.cad.ldd, Jason J. Railton wrote:
> > > I've been tinkering with the "ldraw.xml" file in LEGO Digital Designer (LDD),
> > > and have come up with the following list of fixes for good LDD/LDRAW conversion.
> > Hey Jason,
> >
> > If this really works, and I believe you if you say so, would you mind
> > posting your ldraw.xml file?
> >
> > It would save people time to retype (and perhaps mistype) your adjustments.
>
> I wasn't sure of the copyright position; the original file is LEGO's property,
> even if it is freely distributed. That's why I only posted the ammendments.
>
> It'd be best if you copy and paste the lines of XML from my message into a copy
> of your own file, rather than try to re-type them.
>
>
> Jason R
Jason,
Thanks for figuring out the 1x1x2/3 slope thing. It was driving me nuts.
Also, I think you are right. Even though it would be very convenient
to re-publish the ldraw.xml file, it is probably safest not to.
Thanks for putting this all together. Could you also possibly get LDD to
run on my aging Mac :) ?
Chris
--
http://users.rcn.com/cjmasi/lego/
Learn about brittle bone disease
http://www.oif.org/
| | | | | | | | | | | | | | | | | | |
Wicked awesome, Jason! I'm planning to convert a ton of ldd models over to dat
for BrickSpace and this'll help immensely!
-Stefan-
| | | | | | | | | | | | | | | | | |
In lugnet.cad.ldd, Jason J. Railton wrote:
> I've been tinkering with the "ldraw.xml" file in LEGO Digital Designer (LDD),
> and have come up with the following list of fixes for good LDD/LDRAW conversion.
<snip>
>
> Jason Railton
Good idea to publicize these changes. I have fixes for some other parts as well
but I'm out of town at the moment and won't be back for the next week and a
half. Once I get back I'll contribute any of my changes that haven't already
been posted by then.
I agree with Jaco that it'd be convenient to post a complete updated ldraw.xml
file. I was planning on uploading mine to go along with the ldd brick set page
I put together. Unfortunately I didn't have time to finish my latest changes
before I left.
J
| | | | | | | | | | | | | | | | | | |
| |
|
Apologies to anyone who didn't follow this post. It always bugs me when people
post technical stuff with no explanation, and just expect everyone to 'get it'.
In this case, a lot of people aren't going to be familiar with XML files, so
here's a quick explanation.
The file "ldraw.xml" in the LEGO Digital Designer's "database" folder is a
look-up list for converting LEGO Digital Designer (LDD) parts into LDRAW parts
and back again. Ordinarily, LDD uses its own ".lxf" file format for saving
models, which you won't be able to read. Using the look-up list in "ldraw.xml",
it can convert LDD models into ".ldr" files for editing in MLCAD and the like,
and load ".ldr" files back in.
The file is in XML format. This is a text format with marker tags in to make it
machine-readable. Each bit of useful data is enclosed by tags. These tags are
surrounded by 'less-than' and 'greater-than' symbols. At some point in
computing history, the 'less-than' and 'greater-than' symobls "<" and ">" got
promoted to 'honourary brackets'. Don't ask me how.
Anyway, a marked-up bit of data looks like this:
<tag> data </tag>
"<tag>" is the opening tag, and marks the start of the data.
"</tag>" is the closing tag, which marks the end of the data. Note that it's
the same name as the opening tag, but with a slash at the start.
The useful information is whatever's in between.
An opening tag can also have some parameters (these parameters aren't copied in
the closing tag by the way; that only needs the same name) like:
<tag name="tag001"> data </tag>
Tags and parameters can have any name you like, so long as the program reading
the XML has been programmed to understand them.
So, for example, the part number entry for the 1x1 tile looks like:
<geometry tabulaname="30039">3070b</geometry>
This is a 'geometry' tag; the parameter 'tabulaname' is LEGO's part number that
this applies to, and the data part, '3070b', is the LDRAW part reference to use
instead. The words 'geometry' and 'tabulaname' obviously mean something to LDD,
even if they don't make obvious sense to us.
In XML, a comment begins with "<!--" and ends with "-->". Everything within
these markers is ignored by the machine reading the file. So, to 'comment out'
the faulty 1x1 round plate definition, you have to change:
<remapldraw tabulaname="6141">4073</remapldraw>
to:
<!-- remapldraw tabulaname="6141">4073</remapldraw -->
(You can use 'find text' and search for the number '6141' a few times to get to
the relevant line).
What this edit does is it makes the opening tag, data and closing tag all part
of one big comment, so it's ignored. The machine reads the "<!--" part, then
skips along, ignoring the rest of the tags and the data they contain, until it
passes the "-->" at the end of the line.
This should give you enough information to understand how to edit the contents
of the XML file. There are some more features of XML you may want to know about
too:
1. It's probably obvious by now that you can have lots of tags with the same
name.
2. Line breaks are irrelevant to XML - the text is only laid out on separate
lines to make it easier to edit. As far as the computer is concerned, it could
all be bunched up on one line.
2. Tags can be nested; you can contain one lot of tags in another - but, they
must be completely contained, closing tags and all, or you get an error. For
example:
<outer>
<inner>
data
</inner>
</outer>
is correct, but:
<outer>
<inner>
data
</outer>
</inner>
is really really wrong.
3. Another common mistake is to write "<tag>data<tag>" instead of
"<tag>data</tag>", or simply to miss out some of your closing tags altogether
when they get too deeply nested. That's why they're often written on separate
lines and indented, so the author can keep track of how many tags deep he is.
4. If a tag doesn't actually have any data, but needs to be present as a
placeholder, it can be written as an empty tag:
<tag />
or just:
<tag/>
Note the slash is on the end, and you don't need a matching closing tag. So,
"<tag />" means the same as "<tag></tag>".
Finally, LDD reads the XML file as soon as you run it - it doesn't wait until
you load or save something. So, if you make changes, you have to exit and
re-start LDD, then try saving or loading your model again.
And, as with any file editing, make a copy of your original "ldraw.xml" file
under a different name before you start to edit, so you always have the original
to go back to.
Jason R
| | | | | | | | | | | | | | | | | | | | |
One more tip - if you want to check all your XML is marked up correctly and you
haven't made any mistakes, just double-click the file. It'll open in Internet
Explorer (unless your name's Christopher and you have a MAC... ;-).
You should see a neatly organised colour-coded list, where you can click on each
of the tags to expand it and see what's inside.
If there's an error in the tag structuring, you'll get an error message telling
you where it thinks the problem is. (Though you'll often find the root cause of
a problem is a typo on the line above or back at the start of a group of tags).
Jason R
| | | | | | | | | | | | | | | | | | |
| |
|
Here again is an optional fix. This will convert new brown in LDD models to old
brown in LDRAW, which is more convenient to edit in MLCAD:
First, comment out the old brown definition:
<!-- OLD BROWN, removed by Jason Railton 30.Jun.06 -->
<!-- colour tabulaname="25">6</colour -->
Then, comment out the new brown definition:
<!-- NEW BROWN, removed by Jason Railton 30.Jun.06 -->
<!-- colour tabulaname="192">70</colour -->
Finally, add in this crossover definition:
<!-- NEW TO OLD BROWN, remapped by Jason Railton 30.Jun.06 -->
<colour tabulaname="192">6</colour>
As for parts, I tried to do the 1x1 plate with tooth from the LDRAW Parts
Tracker (part 49668):
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/49668.dat
The re-orientation definition required is "y + 0.320" (down a plate) and rotate
Pi radians about the y axis (turn round 180°):
<!-- 1x1 PLATE WITH TOOTH, added by Jason Railton 30.Jun.06 -->
<origin x="0.000" y="0.320" z="0.000" axisx="0" axisy="1" axisz="0"
angle="3.141593">49668</origin>
And the part definition is simply:
<!-- 1x1 PLATE WITH TOOTH, added by Jason Railton 30.Jun.06 -->
<geometry tabulaname="49668">49668</geometry>
But, this doesn't work. If you place a tooth on your model in MLCAD, LDD will
import it in the right place. But, if you save the model from LDD in '.ldr'
format, the tooth will disappear. Re-loading the '.ldr' file can precipitate a
crash, too.
Contrary to some suggestions based on LDD 1.5, LDD 1.6 refers to all colours of
this part as "49668". I still don't know why this doesn't work though - it
worked for the 1x1x2/3 slope.
Jason Railton
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.ldd, Jason J. Railton wrote:
<snipped content>
> As for parts, I tried to do the 1x1 plate with tooth from the LDRAW Parts
> Tracker (part 49668):
> http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/49668.dat
<snipped content>
> But, this doesn't work. If you place a tooth on your model in MLCAD, LDD will
> import it in the right place. But, if you save the model from LDD in '.ldr'
> format, the tooth will disappear. Re-loading the '.ldr' file can precipitate a
> crash, too.
>
> Contrary to some suggestions based on LDD 1.5, LDD 1.6 refers to all colours of
> this part as "49668". I still don't know why this doesn't work though - it
> worked for the 1x1x2/3 slope.
I'd suggest experimenting and seeing if this is a color-specific issue.
49668 is one of the numbers that is remapped internally in the program, so that
(as you mentioned), it always uses the one number, for both opaque and
transparent parts. I wonder whether the part type that 49668 truly is (Opaque or
Transparent) will transfer fine, but the other coloring type is causing the
crash. The 1x1x2/3 slope doesn't act this way, which would be why I'm
suggesting this as the cause.
-- joshua
----
Joshua Delahunty
Lugnet member #3
| | | | | | |
