(I've seen two other threads along these lines pop up here within the past month or so - I know Eurobricks used to shy away from such discussions, but I'm assuming that with LDD pretty much dead, the stance on it has been relaxed? If I'm wrong, hopefully it should be apparent there's no ill intent here, and I take no issue with this thread being hidden/deleted.)

---

@M2m got me curious about playing around with .g files myself, with his converters and various scripts. I remembered Simon from the LU community had made a .g importer script for Unity some time back, so I got it from him, and tidied it up + expanded on it some more (added support for .g1/.g2/etc files, and UV coordinates), then rigged it up to some obj exporting code. Mostly just for the fun of it, and also cause I hadn't done any binary file reading before, and it seemed like a good chance to see how it worked.

Here's the result, a standalone program that can convert LDD .g bricks to OBJ:

https://github.com/Terrev/G-to-OBJ/releases

 

---

On my machine, it converts all 4186 bricks in the LDD library in 1 minute, 2 seconds. I have a solid state drive; it will probably be a bit slower on a mechanical hard drive but still fairly fast.

I was thinking of rendering out icons of bricks too, but couldn't think of a practical use for myself, and anybody who'd want that could do it themselves with their program of choice.

If you use this on bricks from LDD (as opposed to, say, .g files from LU), be aware you should be using the contents of db.lif in AppData, NOT Assets.lif in Program Files (Assets.lif becomes outdated when LDD receives a patch with new bricks... if that will ever happen again, anyway): https://www.rockraidersunited.com/topic/7899-ldd-updatingpatching/

To extract LIF files, I recommend: https://github.com/JrMasterModelBuilder/LIF-Extractor/releases

Edited February 25, 20196 yr by jamesster

Great ?? As I am on travel I couldn’t test it myself yet, but certainly will once back home. Also I will try to compare your results vs mine. 

Great job once again. 

Edited February 24, 20196 yr by M2m

This is really nice, but Its kinda hard to locate specific part. Gotta search through everyting and name the item i wanna remember. Or is it design element in which order they where made?

13 hours ago, M2m said:

Great ?? As I am on travel I couldn’t test it myself yet, but certainly will once back home. Also I will try to compare your results vs mine. 

Great job once again. 

Thanks! I'm still tinkering with improving the speed - it seems the OBJ exporting code is to blame for it; large pieces like the 32x32 and 48x48 baseplates are loaded and can be displayed on-screen almost instantly, but writing the OBJs for them currently takes 1-2 minutes, which is rather ridiculous. I have to get ready for work now but I'll see about narrowing down the issue tonight or within the next few days.

Edit - What's got me especially curious is that the OBJ exporting code in my 3DXML to OBJ converter works fine, and can process a 48x48 baseplate very quickly. The OBJ exporting code in this project is based off of the 3DXML project's code, but one of the changes I made must have slowed it down significantly. I have a few ideas as to what but won't be able to test until tonight.

6 hours ago, Simeb said:

This is really nice, but Its kinda hard to locate specific part. Gotta search through everyting and name the item i wanna remember. Or is it design element in which order they where made?

Welcome to Eurobricks! If you only want a specific part, LEGO Digital Designer can give you the ID for it in the lower left corner when you place it in the scene and select it, or websites like Bricklink can usually be of help too.

Edited February 24, 20196 yr by jamesster

3 hours ago, jamesster said:

Thanks! I'm still tinkering with improving the speed - it seems the OBJ exporting code is to blame for it; large pieces like the 32x32 and 48x48 baseplates are loaded and can be displayed on-screen almost instantly, but writing the OBJs for them currently takes 1-2 minutes, which is rather ridiculous. I have to get ready for work now but I'll see about narrowing down the issue tonight or within the next few days.

I think that you probably have a loop issue. I had problems in the beginning too and my generated obj files where several MBs big. I was just looping (and writing) to much. I fixed it and now they are just a few kB big. 

Edited February 25, 20196 yr by M2m

It turned out to be a simple problem not even with my code particularly - Unity's Mesh class was slowing it down. In the 3DXML to OBJ project, I'd made my own minimalistic CustomMesh class used for most things instead, because back then, Unity couldn't accept meshes with more than 65535 vertices (mesh index buffers could only be 16 bit; it now supports 32 bit index buffers as well, which can have up to 4 billion vertices). When I did this project, I thought "oh, I can just use the normal Mesh class now", but apparently that led to it doing who-knows-what entirely behind the scenes when the OBJ export code used those meshes. I went back to a simple CustomMesh class, and now the entire LDD brick library (4186 bricks) converts in 1 minute, 2 seconds on my machine - much better than the previous 11 minutes, 22 seconds.

New release available at the link in the first post.

Edited February 25, 20196 yr by jamesster

I get directory not found error on MacOS and the UI is super small (mind this is a Retina Display - so the screenshot is 4 times bigger)

 

The file paths in your screenshot look rather odd, granted I haven't touched a Mac in ages myself, but I sent it over to a friend with one for testing and it worked a-ok for them. Can you paste the full directory paths you're trying to use?

As for the UI, that's pretty much controlled by Unity itself, it's an old UI system but it's convenient to use - I wasn't aware of it having any quirks with retina displays, though it makes sense it would given everything is controlled by measures of pixels. I think I'd have to just switch over to the newer UI system entirely and it'd (hopefully) scale properly.

Edited February 28, 20195 yr by jamesster

Ok  I got it working. Seems the program doesn't like paths with spaces (which are in osx indicated with the \ character). I copied my LOD0 folder to a path without spaces and it converted all files in 1:17.

Just a question - did you get an obj file for part 84638 (mini upperpart w. hook) ? I didn't find this brick among several others.

35 minutes ago, M2m said:

Ok  I got it working. Seems the program doesn't like paths with spaces (which are in osx indicated with the \ character). I copied my LOD0 folder to a path without spaces and it converted all files in 1:17.

Just a question - did you get an obj file for part 84638 (mini upperpart w. hook) ? I didn't find this brick among several others.

That also appears to be something outside of my control as far as I know, as I simply pass the input string to this: https://docs.microsoft.com/en-us/dotnet/api/system.io.directory.exists?view=netframework-4.7.2

Those are assemblies of bricks, not bricks themselves. If you look in the Assemblies folder in db.lif, you will find a 84638.lxfml file that defines the bricks that comprise it. (And if you try to open it in LDD, LDD will say that 5 pieces could not be placed, as it doesn't let you place minifigure torsos, arms, hands, etc individually).

Edited March 1, 20195 yr by jamesster

12 hours ago, jamesster said:

Those are assemblies of bricks, not bricks themselves. If you look in the Assemblies folder in db.lif, you will find a 84638.lxfml file that defines the bricks that comprise it. (And if you try to open it, LDD will say that 5 pieces could not be placed, as it doesn't let you place minifigure torsos, arms, hands, etc individually).

Cool thanks for the tip ! This helped me to get minifigs working:

you think it's possible to make this a plugin for LDD?  like you give LDD the ability to export OBJ by running the lxf through it so you get all its transforms applied to the .g models.

you build in LDD and then work on the resulting model in another app.

EDIT: and since you said this was made in Unity maybe this could help: FBX Exporter for Unity.

dont just get geometry but the transforms intact and maybe whatever bones and rigs LDD uses as well as textures and groups.
 

Edited July 10, 20195 yr by Kalta the Noble Mind

1 hour ago, Kalta the Noble Mind said:

you think it's possible to make this a plugin for LDD?  like you give LDD the ability to export OBJ by running the lxf through it so you get all its transforms applied to the .g models.

you build in LDD and then work on the resulting model in another app.

EDIT: and since you said this was made in Unity maybe this could help: FBX Exporter for Unity.

dont just get geometry but the transforms intact and maybe whatever bones and rigs LDD uses as well as textures and groups.
 

Try this

 

I have tried it but for some reason, it didn't work. maybe I was using it wrong.

i know

7 minutes ago, M2m said:

Try this

 

took me 5 tries to realize I had to move the assets file to the same location as the extractor for it to work.

On my MacOS system it finds the assets file automatically (it’s in the default location). Are you on windows ? 

nope mac as well. it always tells me it cant find the directory

no idea if i have to move stuff elsewhere to make it work.

also where is the assets file located? i had to open up my LDD app to get at it.

The script looks for Users/theuser/Library/Application Support/ LEGO Company/LEGO Digital Designer/db.lif

8 hours ago, Kalta the Noble Mind said:

nope mac as well. it always tells me it cant find the directory

no idea if i have to move stuff elsewhere to make it work.

also where is the assets file located? i had to open up my LDD app to get at it.

We should maybe continue in the respective thread. But out of curiosity would you care to send me the output  of the following command in terminal:

mdfind -name db.lif

For the the output is:
/Users/myusername/Library/Application Support/LEGO Company/LEGO Digital Designer/db.lif

Thanks