Freshly updated Ldraw.xml - Printable Version

Freshly updated Ldraw.xml - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw File Processing and Conversion (https://forums.ldraw.org/forum-22.html)
+--- Thread: Freshly updated Ldraw.xml (/thread-17387.html)

Freshly updated Ldraw.xml - Mattia Zamboni - 2015-09-28

Conversion LDD<-->LDraw

Hi everyone,

I would like to inform you all that at the following link you will be able to find the Ldraw.xml file updated on a regular basis, as soon as new conversions are available. Everyone can also contribute by sending me updates via the built-in messaging system.
I will make sure to:

1) test the submitted parts
2) update the xml file
3) release a new rev in the same location.

I included at the bottom of the page a log of the latest changes.

http://www.brickpassion.com/#!ldraw/cgjo

Comments are welcome.

- Mattia

Disclaimer: flexible parts (or multi bones: i.e. hoses, strings, ...) cannot be converted (limitation of LDD) and are therefore missing in the Ldraw converted file.

EDIT: If you plan on contributing please make sure to send me tested parts conversions only. In case I get wrong ones I will just notify the contributor and ask to fix and resend. Thanks

Re: Freshly updated Ldraw.xml - Willy Tschager - 2015-09-28

I'd like to see this at LDraw.org, preferibly with a short description what's all about and how it works - this could be a copy'n'paste of already available information. Let me know what do you think about.

w.

Re: Freshly updated Ldraw.xml - Rolf Osterthun - 2015-09-28

Hey Mattia,

it is good to see, that someone is engaging with this topic again. I really like what you are planning and I will try to contribute.

But first of all, I would like to ask you to clean up the file a bit. There are double entries for both, bricks and transformations (excuse the monoton format, it is an output from an applicaiton):

Code:
Multible definitions for the Brick 61252.

Multible definitions for the Brick xxx.

Multible definitions for the Transformation 6019.dat.

Multible definitions for the Transformation 41855.dat.

Multible definitions for the Transformation 2516.dat.

Multible definitions for the Transformation 2413.dat.

Multible definitions for the Transformation 57518.dat.

Multible definitions for the Transformation 92339.dat.

Multible definitions for the Transformation 45106.dat.

Multible definitions for the Transformation 54090.dat.

Multible definitions for the Transformation 3626bpa8.dat.

Multible definitions for the Transformation 54654.dat.

Multible definitions for the Transformation 54923.dat.

Multible definitions for the Transformation 64248.dat.

Multible definitions for the Transformation 30225b.dat.

Multible definitions for the Transformation 92088.dat.

Multible definitions for the Transformation 64783.dat.

Multible definitions for the Transformation 3641.dat.

Multible definitions for the Transformation 4003.dat.

Multible definitions for the Transformation 95320.dat.

Multible definitions for the Transformation 2531.dat.

Multible definitions for the Transformation 98376.dat.

Multible definitions for the Transformation 54090.dat.

Multible definitions for the Transformation 60779.dat.

Multible definitions for the Transformation 88287.dat.

Multible definitions for the Transformation 85944.dat.

Multible definitions for the Transformation 64797.dat.

Multible definitions for the Transformation 98366.dat.

Multible definitions for the Transformation 4505.dat.

Multible definitions for the Transformation 10173.dat.

Multible definitions for the Transformation 41881.dat.

Multible definitions for the Transformation 85948.dat.

Multible definitions for the Transformation XXXX.dat.

Multible definitions for the Transformation 2339.dat.

Multible definitions for the Transformation 76254.dat.

Multible definitions for the Transformation 30413.dat.

Then there are a lot of brick entries that are useless:

Code:
<Brick ldraw="XXXXX.dat" lego="xxxx" />

<Brick ldraw="XXXXX.dat" lego="XXXXX" />

For many of the transformations the LDraw part does not even exist. E.g.:

Code:
<Transformation ldraw="13250.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="3.141593"/>

From my point of view these placeholders (or at least I think that they are placeholders) will only confuse on the completeness
of the ldraw.xml and could guide to LDraw files, that contain wrong lines or lines for parts, that do not exist (I did not check
how the LDD handles them).

Btw, does the LDD use the <Assembly>-tags?

Rolf

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2015-09-28

Hi Willy,

your proposal makes sense to me: any idea where to place it on Ldraw.org?
I was in fact planning even a tutorial on how to come up with correct parts conversions, but since don't consider myself a guru on this matter I hesitated for now because I might say things which are not 100% correct.
The fact is that conversion for some part is very trivial, but for some other can be quite cumbersome and time consuming.

- Mattia

Re: Freshly updated Ldraw.xml - Philippe Hurbain - 2015-09-28

I have never been motivated enough to write such a tool myself, but I believe it should be relatively easy to have a program that compares a LDraw file and a LDD one, both supposed to contain the same model, and generates directly the line that goes to LDraw.xml.

One would create a LDraw file made from already validated parts, import it in LDD, then add a the same part (eg. colored in red) in both system, using the validated parts to place and orient it. Should be relatively easy to deduce rotation/translation data from that...

Re: Freshly updated Ldraw.xml - Willy Tschager - 2015-09-28

Hi Mattia,

best would be we grant you author rights to the CMS so you are able to upload a new version any time.

As for the tutorial I was more thinking about a what's this file for, where to place it, what kind of conversion you can expect, why do some parts work and others not, what happens if your model comes with a part that has no counterpart in the ldraw.xml, why get parts not conversed if placed say at odd angles, ...?

A compendium of the Q&A you can fined here or Eurobricks or ...

w.

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2015-09-28

@ Philippe,

I do understand your idea and I think generally speaking it would work.
What unfortunately I think turns the whole thing into a nightmare is that there are corresponding parts which in the 2 ecosystems have differently located+oriented pivots which makes the comparing process a true challenge.
This implies you should start analyzing vertices/surfaces location of the part to understand how parts are oriented in space.

I did something similar in a script in the 3D software I'm using in order to automatically replace parts with corresponding high polygons one, but as mentioned it has been way more complex than initially anticipated.

The rounding of coordinates which occurs during the conversion process doesn't make the process any easier :-(

- Mattia

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2015-09-28

Hi Rolf,

thanks for your comments.
As mentioned on my page my file has been based on the beta version found on the gallaghersart.com
I tried to understand how the file works and started to gradually add/fix parts, but far from saying I am an expert on this topic.
When it comes to the issues you raised I would assume they were present it the first place, but I agree we should have the file as clean as possible.
I can look into it, but with my current little spare time and a big project to complete I still have to put the priority on fixing parts.

Thanks!

- Mattia

Re: Freshly updated Ldraw.xml - Philippe Hurbain - 2015-09-29

Quote:This implies you should start analyzing vertices/surfaces location of the part to understand how parts are oriented in space.

I don't think we need to go this far. We can get orientation and offset of the new part relative to one of the reference parts in both systems, then solve the system (ldraw transformation)=(ldd transformation)x(ldd2ldraw transformation) to derive ldd2ldraw transformation

Now I agree that it is far from obvious, but I believe it can be done...

Quote:The rounding of coordinates which occurs during the conversion process doesn't make the process any easier :-(

Never understood why LDD keeps so many decimals but computes on so little!

Re: Freshly updated Ldraw.xml - Jarema - 2015-09-30

In free-time, I started clean-up this file. So one question come to my mind. If I have:

LINE 1 
LINE 2 <Brick ldraw="XXXXX.dat" lego="XXXXX" />
LINE 3 <Transformation ldraw="53981.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="0"/>

I remove only LINE 2 or ALL.

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2015-09-30

Hi Jarema,

thank you for helping out with the Ldraw.xml file!
I personally would experiment what happen to that part's conversion with and without entry to determine how to proceed, but probably Rolf can provide a more scientific answer here :-)

I just wanted to notify you to make sure you take the latest version I released (Sept 30th).
Now that I know you are working on this I can hold my next update until you are done and implement the changes in the cleaned up version.

Thanks!

- Mattia

Re: Freshly updated Ldraw.xml - Jarema - 2015-09-30

OK. I put my hands to work on this case.

like Rolf Osterthun say Wrote:Then there are a lot of brick entries that are useless:

Code:
<Brick ldraw="XXXXX.dat" lego="xxxx" /> <Brick ldraw="XXXXX.dat" lego="XXXXX" />

So I will clear this mess, with anyone support. Nothing more ,nothing less.

So one question come to my mind. If I have:

Code:
LINE 1 <!-- 53981 16h -->

LINE 2 <Brick ldraw="XXXXX.dat" lego="XXXXX" />

LINE 3 <Transformation ldraw="53981.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="0"/>

I remove only LINE 2 or ALL.

Re: Freshly updated Ldraw.xml - Rolf Osterthun - 2015-09-30

Hey Jarema,

in the example you choose the file 53981.dat does exist. So the brick node is useless, but the transformation node is necessary for a conversion from the LDD to the LDraw universe. But I do not know, if the values are right. This needs to be tested. I think the simplest way is to build a simple LDD file with two parts. A reference part and the 53981 part. I choose always the 1x1 brick as reference. If the LDraw output will look like the LDD input, the transformation node is likely correct.

Since the 53981 file is available, I would change the comment (line 1) either to the name used in the LDD (MINI FIG. WIG, MANGA 1) or the name used in LDraw (Minifig Hair Spiky Short); or even both.

If a part is not available in the LDraw universe, I would remove all three lines. E.g.:

Code:
<!--  87757 32c  -->

<Brick ldraw="XXXXX.dat" lego="XXXXX" /> 

<Transformation ldraw="87757.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="0"/>

Or we could create a todo section with comments.


These are just suggestions!

Rolf

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2015-09-30

Thanks Rolf for your input.

Personally if a part doesn't exist I would still like to see it converted in a either non official or non existing Ldraw part because:

1) it might be available at some point later on
2) it points out in Ldraw about missing parts, which is the only way to alert the user that the conversion wasn't possible on 100% of the parts.

This is actually my biggest problem with the conversion done in LDD: there is no final report or even a way to log the conversion details to file :-(

But as you also said these are just opinions/preferences.

- Mattia

Re: Freshly updated Ldraw.xml - Jarema - 2015-10-01

Thanks to Rolf Osterthun response. I Can use XML Notepad and Parts Tracker at http://www.ldraw.org/library/tracker to remove non-existed part in the LDraw universe and all XXXXX.dat entries.
Good knowlege base is located on http://brickset.com/ too.

Re: Freshly updated Ldraw.xml - Philippe Hurbain - 2015-10-02

Looking closer at the conversion results, I accidentally discovered a bug:

Code:
<!--  Technic Liftarm 1 x 9 Bent   32271 152.dat 15 -->

<Transformation ldraw="32271.dat" tx=".02" ty="-.4" tz="0" ax=".57735026918962576450914878050196" ay=".57735026918962576450914878050196" az="-0.57735026918962576450914878050196" angle="2.0943951023931954923084289221863" />

should actually be

Code:
<!--  Technic Liftarm 1 x 9 Bent   32271 152.dat 15 -->

<Transformation ldraw="32271.dat" tx="0" ty="-.4" tz="-.02" ax=".57735026918962576450914878050196" ay=".57735026918962576450914878050196" az="-0.57735026918962576450914878050196" angle="2.0943951023931954923084289221863" />

With current ldraw.xml, 32271 is offset by 0.5 ldu in x and y directions.

This kind of error seems to affect most liftarm related parts, eg. correct code for 2637 should be

Code:
<!--  Technic Link 16L 2637 21 -->

<Transformation ldraw="2637.dat" tx="0" ty="-.4" tz="-.02" ax=".57735026918962576450914878050196" ay="-.57735026918962576450914878050196" az=".57735026918962576450914878050196" angle="2.0943951023931954923084289221863" />

Frame 5x7 should be

Code:
<!--  Technic Beam 5 x 7 with Open Center 3 x 5 64179 21 -->

<Transformation ldraw="64179.dat" tx="2" ty="0" tz="1.6" ax="0" ay="1" az="0" angle="1.570796"/>

instead of

Code:
<!--  Technic Beam 5 x 7 with Open Center 3 x 5 64179 21 -->

<Transformation ldraw="64179.dat" tx="2" ty=".02" tz="1.6" ax="0" ay="1" az="0" angle="1.570796"/>

And so on...

We really need a tool that calculates precisely ldraw.xml entries!

put ldraw.xml to github? - Steffen - 2015-10-03

Mattia, do you think it would make sense to put ldraw.xml to github ?

This would have the advantage that a version history automatically is present,
and users can download older versions of the file easily.

Edits could be done there as normal commits, and you (or someone else) could get them via
the usual pull requests.

Re: Freshly updated Ldraw.xml - Rolf Osterthun - 2015-10-05

Hey Jarema,

Jarema Wrote:I Can use XML Notepad and Parts Tracker at http://www.ldraw.org/library/tracker to remove non-existed part in the LDraw universe.

did you use some kind of automatic detection? If yes, how does it work? I think your file is a really good starting point.
But I am afraid, that we have to clean it even more:

Afaik the LDD has only numbers for parts, assemblies and aliases. But in the ldraw.xml there are 3 entries with letters:
For the first one I think we will have to find another lego number.

Code:
<!-- Plane Jet Engine with Plate 2 x 2  4868 25  -->

<Brick ldraw="u9017.dat" lego="4868a" />

<Transformation ldraw="u9017.dat" tx="-.4" ty="1.04" tz="-.4" ax="0" ay="1" az="0" angle="4.712389" />

The second and third are exactly the same. At least one can be removed. But there is also a attribute (itemNos) I do not know if
it is working.

Code:
<!--  3626bpa8  -->

<Brick ldraw="3626bpa8.dat" lego="xxx" itemNos="82359" />

<Transformation ldraw="3626bpa8.dat" tx="0" ty="-.96" tz="0" ax="0" ay="1" az="0" angle="0" />

<!--  3626bpa8  -->

<Brick ldraw="3626bpa8.dat" lego="xxx" itemNos="82359" />

<Transformation ldraw="3626bpa8.dat" tx="0" ty="-.96" tz="0" ax="0" ay="1" az="0" angle="0" />

And then, we still have a few transformations that are defined multiple times:

Code:
Multiple brick node for 61252

Multiple transformations for 6019.dat

Multiple transformations for 41855.dat

Multiple transformations for 2516.dat

Multiple transformations for 2413.dat

Multiple transformations for 11297.dat

Multiple transformations for 57518.dat

Multiple transformations for 92339.dat

Multiple transformations for 45106.dat

Multiple transformations for 54090.dat

Multiple transformations for 3626bpa8.dat

Multiple transformations for 30225b.dat

Multiple transformations for 3641.dat

Multiple transformations for 4003.dat

Multiple transformations for 2531.dat

Multiple transformations for 41881.dat

Multiple transformations for 2339.dat

Multiple transformations for 76254.dat

Multiple transformations for 30413.dat

At least there are a few transformations, that have no counterpart in the LDraw universe:

Code:
30237b.dat not available in LDraw

4865bb.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

x240.dat not available in LDraw

x136.dat not available in LDraw

x1681.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

4485b.dat not available in LDraw

dat not available in LDraw

x396 not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

x45.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

x246.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

4739a.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

x933c01.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

x132 .dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

87562pb01.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

x1608.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

x1687.dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

dat not available in LDraw

x516.dat not available in LDraw

bb607.dat not available in LDraw

x71.dat not available in LDraw

x37.dat not available in LDraw

x90.dat not available in LDraw

dat not available in LDraw

I did not check them all, but in my LDraw lib they seem to be not available.

Attached you can find a text file that could be used as some kind of ToDo list. It should contain all LDD parts and assemblies of brickset 1564.1 sorted by designId. I generated it like this:

Code:
foreach (designId in LDDParts)

{

  check if designId.dat exists

  check if transformation node for designId exists in ldraw.xml

  if (brick node for designId exists in ldraw.xml)

  {

    check if transformation node for brick exists in ldraw.xml

    check if brick.dat exists

  }

    if (no transformation found)

    {

      search for possible LDraw files

    }

}

Rolf

Re: Freshly updated Ldraw.xml - Rolf Osterthun - 2015-10-05

Hey Mattia,

Mattia Zamboni Wrote:Personally if a part doesn't exist I would still like to see it converted in a either non official or non existing Ldraw part because:

1) it might be available at some point later on
2) it points out in Ldraw about missing parts, which is the only way to alert the user that the conversion wasn't possible on 100% of the parts.

I am fine with that. But did you think about the following:
1) The origin and the orientation may change.
2) Would something like this be usable for you:

Code:
Open ldraw1.6r.xml.

Read mappings...

Close ldraw1.6r.xml.

Open l2l.xml.

Read mappings...

Close l2l.xml.

Open 1b687af0-04b4-423a-bc81-b10592760199.lxfml.

Open 1b687af0-04b4-423a-bc81-b10592760199.ldr for writing.

Mapping parts...

The input file is in version: 4.0

The Part 60481 is not available in LDraw yet. No mapping.

The Part 60481 is not available in LDraw yet. No mapping.

The Material 148 used by the Part 53989.dat is not known. Using Main Color 16!

The Material 148 used by the Part 53989.dat is not known. Using Main Color 16!

The Material 148 used by the Part 53989.dat is not known. Using Main Color 16!

The Material 148 used by the Part 53989.dat is not known. Using Main Color 16!

Close 1b687af0-04b4-423a-bc81-b10592760199.ldr.

Close 1b687af0-04b4-423a-bc81-b10592760199.lxfml.

273 parts mapped.

4 parts had an unknown Material; Used Main Color 16 instead.

0 parts unknown.

0 parts defect (cann't be read correctly).

0 parts are not created for LDraw yet.

2 parts are waiting on the Parts Tracker.

I am almost done with the implementation of our converter (http://www.digital-bricks.de/en/index.php?site=konv-how-to), so that he can also handle lxf files in version 5.

Rolf

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2015-10-10

Hi Rolf,

sorry for the belated reply: I just noticed your answer.
Your plan sounds great to me, and I am really glad you are working on implementing the support for .lxf ver5!

If your software can provide this kind of logging it is perfect to me, since you have much better feedback from the conversion and even statistics. Does your converted uses the exact same ldraw.xml file for the translation?

And let me ask you, this implies that multi bones part will be able to be converted as well? This is indeed a pity that it doesn't work in the LDD conversion.

If you need any additional feedback do not hesitate to ask.

Thanks!

- Mattia

Re: Freshly updated Ldraw.xml - Rolf Osterthun - 2015-10-12

Hey Mattia,

Mattia Zamboni Wrote:Does your converted uses the exact same ldraw.xml file for the translation?

yes, the converter uses the ldraw.xml.

Mattia Zamboni Wrote:And let me ask you, this implies that multi bones part will be able to be converted as well?

In theory yes. But I never had a look on that. In the past I started to create an extended ldraw.xml. But since I did not want to
add tags or attributes to a xml file that is used by other programms (and where I have no xsd file for), I created a second xml file: l2l.xml. There I started to define decoration mappings for example.

Code:
<!--  Tile 2 x 2 Round   -->

  <!--  Tile 2 x 2 Round with SW Millennium Falcon Vent Pattern   -->

  <Decoration ldraw="4150ps4.dat" lego="4150" decorationID="55729" />

In the current ldraw.xml from Mike Gallagher there are tags (

Code:
<Assembly>

) and attributes (

Code:
itemNos

) where I do not know if the LDD is using them (?).

In the meantime I wrote a small tool, that created a ldraw.xml insted of the ToDo list. Input is a existing ldraw.xml and output is a new ldraw.xml. The attached file was created by the following pseudo code:

Code:
foreach color available in LDD

{

  print localized name as comment

  if mapping definition in ldraw.xml available

  {

    if entry in LDConfig.ldr

    {

      print ldraw name as comment

    }

    else

    {

      print "ToDo: Undefined LDraw color" as comment

    }

    print <Material> tag

  }

  else

  {

    print "ToDo: Missing color mapping" as comment

  }

}

foreach designId in LDDParts

{

  print designName as comment

  if file designId+".dat" available

  {

    print LDraw name as comment

  }

  else

  {

    print "ToDo: LDraw file (designId+".dat") does not exist!" as comment

  }

  if <Transformation> tag for designId+".dat" in ldraw.xml available

  {

    print <Transformation> tag

  }

  if <Brick> tag for designId available

  {

    if <Transformation> tag for <Brick>.ldraw in ldraw.xml available

    {

      print <Brick> tag

      if file <Brick>.ldraw available

      {

        print LDraw name as comment

      }

      else

      {

        print "ToDo: LDraw file (<Brick>.ldraw) does not exist!" as comment

      }

      print <Transformation> tag

    }

  }

  if     no <Transformation> tag for designId+".dat" in ldraw.xml

     and no <Transformation> tag for <Brick>.ldraw in ldraw.xml

  {

    print "ToDo: Missing Transformation"

  }

}

At the end of the file I added the 'from my point of view' obsolet entries from the input ldraw.xml. Btw, the tool does not look for LDD aliases. Currently I do not know how the LDD saves them in the .lxf-files.

When there will be a new LDD brickset one day or if there are new LDraw parts available, it will be very easy to generate a new ldraw.xml with updated ToDo's.

The question is: which file should I use as input file? In Mike Gallagher's file there seems to be special areas: 'below working 4.40', 'Problematic part numbers', 'Needs work or LDR dat file created', ... If I use it, the result will contain entries that are wrong. And they will be even harder to detect, because my tool sorts the entries by designId.

So there is still a lot of work to do.

Rolf

Re: Freshly updated Ldraw.xml - Jaco van der Molen - 2015-10-13

Great work here!
I am trying to add a part.

My lines in ldraw.xml are these


<Brick ldraw="55423.dat" lego="57999" />
<Transformation ldraw="55423.dat" tx="0" ty="0" tz="-0.8" ax="0" ay="1" az="0" angle="0" />

It should turn 180° over y, so I put transformation ay="1", but it just won't turn.
It also moves over tz="-0.8" (I think) and that works.

Why does it not turn?

Re: Freshly updated Ldraw.xml - Philippe Hurbain - 2015-10-13

Quote:It should turn 180° over y, so I put transformation ay="1", but it just won't turn.

I think it does what you asked for: rotate around ay by 0° (parameter angle="0")

Re: Freshly updated Ldraw.xml - Jaco van der Molen - 2015-10-13

Philippe Hurbain Wrote:
Quote:It should turn 180° over y, so I put transformation ay="1", but it just won't turn.
I think it does what you asked for: rotate around ay by 0° (parameter angle="0")

Hmm, OK. I am not yet into this.
So, if I say ay=1 then the value of angle should be 3.141593.
This is Pi? Why is that?

Edit 2: after much trial and error I think the correct entry in ldraw.xml for this part should be:


<Brick ldraw="55423.dat" lego="57999" />
<Transformation ldraw="55423.dat" tx="0" ty="0" tz="-0.65" ax="0" ay="1" az="0" angle="3.141593" />

Re: Freshly updated Ldraw.xml - Philippe Hurbain - 2015-10-13

Ax, ay and az define the direction of the vector around which the rotation is to be performed. Angle of the rotation is expressed in radian (angle in radian = angle in degrees * Pi / 180)

Re: Freshly updated Ldraw.xml - Magnus Forsberg - 2015-10-13

Hello all,

I've been tinkering with this file on and off since 2007. Great to see a renewed interest in making it better.

I don't think it is possible to "crack" the code and make a tool that can simply translate the values. Each pair of Ldraw-LDD parts seams to have it own set of values.

How to add a new part?

This is an empty example, and a good start.

Code:
<!-- description text-->

<Brick ldraw="XXXXX.dat" lego="YYYYY" />

<Transformation ldraw="XXXXX.dat" tx="0" ty="0" tz="0" ax="0" ay="1" az="0" angle="0"/>

Only one line, the third, is really needed if the partnumbers are identical between Ldraw and LDD.

First line is simply a text string, most often the Ldraw description. Mike Gallagher used to add some more info. I would love to see both the Ldraw description and the LDD equivalent. After all, it is a translation file.

Second line is necessary if there is a difference in partnumbers between Ldraw and LDD. It makes the connection between them. If we decide to renumber a Ldraw part, e.g by adding a suffix to the partnumber and/or create a moved to-file, the ldraw.xml needs to be updated aswell.

Third line is the translation code.
tx, ty and tz moves the part in steps. 0.04 units in ldd = 1 ldu.
We have the origin in the middle of the brick. LDD have the origin in the first stud. Or somewere else.
The x-axis is inversed.

Philo Wrote:ax, ay and az define the direction of the vector around which the rotation is to be performed. Angle of the rotation is expressed in radian (angle in radian = angle in degrees * Pi / 180)

Any a-value between 0 and +/-1 is possible.
90 degrees = 1.570796
180 degrees = 3.141592
More than one rotation direction is possible in the same translation, but only one angle.

These simple rules are most often enough to make a new part work.
Some parts are more difficult to translate. Angled Technic Beams or Panels are really tricky, since they often have very different origin and position in LDD and Ldraw.

The translation code also seem to evolve over time. The current translation code for part 30377 is today very different from the one I originally made and sent to Mike Gallagher. I have a feeling that the LDD-team have adapted some of there parts to our coordinate system.

I'm no programmer, nor good at math, so please don't expect me to explain/understand any of these math-rules.
I'm just good at finding patterns and making analyzes.

Attached here is a document I made back then and an excel-sheet with some simple tools I've used.

Re: Freshly updated Ldraw.xml - Rolf Osterthun - 2015-10-13

Hey Magnus,

thanks for sharing your collected information.

Magnus Forsberg Wrote:
Philo Wrote:ax, ay and az define the direction of the vector around which the rotation is to be performed. Angle of the rotation is expressed in radian (angle in radian = angle in degrees * Pi / 180)
Any a-value between 0 and +/-1 is possible.
90 degrees = 1.570796
180 degrees = 3.141592
More than one rotation direction is possible in the same translation, but only one angle.

The a-values define a vector (or a direction) where the part will be rotated around by the defined angle. Normally the vector should have the length 1. So it is possible to have the simple vectors:

1, 0, 0; rotation around the positiv x-axis
0, 1, 0; rotation around the positiv y-axis
0, 0, 1; rotation around the positiv z-axis

But it is also possible to rotate the parts around any other vector. E.g.:

0.7071, 0.7071, 0; rotation around a vector in the x-y-plane
0.7071, 0, 0.7071; rotation around a vector in the x-z-plane
...

And you can reach the final destination by more than one way. For example, if you rotate a part around the positiv z-axis by 90° you will get the same result as if you rotate the same part around the negativ z-axis by 270° (or -90°) and so on.

I think the technic is also described here.

(Only for addition) Rolf

Re: Freshly updated Ldraw.xml - Jaco van der Molen - 2015-10-14

Great explainations Magnus, Rolf and Philo!

Re: Freshly updated Ldraw.xml - Jaco van der Molen - 2015-10-14

Magnus Forsberg Wrote:Second line is necessary if there is a difference in partnumbers between Ldraw and LDD. It makes the connection between them. If we decide to renumber a Ldraw part, e.g by adding a suffix to the partnumber and/or create a moved to-file, the ldraw.xml needs to be updated aswell.

Would it be an idea to just create a file with the filename "LDD number.dat" where we just add the LDraw part?

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2015-10-14

Hi Rolf and everyone,

thanks for all the great work and for the inputs: here is my take on all this Ldraw.xml thing:

This file will most likely always need to be edited and updated manually. For this reason in my view it should be as easy as possible to read and understand, so for example I see as very useful to have an empty line between parts, same thing goes for other kind of notes/marks which can help the user to edit the file.
Because of this the file might not be as clean as we might want it, but as long as the conversion works properly I don't really see an issue.
When it comes to the parts order it is also more convenient to just append new parts at the end instead of inserting them in the proper place by DesignId. So, I personally would suggest that we could add new ones at the end and every now and then we resort them and release a new version.

For the above reasons I am currently a bit hesitant to take straight the file kindly cleaned by Jarema, since the are no empty lines between parts and concurrently it is also hard for me to check at 100% that the cleaning has been done properly.

Rolf, to answer your question, how about letting your converter just translate the file and just append the special areas at the end untouched? Would it be possible to create markers to basically highlight either the part to be converted, or on the contrary the part not to be translated?

Just an idea...

Thanks,

- Mattia

Re: Freshly updated Ldraw.xml - Rolf Osterthun - 2015-11-02

Hey Mattia,

Mattia Zamboni Wrote:And let me ask you, this implies that multi bones part will be able to be converted as well? This is indeed a pity that it doesn't work in the LDD conversion.

yes, it is. Here is the result of a first test (source is from Eurobricks).

.png

flex-o-rama1.png (Size: 61.93 KB / Downloads: 48)

But you can see, that there will be a special handling necessary. The beginning and ending parts are wrong and for some parts a alternate algorithm will be needed.

Rolf

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2015-11-03

Hi Rolf,

this is really great news and as a first result it looks very promising! Thanks for your efforts on this.
I can understand that special handling and even algorithms for different parts might be needed but hey... at least we have a solution!

In order to better coordinate our efforts around the ldraw.xml file I wouldn't mind to get in direct contact with you.
You can drop me a message through my website and I will get back to you.

Thanks!

- Mattia

Re: Freshly updated Ldraw.xml - Philippe Hurbain - 2016-02-07

Mattia,
Are you aware of the work of Shutterfreak on LDraw.xml? (Eurobricks thread)

Re: Freshly updated Ldraw.xml - Mattia Zamboni - 2016-02-07

Hi Philippe,

thanks for pointing out this to me.
Olivier was kind enough to send me a note about his work and a link to this thread.
I will make sure to include these parts in my next update.

Thanks!

- Mattia

RE: Freshly updated Ldraw.xml - Sylvain Sauvage - 2016-07-16

Hi Mattia,
A few days ago, I started a thread on Eurobricks ( http://www.eurobricks.com/forum/index.php?showtopic=137193 ) to make available the corrections I made to my ldraw.xml and Philo/Philippe later pointed me to this thread.
It seems my version is more up-to-date than the one you made available (2015-09-30) (even more so since I included some of your modifications Wink

). (Note that I include unofficial LDraw parts.)
Just take a look or contact me if you want to mutualize the work.
— Sylvain