bartvbl Posted October 17, 2012 Share Posted October 17, 2012 I've spent a couple of days to look at the format used by LDD to store its bricks. I had to debate a bit with myself if I wanted to release it, but I concluded that a viewer couldn't hurt. As of now, it only shows .g files that do not have .g1, .g2, etc files of the same name. You'll find that you can still view such parts, but they'll not show any geometry at all, or parts of it are missing. I'd recommend extracting the assets.lif, then the db.lif, then dump the .jar file in there, then run it. The file format itself is a custom format, as we found out, and clearly designed to be used with openGL, which is the renderer used by LDD. For most files, less than half of the .g file is used to describe the geometry. The rest of the file I have sortof mapped out, but haven't found out what it contains. I have considered posting the specification of the file format as far as I managed to map it out, but I'm a bit cautious to do so given that I can not oversee the implications of a brick geometry file converter with respect to lego's copyright enforcement. It's still reverse engineering either way. Controls: arrow keys: rotate X and Y axis Q/W: rotate Z axis A/Z: zoom in/out N/M: wireframe off/on Download Link Antillies, Alcom Isst, le717 and 2 others 5 Link to comment Share on other sites More sharing options...
le717 Posted October 18, 2012 Share Posted October 18, 2012 Take a look at the .xml files. They also contain brick geometry. Thanks for this bart! :D Link to comment Share on other sites More sharing options...
JrMasterModelBuilder Posted October 18, 2012 Share Posted October 18, 2012 Cool! I'm somewhat surprised there are studs in the geometry data. I know for a fact that the studs aren't loaded into OpenGL when completely covered be other bricks from inspecting models that we taken from 3DVia Printscreen. The file format itself is a custom format, as we found out, and clearly designed to be used with openGL, which is the renderer used by LDD. For most files, less than half of the .g file is used to describe the geometry. The rest of the file I have sortof mapped out, but haven't found out what it contains. I have considered posting the specification of the file format as far as I managed to map it out, but I'm a bit cautious to do so given that I can not oversee the implications of a brick geometry file converter with respect to lego's copyright enforcement. It's still reverse engineering either way. Mega Blocks doesn't seem to have any trouble copying bricks already, besides, these aren't the high-res models from the Easy Builder Tool, just the dumbed down version for LDD. Plus reverse engineering for interoperability with other programs is legal. Link to comment Share on other sites More sharing options...
lol username Posted October 18, 2012 Share Posted October 18, 2012 Glad to see you finally publicly releasing this! Take a look at the .xml files. They also contain brick geometry. Thanks for this bart! I think he's taken a look at pretty much every file format in all of LDD... :P Link to comment Share on other sites More sharing options...
bartvbl Posted October 18, 2012 Author Share Posted October 18, 2012 Take a look at the .xml files. They also contain brick geometry. Thanks for this bart! You're welcome! The XML files do not contain geometry data, though. They contain physics data. In short, when a computer has to perform a physics simulation, it can simply not check for collissions between every single triangle of a model. You'd get billions of comparisons, and if you're supposed to render at 60FPS, you simply haven't got the time. So instead every model has a bunch of bounding boxes instead. Boxes are very easy to do collission tests on, and reduce the overall number of tests that have to be performed. These collission box definitions are in the XML file, along with some other properties, like the bone structures of tubes and how the brick can interconnect with other bricks. lol username 1 Link to comment Share on other sites More sharing options...
le717 Posted October 18, 2012 Share Posted October 18, 2012 (edited) Take a look at this. I foun this a while back. It seems someone has already broken all the LD file formats... http://www.eurobrick...showtopic=65123 Then if the .xml files don't contian brick geometry, how did JMMB get the image by using the info from a xml? EDIT: NVM. I read our PM incorrectly. That image is from something else. EDIT 2: BTW, th .g files should also contain UV map, bart. ;) Edited October 18, 2012 by le717 Link to comment Share on other sites More sharing options...
JrMasterModelBuilder Posted October 18, 2012 Share Posted October 18, 2012 Perhaps this is just a problem with the 3D renderer, but I noticed some bricks aren't rendering properly. These are the ones I saw: 99061.g 99232.g 99253.g 99729.g 99778.g 99809.g 99930.g Link to comment Share on other sites More sharing options...
bartvbl Posted October 19, 2012 Author Share Posted October 19, 2012 Perhaps this is just a problem with the 3D renderer, but I noticed some bricks aren't rendering properly. These are the ones I saw: 99061.g 99232.g 99253.g 99729.g 99778.g 99809.g 99930.g It's indeed a problem with my renderer, caused by me making some changes before uploading it. Something with the rendering part was a bit s***ty I have fixed it for my own version. EDIT: updated the download link at the top, and added a bonus wireframe mode :) JrMasterModelBuilder 1 Link to comment Share on other sites More sharing options...
JrMasterModelBuilder Posted October 19, 2012 Share Posted October 19, 2012 Perhaps this is just a problem with the 3D renderer, but I noticed some bricks aren't rendering properly. These are the ones I saw: 99061.g 99232.g 99253.g 99729.g 99778.g 99809.g 99930.g It's indeed a problem with my renderer, caused by me making some changes before uploading it. Something with the rendering part was a bit s***ty I have fixed it for my own version. EDIT: updated the download link at the top, and added a bonus wireframe mode Working perfectly now! Link to comment Share on other sites More sharing options...
Tielc Posted December 18, 2013 Share Posted December 18, 2013 Bartvbl, I have written a few apps to open the LDRAW files in SolidWorks and Autodesk Inventor, and also re-written the common DATtoDXF to be significantly faster. I would like to add the ability to open the .g files from LDD as well, however when I look at the files in VS2012 I'm a little lost. They seem to be bitstream files to me, but I'm not familiar with working with them. I was curious of you would be willing to collaborate? I'm more than happy to share the .dll's I've created for DATReader, and SolidWorksDATWriter, InventorDATWriter and DXFDATWriter I've created. Link to comment Share on other sites More sharing options...
JrMasterModelBuilder Posted December 19, 2013 Share Posted December 19, 2013 Bartvbl, I have written a few apps to open the LDRAW files in SolidWorks and Autodesk Inventor, and also re-written the common DATtoDXF to be significantly faster. I would like to add the ability to open the .g files from LDD as well, however when I look at the files in VS2012 I'm a little lost. They seem to be bitstream files to me, but I'm not familiar with working with them. I was curious of you would be willing to collaborate? I'm more than happy to share the .dll's I've created for DATReader, and SolidWorksDATWriter, InventorDATWriter and DXFDATWriter I've created. For readig the binary .g files, you may wish to check out this topic: '?do=embed' frameborder='0' data-embedContent>> Link to comment Share on other sites More sharing options...
Recommended Posts