M2m

I blatantly (manually) copied this technique from Lego_nuts (he did it in Mecabricks) and I found it super impressive. For anyone who needs this feel free to take this LDD file (https://github.com/sttng/LDD/blob/master/assets/medieval_wall.lxf)

Engineers saying: “Delivered is better then perfect”

Don’t quit after 1 negative comment. I like your parts and make good use of them

I can understand your look for quality but i would also say if you don’t like those bricks you can easily just skip them ? While I surely would be happy to have 100% perfection (which even LEGO doesn’t deliver) I rather take those and knowing the disadvantage then nothing. As the adding of bricks is not straight forward I expect everyone who does it to know about the repercussions - possibly a new version of bricks will have impacts to my builds. Just my opinion.

Yes HDRI is a great way for getting really good results. I'd recommend also to use deep color output (such as exr) it gives you additional 'bandwidth' for later color and exposure correction.

@Equilibrium Thanks for giving it a try. I'm honestly out of ideas. Anyway its open source so maybe a more gifted programmer picks it up.

Thanks for the support and suggestions. I replaced the string + concats with .join([a,b,c,...]) https://github.com/sttng/LDD/blob/master/LIFCreator.py It takes on my Macbook booted into Win10 now around 800secs (for db folder including all the new parts). On the other hand this drastically decreases the performance on macOS :( I guess this part was done by jester. Why don't you replace it with 2x 24201 for the time being ?

Assuming you used my LIFCreator.py tool it could also be there was a bug and the lif file wasn’t created correctly and prevented loading the 1st time you tried.

Maybe its reading the palette from Asssets.lif (or Assets folder in case you extracted assets.lif ?)

Thanks for the hints. I get that it seems windows python is slow on long strings (and as I build the whole lif file in memory I run into the same problem), but I didn't see a solution :( Anyway how did you get your bricks working ?

Having 8GiB of RAM. As said it it runs in 25secs for me (with all new parts)

Yes. True. Can add that add the start-up and user have to confirm with <Enter>. Where you able to run it on Linux after all ?

Maybe you have to add the material id to the MaterialSelector.xml which is part of the LDDExtended.lif file (on MacOS in Folder /Users/username/Library/Application\ Support/LEGO\ Company/LEGO\ Digital\ Designer/Palettes/ ) ?

How did you create db.lif ?

Its all a big mystery to me. For me I can pack a folder with LIFCreator.py and then unpack the resulting file with LIFExtractor.py in Windows 10:

I think on windows you should use the \ (back slash). On Linux, macOS you should use the / So for Windows: python LIFCreator.py db\ I'm still trying to figure out why the script is so slow on Windows :(

Hmmm... might be. Then on the other hand blueprint is working for me - just not with the ALL the new parts. But some DO work. So I'm more expecting blueprint has problems in loading parts then the lif file. I'm still surprised the lack of speed for the conversion as it honestly only takes 20-30sec for me.

I made some more performance related tweaks, so the creation of lif files should be faster. But I don't think it'll help with Blueprint. I checked now all other applications I know which rely on db.lif (LDD, Bluerenderl, busufl) and all of them accept the packaged db.lif file. Below a busufl render - so for blueprint I think it is more about how it (not) handles the new parts it self and not about the lif file.

Did blueprint work with the original db.lif file for you ? As written before I got blueprint working with some new parts but also not all. With quite some of the new parts it simply crashed. So I expect these problems most likely are related to the way blueprint handles parts and the new parts may be just so slightly different that blueprint gets confused (LDD in all definitly is just the more professional software and just is more resilient to data not 100% 'compliant').

Im still using LDD because I am so used to its workflow. Thanks to the effort there are also new (new old) parts available. I personally think Mecabricks also looks really cool, both from UI and rendering point of view. Still I'm a fan of LDD 'parts snapping'.

Ok I made a couple of changes and for me its working on macOS Python 2.7 and Win10 Python 3.8 (current). https://raw.githubusercontent.com/sttng/LDD/master/LIFCreator.py I first installed Python 3.8.3 on Windows 10 (with the standard options and selected to have python added to my path) Then I start the Command Line (cmd.exe) and go to the "Downloads" folder (cd Downloads) where I have the DB folder and the LIFCreator.py script as shown below in my Win10 VM (Python installer is also still there) To confirm python is working i type python and after i press CTRL-Z to exit the python environment: Next I start the LIFCreator program with python LIFCreator.py db\ I get a couple of outputs and hit <ENTER> to confirm all (Choosen directory: db, Will create: db.lif) and then it will start and list all files and sizes it processes. On my VM this is super sloooooowwwww. On my mac it takes approx 30sec. The last file to be processed is pes.xml - after this is will write the lif file: Done :) Comparison on my Mac (not VM) - just 21secs

Yeah surely - but I guess using zip (without passwords) and adding a shasum.txt file containing all the sha-1 values of the included ldraw files would be much more user friendly *rant finished

If you want to hash then there are better ways (SHA) to do. You should definitely use hash functions and hash values, if you want to hash. Also if you want to have error correction one should look into reed-solomon, hamming codes, crc and this stuff. Just using zip is a bad shortcut, as because of the encryption (and non-public password) the risk of data loss for the acutal user is higher.

I really suggest to update to Win10. Win 8 is really not up to it!

Yeah I pushed the writing to the end of the program (so the filehandle isn't open forever). What Windows are you using ? I might install Win in VM. Seems to be more fruitful... Anyway I just pushed another change. Maybe you can have a look where it stops.