Custom LDD bricks and fixes

[Equilibrium]

1 minute ago, Stephan said:

How do I find these? And how can I fix that :P

I don't know about blender but 3D Max has a button for that xD (bottom right corner)

Removing them and resetting normals manualy fixes the problem.

You could try to select all polygons and move them away, then (if blender has it) switch to showing vertices and it could look like this:

Edited February 28, 2022 by Equilibrium

[Stephan]

14 minutes ago, Equilibrium said:

Removing them and resetting normals manualy fixes the problem.

Found it, but for me the stud remains odly shadowed and highlighted...

[suenkachun]

34 minutes ago, Stephan said:

Forgot about that. Fixed.

Thanks. Unfortunately, I still failed to properly insert the Plate 6x6 into my custom Elevators. Please use this file to check again and the Plate 6x6 should still not fit underneath the cabin even after the latest update. Unless I did something wrong here the collisions might need further changes.

[Stephan]

5 minutes ago, suenkachun said:

Unfortunately, I still failed to properly insert the Plate 6x6 into my custom Elevators.

Fixed.

[suenkachun]

41 minutes ago, Stephan said:

Fixed.

Works now, thanks!

Edited February 28, 2022 by suenkachun

[Kuramapika1]

2 hours ago, Stephan said:

I can't get it to work.

My apologize: if you still have the problem the correct option is to go to Object Menu and choose "Shade" smooth or flat; hope you solve the problem.

[Equilibrium]

19 hours ago, Stephan said:

Found it, but for me the stud remains odly shadowed and highlighted...

Tested this a bit more and turns out manually resetting normals was enough, these vertices don't even have to be removed (at least in 3D Max). So main issue is related to normals reset in blender (from what I read it is advised to remove loose vertices there for example).

Edited March 1, 2022 by Equilibrium

[SylvainLS]

Hi, the GitHub repository is a bit of a mess: some files are missing from pre-release but are in master (e.g. 9559.xml) but some files in master seem to be older versions 

 

[suenkachun]

1 hour ago, SylvainLS said:

Hi, the GitHub repository is a bit of a mess: some files are missing from pre-release but are in master (e.g. 9559.xml) but some files in master seem to be older versions 

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

[SylvainLS]

21 minutes ago, suenkachun said:

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

I strongly disagree: Parts that have been released should not move.  There may be exceptions, within a few days to a couple of weeks of the release, if the released version had obvious errors but one shouldn’t have to go back and change all one’s files every time there’s an update!

I hadn’t noticed that 69729 had been moved.  That is unacceptable.  69729 has been released in may 2021, 9 months ago, it should be corrected to be replaced as it was.  Period.

It’s even more of a problem for OFFICIAL parts that have been modified, like 29602.  The customized version should not prevent previous files to load.

 

[PicnicBasketSam]

1 hour ago, SylvainLS said:

I strongly disagree: Parts that have been released should not move.  There may be exceptions, within a few days to a couple of weeks of the release, if the released version had obvious errors but one shouldn’t have to go back and change all one’s files every time there’s an update!

I hadn’t noticed that 69729 had been moved.  That is unacceptable.  69729 has been released in may 2021, 9 months ago, it should be corrected to be replaced as it was.  Period.

It’s even more of a problem for OFFICIAL parts that have been modified, like 29602.  The customized version should not prevent previous files to load.

 

I just logged on here to note the same exact problem when trying to update the sets using the Stuntz ramp. Per my Brickset records I've got 78 files of official sets containing 69729. Absolutely no way in hell am I going to go back and change 78 broken files because of an arbitrary change to one (1) part! I tried to revert back to the 2021 version that's still hanging around on the development branch of the Github and that broke the part even further, so I've gone back to the current February 2022 version and I'm just not going to open any files that contain it, or create new ones, until this gets sorted out.

[Stephan]

I will look into this. This is indeed not what should happen. I will disable the Dropbox link until I get home to fix the aforementioned error of the 2x6 Tile.

I will also clean the Github repository and merge it with the Master.

(I already know what happened to the 2x6 Tile, so that should be an easy fix). 29602 will be reverted as well.

Edited March 2, 2022 by Stephan

[Stephan]

15 hours ago, Equilibrium said:

Tested this a bit more and turns out manually resetting normals was enough

Still couldn't get it to work, but now I used the previous stud model and the new cube/Brick model. That worked :)

7 hours ago, suenkachun said:

Part 78329 Plate 1×5

This is the exception. The part was available with a wrong PartID because NewElementary made a typo. That was a good reason to improve its position.

I agree with @SylvainLS that the position of released/original parts should not be changed unless there is a VERY good reason for it.

I am sorry for these inconveniences and will correct them this afternoon! I will also think of something to prevent this from happening in the future.

[Calabar]

Just a question about bricks that "moves" with the last update(s): are the updated bricks wrong or the previous ones (including the ones officially released with LDD)?

In the first case the obvious solution is to update the new bricks and fix the errors but, in the latter we should think over the idea to fix the issues once and for all, even if that could cause some issue with existing files because the alternative would be maintain an error for backward compatibility, and that don't seem a good way to proceed.

I suppose that it is not possible to easy fix programmatically the issue related to shifted position of a brick on existing lxf files, because the position varies depending on how the brick is placed and oriented. Or maybe it is possible to get this information from the lxfml? In this case it should not be too complex to create a script that will fix all these issues generating a new fixed lxf file.

[suenkachun]

2 hours ago, Stephan said:

I will look into this. This is indeed not what should happen. I will disable the Dropbox link until I get home to fix the aforementioned error of the 2x6 Tile.

I will also clean the Github repository and merge it with the Master.

(I already know what happened to the 2x6 Tile, so that should be an easy fix). 29602 will be reverted as well.

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.

[Stephan]

3 minutes ago, Calabar said:

Just a question about bricks that "moves" with the last update(s): are the updated bricks wrong or the previous ones (including the ones officially released with LDD)?

No, it depend on the brick: in the case of the dog the decoration surfaces were added by another contributor which changed the orientation of the part. This is harder to check beforehand for me because I get new files so I would have to check the contents of every file I get (which I already do though nowadays, but that takes time).

For the 2x6 Tile it's my own fault! I changed the orientation for private use and export benefits, but overwrote the Dropbox files with these when I updated the collision data... stupid mistake.

Most of the times the orientation isn't that important. It should be in-system and convenient to use. If there is original TLG data available (i.e. Unity Micro Game) we should adhere to that for consistency, but since LDD is now officially abandoned, that's not mandatory.

8 minutes ago, suenkachun said:

Hopefully, 69729 and 29602 can be restored by only fixing their positions but not losing their latest fixes regarding collisions and connectivity

Yes, they will, no matter what. They will continue to adhere to the latest fixes. Only their position/orientation will change.

I have the old 69729 xml file in the master repository of Github and 29602 (if it's the dog..., I can't check the number right now) should be in the original LDD folder.

[suenkachun]

1 hour ago, Stephan said:

Yes, they will, no matter what. They will continue to adhere to the latest fixes. Only their position/orientation will change.

I have the old 69729 xml file in the master repository of Github and 29602 (if it's the dog..., I can't check the number right now) should be in the original LDD folder.

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!

[SylvainLS]

5 hours ago, Stephan said:

29602 (if it's the dog...

Indeed it is.  My pet peeve 

 

5 hours ago, Calabar said:

Just a question about bricks that "moves" with the last update(s): are the updated bricks wrong or the previous ones (including the ones officially released with LDD)? […]

Position and orientation are arbitrary.  So they are never wrong in the absolute.  It’s changing them from version to version that’s relatively wrong.

Making a small program to modify the position & orientation of a part in an LXF file would be easy.  About as easy as doing it for an LDraw file (LDraw is simpler because it’s line oriented while LXF is Zipped XML but that’s the extent of the difference).

 

About spotting the changes:

I spot the changes more easily than Stephan when I prepare the update for ldraw.xml… but it can be a pain because it’s manual (get the list of parts that have been modified, add them one by one in an LDD file, connect them to parts that I know haven’t changed (to have a reference), export the file in LDraw and check there if they are all placed the same way as in LDD).  I was about to do it for the parts that are different between pre-release and master but, fortunalety for me because there were 80 of them, I saw the repo had other problems first.

The same kind of thing could be done in LDD: use the parts in an LXF, keep an image of how it looks, open the file after an update, check with the image… the only problem would be if new collisions are stricter: LDD would just remove the parts… but I think that’s another thing that shouldn’t happen (if you use the part in a “legal” build).

So, anyway, I should automatize that check because custom parts get udpated continuously… and it may also happen with LDraw files (I add them in ldraw.xml as soon as they appear in Unofficial but some are repositioned afterward, that’s why it’s Unofficial and not Official ).  Unit testing and all that… boring but necessary stuff… gah….

EDIT: @Stephan couldn’t you automatically be warned when the bounding box in the .xml file changes?

Edited March 2, 2022 by SylvainLS

[Stephan]

1 hour ago, SylvainLS said:

couldn’t you automatically be warned when the bounding box in the .xml file changes?

Right now I use a website that offers Text Compare. That helps a lot already (even though 90% of the current parts are added by myself).

[Stephan]

Added fix version 20220302: LINK.
 

Updated original parts:
• Updated decoration surface: 3297, 32523
• Updated collision data: 6190
• Updated assembly: 61927, 92693
• Reverted to original orientation: 29602

Updated custom parts:
• Updated category: 19086, 39369, 67139, 70644, 71708, 80286
• Updated collision data: 71708, 78267, 80267, 80268, 80286, 426502
• Updated outlines: 27448, 73109, 73507, 73682, 80267, 80268
• Updated 3D model: 80286, 426502
• Added collision data: 27448, 98107
• Updated connections: 62233, 426502
• Updated assembly: 40918, 43097
• Reverted to original orientation: 69729

Added missing files:
• 3297, 9488, 9489, 9559, 19859, 37091, 37092, 47157, 62271, 62273, 62274, 62275, 65834, 69729, 76110, 30680, 86876

Other notes:
• Added decoration: 301002
• Updated 2020NewPreColoredParts palette with: 1x 3010 [3010001]

 

This fix should address all of the afore mentioned missing files and other errors.

[SylvainLS]

Thanks for the quick update 

 

51 minutes ago, Stephan said:

Right now I use a website that offers Text Compare.

Well, I thought more about a script looking whether lines containing AABB were in the output of git diff   But that also suppose the boxes are correctly changed when the .g are modified and I guess it doesn’t tell readily if it’s a move/turn or a small change in the geometry.

[SylvainLS]

Okay, so I looked at the updated GitHub:

• THANKS for reverting 29602 and 69729 
• 19859: still missing the .g files
• 27448: has moved since last time (0.8cm in Z)
• 98107: can’t connect anything to the anti-studs
• 32476: can you check if it moved? It’s 0.4cm in X from where it was but the .dat has changed in 2021… but it was Official so such a move in LDraw shouldn’t be possible.

[Calabar]

9 hours ago, SylvainLS said:

Position and orientation are arbitrary.  So they are never wrong in the absolute.  It’s changing them from version to version that’s relatively wrong. 

I mean, if every brick has its pivot in the centre, a brick that rotates around its bottom-left edge should be considered "wrong", isn't it?
It would be useful to define some criteria about these kind of things.

Great to hear that an automatic tool would be enough easy to do, convert old lxf to new bricksets avoiding brick removal (as much as possible) would save a lot of the existing buildings.

[SylvainLS]

16 minutes ago, Calabar said:

I mean, if every brick has its pivot in the centre, a brick that rotates around its bottom-left edge should be considered "wrong", isn't it?

Maybe, if you want to be strict about it but:

• It doesn’t really change anything except add troubles (more below).
• Even for simpble bricks, there’s more than one “right.”  For instance, the 1x1 brick.  LDraw puts its 0,0,0 in the centre and at the base of the stud (top of the brick without the stud).  LDD puts it at the bottom of the brick (so 0.96cm lower than LDraw).  One part, two “rights”… or is it two “wrongs”? 
  For bigger bricks, LDraw chooses one corner stud while LDD still uses the centre.

I’m not sure LDraw has defined strict criteria (written them down I mean), I think it’s mostly history and common sense (place 0,0,0 at the most useful connection or hinging point).

For official LDD parts, I would say there are some criteria too (e.g. all brick- and plate-like parts have their origin at the centre of their base), and it’s mostly common sense too, so tranformation to/from LDraw are rather simple… but there’s some weird stuff, when LDraw and LDD really don’t agree on what’s right, or when TLG is its usual inconsistent self¹.

(¹ I don’t have the numbers for that but there are similar official LDD parts that are not oriented the same way (hoses of different length for instance).)

Hmm, a quick count (well, not so quick as I used the opportunity to clean up ldraw.xml a bit):

• 3956 transformations in ldraw.xml for official parts that have an LDraw equivalent (there’s some doublets for variants),
• 1830 contain a rotation,
• 1544 are on one axis only: 1511 by ±90° or 180°, 33 at other angles,
• 286 combine two or three rotations: 249 with ±90° or 180° only, 37 with one at another angle.
• Happily, there’s no LEGO logo on LDD parts to align with those on LDraw parts 

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

Anyway, even if you define criteria, there’s no need to change the old parts.  First, that would mean a lot of work, a lot of broken files (it would screw up ldraw.xml too or you’d need different versions), just to adhere to things users don’t see and don’t care about.  Second, if the old parts are edited, to add decors or refine the shape or whatever, the editor just needs to keep the same origin, rather than get and try to apply the list of criteria (which will necessary have holes or ambiguities which will be resolved differently by two different editors…).

As Stephan said, one criteria is: Keep TLG-sourced parts (Unity games) as TLG made them!  The another one is: Keep the released parts as they were!  If those two are followed, there’ll be no problem and no need for more work.

(And if people could also keep the position and orientation of imported LDraw models I would be very grateful  )

[Stephan]

11 hours ago, SylvainLS said:

32476: can you check if it moved? It’s 0.4cm in X from where it was but the .dat has changed in 2021… but it was Official so such a move in LDraw shouldn’t be possible.

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.

11 hours ago, SylvainLS said:

19859: still missing the .g files

Fixed! They were in the rar file so I could easily add them from my work pc.