How to make custom LDD stuff?

[pauldk]

So guys, I know this topic has been discussed once before.

Is there a way to make my own bricks for LDD, or make custom decals?

I think I have to find the files in the db.lif or Assets.lif, but I have tried to google for any programs that can extract LIF files, but I haven’t been lucky so far.

Edited September 13, 2011 by pauldk

[Calabar]

Look at this recent topic.

It's the same request, but regarding decorations only.

The answer is valid for both decorators and 3D models.

[Bojan Pavsic]

@pauldk

Even if you'd find a software to extract LIF files, you wouldn't be able to create a new part that easy.

First you'd need to find the exact scale, so your new parts wouldn't stand out. Then you'd need to create the 3D graphic mesh, the 3D collision mesh, the shading data and the connection data. Afterwards you'd need to pack it all back together. And trust me... that's not easy.

Edited September 15, 2011 by Bojan Pavsic

[nemo]

The .lif isn’t too bad. And in fact it isn’t necessary to rebuild it.

Generating the .g mesh files is not trivial though. What software is used to build those?

[Bojan Pavsic]

The .lif isn’t too bad. And in fact it isn’t necessary to rebuild it.

Well, if you want to insert a new item and you don't rebuild the db.lif, you need to inject the data into the original one and change quite some other bytes in there (which represent the sizes of the chunks in there) and you need to update the lifs TOC... It's easy if you know how the lifs are made.

If you don't want to change everything, you have to find a piece with the same number of polygons and edges and replace it, but that's not really the point, is it...

The bigger problem with .g files is that the lifs were the same since version 3.x (don't know how they were before), but the .g files changed through versions... Dunno if they'll keep the files the same, now that they added the edge data. I hope they will :)

[nemo]

Well, if you want to insert a new item and you don't rebuild the db.lif, you need to inject the data into the original one

Is that actually true though, or does it only look in db.lif if it hasn’t got a \db\ etc? LDD certainly doesn’t work if I add an empty \db\, so I assume it looks there first.

[hrontos]

It is interesting see how the db.lif works like magnet to many people.

Are you really interested to add something into LDD?

I mean, do you have anything prepared - like decoration, brick geometry or something else? Or are you just curious?

How would you then share the model with others, when they do not have your modifications?

Or it is enough for you to have it just for your personal use?

It quite easy to have custom brick database with custom decorations. But it is probably not the right way.

May be we can ask TLG to put something there for us. I mean, if they do not have the time to add new decorations or correct connection points of some bricks or make flex part really flex (these three types are the easiest), we can try prepare it and we will see, if TLG will accept it.

[nemo]

How would you then share the model with others, when they do not have your modifications?

The .lxf file is just a zip, so could contain any non-standard resources. In principle this is no different to including the correct images and fonts in an .xps or .odt file. Then if someone adds a sticker they could send you an .lxf containing the brick and its sticker which you could then copy and paste, or add to your own repertoire.

[Bojan Pavsic]

@nemo

and what happens if let's say person A makes a part #12345 and sends that around with his lxf. Then comes person B that doesn't know about person A and makes another version of part #12345 (which might or even might not be the same part - as we all know the differences between BL/LDD/MLCAD part names...). Will you do that by hand? Maybe... What about those people that don't know how to decompress the file. Or where to copy the new files...

In a matter of weeks, TLG would get tons of e-mail "LDD doesn't work anymore", forums would be flooded with people not knowing what to do... (ok, maybe not that much but still... get the point?)

For this to work, there would have to be a webpage/webservice/something that would have all the new parts, all of their versions (approved by administrators) and a button downloader. When this is done, then there's the problem with custom parts. Ok, let's say only original Lego parts are allowed. Then someone comes along who would like his custom minifig. Then another who'd like Brickarms (or whatever that Lego weapons maker/seller is) parts...

To get a custom part into LDD is the least of the problems and i just wrote down only a couple of them.

[nemo]

what happens if let's say person A makes a part #12345 and sends that around with his lxf. Then comes person B that doesn't know about person A and makes another version of part #12345. Will you do that by hand?

If they’re the same, there’s no problem. If they are different then it is just the same as copying 12345.g into a directory containing 12345.g – LDD would ask which one you wanted to keep. It could display both side by side in 3D, or in context in the model. Or it could just rename the second to be 12345(2).g (adjusting the loaded .lxf accordingly).

Obviously if you allow custom parts in LDD, then it needs a way of managing them, but this isn’t a difficult problem.

(which might or even might not be the same part - as we all know the differences between BL/LDD/MLCAD part names...)

Well that’s a separate problem. I’d solve it by having a namespace for any non-official part number and have LDD map equivalent parts. There’s already the many-to-one mapping of brick/colour number to mould number. There’s no reason why one couldn’t have BL:12345.g for example.

What about those people that don't know how to decompress the file.

If we are talking about functionality built into LDD, then that question doesn’t arise. If we are not talking about LDD functionality, then the only thing one can do is modify or unpack db.lif and add the .g etc files manually. A stand-alone “interoperable program” would be the easiest solution to that.

In a matter of weeks, TLG would get tons of e-mail "LDD doesn't work anymore", forums would be flooded with people not knowing what to do... (ok, maybe not that much but still... get the point?)

What are we talking about – new LDD functionality or a third-party hack? If it’s LDD functionality then one would hope they wouldn’t introduce any more bugs. If a third-party hack then you cover it with “THIS IS A HACK” warnings. You say “If you use this facility it may stop your copy of LDD working and you may have to uninstall the hack”. Then you provide a mechanism to return to the original db.lif and LDD returns to its original state.

For this to work, there would have to be a webpage/webservice/something that would have all the new parts, all of their versions (approved by administrators) and a button downloader.

That would be very nice, though it isn’t necessary. There is this very forum!

then there's the problem with custom parts.

Again, namespaces are the solution to that.

Then someone comes along who would like his custom minifig.

Actually it’s stickers, rather than bricks, that I anticipate would proliferate most. They’re much easier for the average user to produce, and there are probably more stickers missing from LDD than bricks. Managing namespaces for custom stickers is more tricky, and would probably necessitate very long Android-style identifiers: eg com.eurobricks.forum.nemo:12345.png

Then another who'd like Brickarms (or whatever that Lego weapons maker/seller is) parts...

Wouldn’t it be nice if Brickarms could provide a definitive set of digital parts though?

To get a custom part into LDD is the least of the problems and I just wrote down only a couple of them.

There’s rather more to software engineering than typing, but this is what I do so it doesn’t seem so hard to me.

[Calabar]

@nemo

The problem, IMHO, is not related to issues that can be solved with some kind of effort by LDD staff, but to these situations that can't be "solved" but have to be accepted.

If you use custom bricks/decorations, you have to provide a way to allow all LDD user to open a model with that custom bricks.

Include that in the lxf file could seem a good solution, but this can increase the file size (with decorations overall!). But ok, we decide to include that additions.

Imagine a child that find the file and opens it. Then he want to use that pieces for his models, but the piece is not in his database. Ok, let's suppose that the piece is added to the database too. But what happens if the child moves to another computer, or "format" his operating system? He will not have the pieces anymore.

For a crafty pc user it is not a problem, but what about unexperienced users?

LDD target is not Adult fan. For adults LDD developers unlocked some feature (in the extended mode) that was not born as standard feature of LDD, but they will not upset a software born for another goal to add feature that was not useful to achieve it.

[Bojan Pavsic]

@nemo

So that we're clear. What we're talking here is an external app... LDD will (most certainly) never support this. I know what does all this take from programming perspective as i'm a software developer for 20 years.