suenkachun

Thanks for the info, will test these out in a bit. BTW, I think Plate 1×2 should be Part 3023 while Part 3032 is actually Plate 4×6.

Hoping that someone here can provide the accurate UV Mappings with Dimensions for three recently added Decoratable Brick surfaces: Part 3024 Plate 1×1 vertical surface, Part 3023 Plate 1×2 longer vertical surface and Part 3623 Plate 1×3 or Part 34103 Plate 1×3 W/ 2 Knobs longer vertical surface (these two should be identical), as I tried several times to produce custom Decorations for these three surfaces but none of the results displayed correctly. From new Decoration image files provided in recent LDD updates, the only information available is: Decorations for Plate 1×1 equal a regular 1:2 rectangle (e.g., Decoration 34452), Decorations for Plate 1×2 equal 1024 Pixels times 236 Pixels which can also be used by Plate 1×3 (Decoration 69172), while Decorations for Plate 1×3 W/ 2 Knobs (thus Plate 1×3 too) equal 1024 Pixels times 207 Pixels (Decoration 76901). What I usually do is start with the actual dimensions of the surface (e.g., Plate 1×1 vertical surface 0.3 cm times 0.75 cm) then scale the decoration up till the shorter side equals 1024 Pixels, and the longer side is compressed into 1024 Pixels to form a maximum square; if a regular 1:2, 1:4 or 1:8 rectangle is involved I always try to stick with them, but none of the three surfaces mentioned actually fit into these rectangles so I need to know how much compression is involved for each surface. Thanks in advance to anyone who can assist with this!

The latest LEGO Colour “371 Warm Tan” (HEX: #CCA373, converts to RGB: 204/163/115) was recently revealed on Ryan Howerter’s list after “370 Medium Brown” (HEX: #755945, converts to RGB: 117/89/69). Their German Names are “369 Mittel Braun” and 371 “Warmes Hellbraun” (equivalent to Light Brown, I translated the phrase “Tan Colour” via a few different sources and they all produced “Hellbraun” for “Tan”, correct me if I’m wrong) respectively. Both Colours should be added in the next LDD update so stay tuned, if interested import these Colour values directly into LDD ahead of time (don’t forget to assign both English and German Names for completeness or just include English for basic use) and enable them for use (methods have already been mentioned several times in this topic so will be skipped here).

If Hollow Studs refer to the Round Brick 1×1 and the Nose Cones (can also apply to Bricks like 85861/86996/35459/4733/etc. which all have at least one hollow stud), I think the issue originates from Part 32828 as try attaching a clip to it and these will also collide with that tiny bit sticking out. Just checked Bricks with Cross and 32828 should only fit when placed at 0°, 90°, 180 and -90° at the furthest position but not at other angles which it can at the moment, as the sticking out bit will fit into the four extended spaces of the cross but will collide with the solid spaces around the cross.

My bad, 50946 does fit as well, was just a construction error of mine as I had to use the help of a video guide on YouTube before the instructions were finally available digitally not long ago. Good to know about the Part differences too. In this case, 10885 can be added at a later date as there are more important things to prioritise at the moment.

Thanks, I suppose the other part is 79194 then, perhaps this part should also be pre-aligned properly when added into LDD in the future. Speaking of similar Bricks and Knobs, I just remembered this old question: currently Part 85861 Pl.Round 1×1 W. Throughg. Hole (2009-2019) is in LDD but seemed to be replaced by Part 28626 (2014-2022) in recent years. I can’t tell the difference between these two just by looking at their official images (shown below), but should 28626 be added if there is a significant difference between the two? Left is the official image of 85861 in White and right is the official image of 28626 in White. BEW, any chance to see the new Radiator element 10885 added soon, as the old 50946 doesn’t fit when trying to build Set 40532 Vintage Taxi.

Just tried to attach Part 25893 3.2 Shaft w/knob to a clip (vertical holders, 6019/61252/60476) and discovered that the clip cannot be aligned to the middle of the shaft perfectly. As shown above, the two builds on the left demonstrate that the clip will always be misaligned slightly to either side. The third build on the right used an assembly of regular Bricks which forced the clip to be placed in the middle, but the clip is not attached being slightly away from the shaft and attempting to move the clip will cause the joining Brick 1×1 at the back to be misaligned. If the process is reversed so that the 25893 is attached to the clip, it will end up colliding with nearby Bricks as shown below (in this example with the Transparent Brick 1×3 on the left, can also collide with the Brick 1×3 on the right if moved once towards this side). With the current knowledge of how Bricks in LDD work, will it be possible to adjust 25893 so that any clip can attach to its middle perfectly which also avoids other collision issues? Tried the scaffolding tricks but nothing has worked so far as the attachments are automatic and hard to adjust manually. Thanks in advance to anyone who can assist with this.

Thanks for the great work as usual! I checked the Bricks in the screenshot after the latest update again and here’s the latest information. Within the screenshot, only 45800, 45801 and 98107 have been fully fixed, but for 98107 nothing can be connected to the anti-studs. Ignoring 3900, the rest of the Bricks all need updated collisions for future LDD updates. 35646 (Crystal) and 51270 (Pumpkin) should be easier to fix as they only collide with other Bricks on the edges, while 25195 is only missing collision at the top part of the round tube and the Plate 2×6 section at the base works fine, also easy to fix. In addition, I just found another Brick needing to be fixed. Part 32828 Plate 1×1 Round W/Horizontal 3.2 Shaft has a tiny bit sticking out underneath the Round Plate 1×1 (circled in Blue above), and at the moment this tiny bit can collide with other Bricks beneath it if inserted too deep. There is no rush at all in updating these Bricks as everything does take time to complete, just wanted to make a progress check and post a reminder. For now, anyone using most of the Bricks in the screenshot will expect issues needing to be fixed so please place them carefully to avoid being removed in the future. Thanks again!

The following visual example will further demonstrate that a “Bit Depth” of 32 is necessary for LDD Decorations. The above image is a simple set of Bright Yellow Road Markings to be used on a Part 87079 Flat Tile 2×4, with Dimensions 512 Pixels times 1024 Pixels and “Bit Depth” 8. The second image above is the same set of Bright Yellow Road Markings to be used on a Part 87079 Flat Tile 2×4, with Dimensions 512 Pixels times 1024 Pixels and “Bit Depth” 32. Insert both into LDD and the first image on the left will not render correctly and end up being just a Black surface, while the second image will render correctly. As a result, having a “Bit Depth” of 32 will always ensure that more Colour information is included in the image coding and everything will be displayed correctly in LDD, even when the Decoration only uses one Colour.

Thanks for the info, did not know that before!

I just checked again using my Windows 11 Laptop. When browsing the Decorations folder, right-click any PNG image and open its Image Properties. Take 300901, which was my contribution earlier, open its Image Properties and navigate to the third Tab Details. Underneath the three lines regarding Image Dimensions, there should be a line saying “Bit Depth” 32. I also did a quick Google search below and the relevant information can be seen clearly via images. https://www.google.com.hk/search?q=image+properties+bit+depth&tbm=isch&ved=2ahUKEwi_uNKYvL72AhWsxosBHWuxAMoQ2-cCegQIABAA&oq=image+properties+bit+depth&gs_lcp=CgNpbWcQAzoECAAQEzoICAAQBRAeEBM6CAgAEAgQHhATOgUIABCABDoECAAQHjoGCAAQHhATOgYIABAIEB5QkQtYhjRg7TVoAHAAeACAAXKIAbAOkgEEMjAuMpgBAKABAaoBC2d3cy13aXotaW1nwAEB&sclient=img&ei=sHcrYr-gLayNr7wP6-KC0Aw&bih=676&biw=1536 Simply speaking, this value can usually be 8, 16, 24 or 32 from personal experience, and those which do not equal 32 may end up having display issues in LDD.

Using my own personal experience, I once tried inserting a Decoration with only text in one plain colour (LEGO White) and a Transparent background, then they ended up with display issues in LDD (I recall it only having a “Bit Depth” of 8). Not sure why this is the case, but I always stick with the highest “Bit Depth” of 32 to ensure that everything can be displayed correctly error-free. I will look into this and possibly post an example a bit later. P.S., a “Bit Depth” of 32 is actually taken from the original LDD Decorations compressed into 128 Pixels times 128 Pixels Squares, so I stuck with this always.

Thanks to the latest information available regarding Part 3062 Round Brick 1×1, I have just updated the PDF Guide (now four pages) which can be found here. The information within the Guide can help everyone design the most accurate Decoration PNG images of common regular Bricks for use in LDD, whether they are your custom creations or official images to be submitted here for future LDD updates. The information below highlights irregular Decorations and Decorations regarding Part 63864 Flat Tile 1×3, Part 69729 Tile 2×6 And Part 3062 Round Brick 1×1. Thanks in advance and I hope that this will be useful. All irregular Decorations (including regular rectangles 2×3 and 1×6): make the shorter side 1024 Pixels then compress the longer side into 1024 Pixels to form a maximum Square, check PDF for exact values. Part 63864 Flat Tile 1×3 And Part 69729 Tile 2×6: Create Decoration as 1024 Pixels times 3072 Pixels, then scale down to 338 Pixels times 1014 Pixels. Compress 1014 Pixels into 1012 Pixels (two Pixels less) without changing the other side or cropping the image, unless the last Pixel on either side only contains a single plain Colour which will only be cut off if not compressed. Align the latest Decoration (338 Pixels times 1014/1012 Pixels) to the centre of a Blank or Transparent 1024 Pixels times 1024 Pixels Square and output as PNG for use. Part 3062 Round Brick 1×1: Create Decoration within a 1024 Pixels times 960 Pixels Rectangle, then align Rectangle to the centre of a Blank or Transparent 1024 Pixels times 1024 Pixels Square and output as PNG for use. If the Decoration is created as an actual Sticker to be printed and used in real life (therefore using the standard of 1 Brick Width=0.75 cm and 1 Brick Height=0.9 cm), the PDF can help scale up the Decoration into the best LDD standards. Some Bricks will end up in the same enlarged size despite the different original Brick sizes, as their base ratios are the same (e.g., Decorations for Brick 1×2 And Brick 2×2 Front Vertical Surface/Roof Tile 1×2×2/3, Abs Main Slope/Roof Tile 3×4/25° Main Slope/Brick 2×6×3 Front Vertical Surface will all end up being 1024 Pixels times 1706.66667 Pixels, to be compressed into a maximum Square).

Understood, thanks for the clarifications so far.

Thanks for the image! From what I’ve read so far, I guess that as long as the Decoration itself fits within the two Green lines then it can be displayed correctly, while the extra spaces on either side can be kept Transparent unless there is a specific reason to add the black background layer underneath which I haven’t fully understood yet.

With the update finally released and working fully, I guess that there should be more time to look into this now. let me also rephrase my original post a bit. To make things simple, the main question here is: is there a specific UV map designed for Decorations used on Part 3062 Round Brick 1×1, if so can it be shared so that custom Decoration used on this Brick can be more accurate and everyone can know the standard to follow when contributing future official Decorations for this Brick? What I used to do is assign a square 1024 Pixels times 1024 Pixels Decoration directly onto this surface, but it seems to be stretched out on either side and is therefore not accurate. I did notice that Decoration 13450 “Ü” was modified into Decoration 306201 which compressed the letter a bit so it can be shown properly on the Round Brick, which further proves that my old method was slightly inaccurate. The difficulty with this part as mentioned before is that a Decoration on 3062 wraps around the Brick on one side, therefore the Decoration borders are hard to figure out unless there is an accurate UV mapping available. Thanks in advance!

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). 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.

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!

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.

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!

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.

No problem, will wait till the latest update files are available before I update my own files in LDD again, thanks for the continued efforts as usual!

Thanks for the replies. Fortunately, I did back up all my original old files in my external hard disc which was what I used on my desktop computer to compare with the new files, so all I need to do next is revert some of my templates back to the old version then replace all updated files with their old version, which is super easy. Hopefully, 69729 and 29602 can be restored by only fixing their positions but not losing their latest fixes regarding collisions and connectivity.

This seems to be the cause of my issues when I first updated LDD via GitHub, which were then solved by installing the Dropbox version (since the last fix). Therefore, I’d suggest everyone to use the Dropbox version for now until the issues on GitHub are looked into further. A friendly reminder: After updating LDD an expected behaviour is certain updated Bricks may be altered in existing models saved before the update, not an issue to be fixed from the programme level and each file must be checked individually to fix all issues. This first happened with Part 78329 Plate 1×5 a while back which was shifted to either side by two Bricks (if I remember correctly), also causing some nearby Bricks to be removed. For the latest two updates (Development Version 20220226 and Fix Version 20220228), the first updates for Part 69729 Tile 2×6 accidentally caused its selection box to be misaligned by three Bricks, which was then corrected. However, the second fix led to all existing Tile 2x6 to be shifted by three Bricks, sometimes causing themselves to be removed and often resulting in certain nearby Bricks removed as well. Depending on the total number of each element involved being used, the process to reposition all affected Bricks and add back all removed Bricks may take a while. Personally, fixing all issues regarding Plate 1×5 took only a few hours as I had only previously used less than 50 of this element at the time. However, for Tile 2×6 I have currently used at least a few thousand in my existing models, spread across at least 42 files and doesn’t even include the various templates I have saved in all three modes of LDD. Took me around six hours to finish fixing the first 6 files plus all templates, and I expect to complete this process at least a week later. I first installed the previous version of LDD (basic plus Development Version 20210828) on the old Desktop computer at home, then I open each old file one by one and compare with each messed up new file on my Laptop to fix all issues. For templates, I open a blank file and insert all relevant templates on both devices to compare and fix all issues then save the fixed templates on the Laptop again. Although this manual process will take a while to complete, such a small sacrifice is always totally worth it for a global release of the updated Tile 2×6 (and Plate 1×5 if I may say).

Works now, thanks!