Custom LDD bricks and fixes

[Mobieus69]

Quick question.  Is there any way to tell which bricks have been removed when you get placement errors?  In really complex models, it can be almost impossible to find what was removed if it's not something large and noticeable.

[Stephan]

1 hour ago, Mobieus69 said:

Quick question.  Is there any way to tell which bricks have been removed when you get placement errors?  In really complex models, it can be almost impossible to find what was removed if it's not something large and noticeable.

Yes, there is. In the Lego Digital Designer folder, there is the UnplaceableBricksDump.lxfml. Open that in Notepad and search for "materialid = "21""

The exact phrase I don't know, but you'll see it when you open the file. Removed parts are colored Red in the text file.

[SylvainLS]

56 minutes ago, Stephan said:

This one didn't move. I replaced the original 3D model with the LDraw one since the original was wrong. But I placed the LDraw one on the exact same place.

Indeed, my mistake.  I thought it was a custom part, not a customized part, so I didn’t check in the official LDD.  Seems the error dates back from at least 2016…. *sigh*

 

5 minutes ago, Stephan said:

Open that in Notepad and search for "materialid = "21""

You can also use the Developer mode, deactivate the collision detection (Toggle Physics Test in the menu), and open that file to spot the red bricks.  Then open the .lxf and fix the parts before reactivating the collisions.

 

[Mobieus69]

Awesome, thanks for assist guys.

Am I missing something?  I see a lot of material id = 24  but no red text. and no "21".

[Stephan]

17 minutes ago, Mobieus69 said:

Awesome, thanks for assist guys.

Am I missing something?  I see a lot of material id = 24  but no red text. and no "21".

Sorry, the text is not red. But there should be lines with material id = 21.

[Mobieus69]

Hmmm, all of mine say "24" and if I open the file in ldd, I just get an all yellow version of my model sans the missing parts.  "24" is yellow.

Wait, nevermind.  Found them.

 

Thanks.

[suenkachun]

1 hour ago, Mobieus69 said:

Quick question.  Is there any way to tell which bricks have been removed when you get placement errors?  In really complex models, it can be almost impossible to find what was removed if it's not something large and noticeable.

The exact file path of this is in C:\Users\xxxxx\AppData\Roaming\LEGO Company\UnplaceableBricksDump.lxfml and handles one lxf file at a time. All normal Bricks will be in Bright Yellow (materials="24") while removed Bricks will be placed at the end of the list and in Bright Red (materials="21"). I usually search for “materials="21” without the " at the end in Notepad, just in case any Bricks involved are multi-colourable (e.g., materials="21,21"). Unfortunately, LDD no longer includes the Bright Red Bricks when importing the “UnplaceableBricksDump.lxfml” as these Bricks will continue to be removed, so their colours or exact positions will remain unknown. There is a way to speed up the process by comparing the lxfml files of the original file and the new file with Bricks removed, which helps to locate the Colours of the removed Bricks.

First, save a separate copy of the original lxf file and save a new copy of the same file after Bricks have been removed. Take the original lxf file such as “123.lxf” and rename it “123.zip”, unzip the file and it will contain both “IMAGE100.PNG” and “IMAGE100.LXFML”. Do the same for the new lxf file with Bricks removed such as “456.lxf” into “456.zip” and the unzipped “456.zip” will also contain both “IMAGE100.PNG” and “IMAGE100.LXFML”. You can then compare both “IMAGE100.LXFML” (such as using an online Text Compare tool) and the differences between the two files are the information of the removed Bricks. Another simple thing to do is check the “UnplaceableBricksDump.lxfml” to locate all “designID” of removed Bricks (such as designID="69729" materials="21") then search for these “designID” in both “IMAGE100.LXFML” to locate the extra ones in the original “IMAGE100.LXFML”. By checking the “materials="xxx"” value of the extra Brick lines in the original “IMAGE100.LXFML”, the colours of the removed Bricks can be retrieved one by one. By now you will have the following information: all Element IDs of removed Bricks and the individual Colours of each removed Brick, but their locations will remain unknown and you have to only rely on these two pieces of information to hopefully find out where the missing Bricks were originally placed. Remember to rename “123.lxf” back into “123.lxf” and “456.zip” back into “456.lxf” afterwards and they will both recover into normal LDD files (in this example “456.lxf” will no longer be needed as this is the new copy of the same file after Bricks have been removed). The second process is especially useful for larger models when the Brick count prevents locating faulty sections easily.

P.S., there is an old topic from a decade ago in 2012 on this forum with some more information on this issue (link below), might be outdated but still worth reading.

 

[Calabar]

4 hours ago, SylvainLS said:

So, depending on your point of view, LDraw and TLG are really/not so different 

Thanks for the explanation.

However I mean maintain a certain coherence inside the same system (LDD o LDRAW), not among the two systems.

Besides, I thought that some of these difference could influence the workflow using LDD. For example if the rotation point is different, a brick could rotate in a different way, but if now I don't understand wrong, it is not true.

Obviously a coherent system would make easier to convert LDD to LDRAW and vice-versa, but I suppose that once that existing bricks are managed, it is enough to follow the guidelines for new bricks. That means the some rule that contributors that creates custom bricks should follow are a good starting point. Did someone already written down these guidelines?

 

@suenkachun

Probably open the UnplaceableBricksDump.lxfml in developer mode is the easiest way to find the misplaced bricks.

Otherwise you could try another way:
- Place a single brick, easy to identify inside the lxfml, on the top-left corner of the scene
- Place another brick like the previous one outside the scene, for example next to the top-right corner.
- Open the lxfml file and find these two brick. Check their coordinates and write down the difference (in this case the horizontal value only).
- Apply these difference to all the misplaced bricks in a copy of your LXF file. In this way all the misplaced bricks will be detached from the model and placed aside the model itself.
- Fix the misplaced bricks, select them all together and re-place them inside the model. Maybe some trial and error are necessary.
- PS: it could be necessary to replace the whole model before starting, in order to orientate it in the right way (in relation to the grill).

I think it is easier done then said.

Edited March 3, 2022 by Calabar

[Stephan]

20 hours ago, SylvainLS said:

27448: has moved since last time (0.8cm in Z)

Not compared to the 2020 update on Github? Left the newest version, right the 2020 version. Both have the same position of the Custom2DField. I also have no removed parts from my LDD files (the ones I checked).

20 hours ago, SylvainLS said:

98107: can’t connect anything to the anti-studs

Fixed!

[SylvainLS]

27448:

Hmm, the transformation in ldraw.xml was committed on 2020-05-20.  I don’t have the history for 27448.xml in my LDD prior to 2020-12-14 (when I installed on a new computer…) but the bounding box hasn’t changed since.  So if something happened on my computer, it’s between these dates.

On GitHub, the first version of the file is from 2020-08-03.  It’s the same as my December version.

So it’s either an old error or a change I missed between May and August.

Well, I’ll change the faulty transformation….

6 hours ago, Calabar said:

However I mean maintain a certain coherence inside the same system (LDD o LDRAW), not among the two systems.

With the difference between the two, I meant to examplify that two people could disagree on what is “right” and therefore do things differently, even in the case of criteria.  They would both still be “right” because there will always be holes (new unforeseen parts) or ambiguities in the criteria.  (It sure would simplify ldraw.xml if both LDraww and LDD agreed but it was not the point.)

That doesn’t mean there should be no criteria, but having very detailled ones and being very strict about them is not really useful in the context of LDD (it is more useful for LDraw).

[suenkachun]

On 3/3/2022 at 11:48 PM, Stephan said:

Fixed!

Collision data for Part 6111 Brick 1×10 were last updated in LDD Development Version 20210501 (July 10, 2021). I was recently checking my old House/Hotel project since the latest LDD updates (20220226 and 20220302) and five copies of this Brick were removed due to being placed incorrectly: three were removed from the first file which includes the Ground Floor/First Floor and two were removed from the second file which includes the two Roof Floors. I managed to reinsert one from the first file and reinsert both in the second file, but the other two in the first file will still always be removed after multiple fix attempts. The issue here is that all Bricks can be inserted and saved properly, but once the file is reopened selected 6111 will be removed. Shown below are the two locations in the first file where the two 6111 in Bright Red will be removed (in both cases, there is another 6111 on top and a layer of White Plates underneath, the first location has two stacked Brick 1×16 on either side while the second location has two stacked Brick 1×16 on the right side and a Brick 1×2×2 on the left side, there are also regular Bricks in front and behind). For now, I have dragged all nearby Bricks surrounding the two removed 6111 away from the main build and everything currently saves properly without the two 6111. I’m guessing that collisions for the Brick 1×10 might be a tiny bit too large again and requires further adjustments. Hopefully, this will be the only solution required and no other Bricks need to be modified. Thanks in advance!

[Equilibrium]

@suenkachun Heh, plus its side collisions are turned inside out (negative scaling) so they are not working.

[suenkachun]

1 minute ago, Equilibrium said:

@suenkachun Heh, plus its side collisions are turned inside out (negative scaling) so they are not working.

Thanks, so that’s the cause of the issues, I guess I’ll wait till another global update before reinserting the two missing 6111 and place all relevant Bricks aside for now.

[Equilibrium]

@suenkachun I'm not sure if it is the cause of your particular issue but its an error that keeps popping up. I've searched through files and it seems there are at least 20 bricks affected. I'll look into fixing all of them tomorrow.

[suenkachun]

1 minute ago, Equilibrium said:

@suenkachun I'm not sure if it is the cause of your particular issue but its an error that keeps popping up. I've searched through files and it seems there are at least 20 bricks affected. I'll look into fixing all of them tomorrow.

I do think that this seems to be the cause on my end too, as any Bricks in front or behind don’t seem to affect the removed 6111. Hopefully, a general fix can be issued for everyone affected and thanks in advance!

[BrokenEye]

Alright, I just finished the first batch of remade Power Shield decals. These are all the red Nexo Knights shields and all the miscellaneous non-Nexo shields. For the most part, the backgrounds and borders had to be remade from scratch, but the artwork was entirely salvageable.

Spoiler

this one takes up slightly more of the shield face than the standard-sized decals

 

[Stephan]

12 hours ago, Equilibrium said:

I'm not sure if it is the cause of your particular issue but its an error that keeps popping up. I've searched through files and it seems there are at least 20 bricks affected. I'll look into fixing all of them tomorrow

I didn't know that negatively scaled collisions didn't work. I just thought their coordinates were Inverted. Good to know!

[Equilibrium]

@Stephan Yea, try to stick a bar into narrower side of 6111 brick. It will go through. Anyway I replaced negative signs inside 55 files. Collisions itself will now work but there still might be issues if they were made too big or something.

@suenkachun Try now, I'm curious if it was the case.

 

Download Link

 

[suenkachun]

5 hours ago, Equilibrium said:

@Stephan Yea, try to stick a bar into narrower side of 6111 brick. It will go through. Anyway I replaced negative signs inside 55 files. Collisions itself will now work but there still might be issues if they were made too big or something.

@suenkachun Try now, I'm curious if it was the case.

 

Download Link

 

Thanks for the fixes, I just got home and checked, this was indeed the case. After updating LDD with the latest 55 files, my two original House/Hotel model lxf files can now be opened perfectly without any glitches once again (fortunately I still had them backed up somewhere). I guess I can now revert to these two old files (just in case new errors will appear in the updated files) and continue updating them (since the Brick 1x10 error appeared, I continued to update other parts of the files and the same changes will now have to be redone in the two old files).

6 hours ago, Stephan said:

I didn't know that negatively scaled collisions didn't work. I just thought their coordinates were Inverted. Good to know!

Please include the 55 updated files in a future LDD release after further checking the collision boxes, or at least make them available on GitHub for now so that others won’t experience similar issues, I can confirm that the fixes are working fine on my end.

[Equilibrium]

@suenkachun That's nice, I'm glad it helped

[Mobieus69]

Anyone else getting a damaged or unknown notification when trying to open the rar file with the latest fixes from @Equilibrium?

[dz9r]

Hi, just installed the latest update and the 2x3 26603 tile isn't working for me,  not sure if its just me. Also have the these  parts been added yet, 

33909 and 26604, 32952. 

[SylvainLS]

9 minutes ago, dz9r said:

Hi, just installed the latest update and the 2x3 26603 tile isn't working for me,  not sure if its just me. Also have the these  parts been added yet, 

33909 and 26604, 32952. 

33909, 26604 & 32952 are in Official LDD (since, respectively, Jan 2018, Feb 2017 & Jan 2018).

Check that you have LDD 4.3.11 with Brick version 2670 (menu Help | About).  If not, look earlier in this thread for one of the dozen times we explained 4.3.12 is crap and how to install the correct version.

[dz9r]

18 minutes ago, SylvainLS said:

33909, 26604 & 32952 are in Official LDD (since, respectively, Jan 2018, Feb 2017 & Jan 2018).

Check that you have LDD 4.3.11 with Brick version 2670 (menu Help | About).  If not, look earlier in this thread for one of the dozen times we explained 4.3.12 is crap and how to install the correct version.

I installed 4.3.11 but it was missing more than half of the bricks so I installed 4.2.10. I'll have another look in the thread to see if I can 11 to work properly. Thanks.

[SylvainLS]

If it was missing bricks, then it was crappy 4.3.12.