195 replies to this topic

[Superkalle]

hrontos, on 08 August 2011 - 01:34 PM, said:

LDD support different views of model in building instruction. This means, that for every BI step, LDD generates also camera position and stores this info in the LXF file. So every step can use different view of the model.

Good point.

Actually, improved BI is high on my list too. One thing would be if the BI algorithm could utilize groups that the users have created.

PS: To create custom views during creation of BI, I normally rotate the BI-view (yes you can do that) to a favored position, and then Ctrl-K. I then get a number of nice instructions steps that I paste into a Word-document. The only problem is that I miss out on the small thumbnails showing the needed parts per step.

[hrontos]

Superkalle, on 08 August 2011 - 02:38 PM, said:

Good point.

Actually, improved BI is high on my list too. One thing would be if the BI algorithm could utilize groups that the users have created.

PS: To create custom views during creation of BI, I normally rotate the BI-view (yes you can do that) to a favored position, and then Ctrl-K. I then get a number of nice instructions steps that I paste into a Word-document. The only problem is that I miss out on the small thumbnails showing the needed parts per step.

Actually I am working on an XSLT transformation, that will transform the groups and subgroups into steps and substeps, since I do not expect to have solution for manual instruction from the TLG very soon and this one is really simple, however it has several drawbacks:
1. the view point. XSLT cannot determine proper camera view. Thats why I would be happy, if LDD could save also the modified view into BIs.
2. Modification of model results in deleted BIs. They can be regenerated by the XLST again, but if the LDD will save those BI camera views, these will not be preserved. The only solution would be to backup the model with proper views. And use the backup version of BIs during the XSLT processing.

I have read your BI recomendations with Word document and they are really nice instructions.

The Ctrl+K solution works nicely also with the original instructions, simply replace the LDD BIs image with your screenshot and the better view will appear in the HTML. Since LDD names BIs files by step numbers, and also screenshots are numbered it should be quite easy to just go through instructions, generate proper sceenshot for each step and then use some multirename tool to rename files with screenshots according to BI conventions.

But all these approaches require a distribution of huge set of files, unlike the possibility to Save the modified BI view in LDD reduces the distibution to LXF file itself. That's why I consider this simple feature as important one. I am not asking the TLG for animations or other nice, but dificult to implement solutions with very limited target audience.

I will share "the groups to BIs transformation" solution with step by step how to use it as soon as it will be ready.
I have build the 8265 set in LDD exactly according to original BIs and groupped it and subgroupped so that "the groups to BIs transformation" should produce almost the same steps.

HTML instructions can be also processed by XSLT to get them to some other, more paginated or differently navigated format. But this transformation will come later.

[Calabar]

I think there are some things useful to improve instruction:
- generate using grups and subroups
- automatically choose the best point of view: the best is the one where the hidden area of added bricks and the bricks where they connect is minimal.
  There could be 4 or 8 points of view, one of which is the main point of View (chosen if there is one than more "best angles" available).
It is necessary a bit of tolerance to avoid continuous change of angle.
The change of angles have to be reported on the instructions.
- The chance to ask user to modify step by step the point of view, and store it in the lxf file.

[pbk420]

There are certain pieces mostly minifig headgear that id like to see fixed. Take this example the Stormtrooper helmet, when you change the color of it the whole helmet changes color. They need to fix that and those similiar to it that will allow them to be multi-colored like a few of the others are. They need to be able to have a white outside with black eyes.

[Calabar]

My wishlist updated.

[Aanchir]

pbk420, on 11 August 2011 - 11:03 PM, said:

There are certain pieces mostly minifig headgear that id like to see fixed. Take this example the Stormtrooper helmet, when you change the color of it the whole helmet changes color. They need to fix that and those similiar to it that will allow them to be multi-colored like a few of the others are. They need to be able to have a white outside with black eyes.

To be fair, the Stormtrooper helmet shouldn't be able to be colored multiple colors with the paint bucket tool because it is neither a blended part nor a part with multiple pre-assembled components. There are single-piece, non-blended parts that can be dual-colored-- a good example is the 2x2 dome. However, this is actually a glitch in the programming, not a deliberate feature, and is caused by certain decoration surfaces being erroneously interpreted as surfaces for the paint bucket tool.

So the real solution to this problem isn't to include multiple coloring surfaces, but rather to add decoration surfaces and to add the decoration for that part to the program.

[Shroud]

Still on my wish list:

1. Mirror selected objects

2. Wire frame view for use with bigger projects

3. Use your computers GPU? don't think it does right now

4. Proper technic interactivity

I know some of this has been mentioned, so just in case its forgotten by now :P

[Jay Sathe]

I would love more export functions to common 3D formats (.3ds, .obj, etc.). It took me almost a week of trying different CAD programs and file-type converters before I finally got myself a .3ds of the 8402 Sports Car.

Minifig customization would be great, but I think a more organized way of looking through prints (and subsequently more prints) would be better at least for me.

Animation or saved camera angles would also be really great to add in, as would a physics simulator, but those are seriously longshot wishes.

[nemo]

I'd like all the basic UI errors to be fixed.

eg, when Ctrl-clicking to add bricks to a selection, who could argue that just missing the required brick and clicking in open space could possibly be legitimately interpreted as a desire to lose the entire selection? Whilst still holding Ctrl? Basic stuff.

Lassoo selection should use the projected brick outline (or a convex hull of the projection) NOT the bounding box to decide what is inside the lassoo rectangle. Ctrl-lassoo should obviously not clear the current selection first.

As I've reported elsewhere, the colour palettes must NOT be fixed size as they don't fit on a netbook screen (1024x600).

The other thing I'd like is some more sensible data management. The massive binary blob of XML files that is the 400MB .lif (ignoring the oxymoronic construction itself!) is unnecessarily inefficient and causes a huge amount of delay. If you are going to use a binary format, then build in an appropriate index at the start so the whole massive file doesn't have to be scanned!

No, I can't ignore the oxymoron: If you're going to have a binary file, don't inflate it and slow it down by filling it with now-useless XML, use a binary format. Or, if you're going to inefficiently define stuff in XML, then don't hide it in an uneditable binary blob!

Do "welcome screen" thumbnail loading and rendering in another thread - stalling the UI thread so the user can't click the 'New' button until LDD has loaded and rendered a thumbnail of a previous model is yet more poor engineering.

I know LDD is free but it has Lego's name on it, and that means the same degree of quality and attention to detail should apply to its engineering as to the rest of Lego's products. I find the LDD software frustrating, slow and frequently disappointing.

[Aanchir]

nemo, on 17 August 2011 - 06:56 PM, said:

I'd like all the basic UI errors to be fixed.

eg, when Ctrl-clicking to add bricks to a selection, who could argue that just missing the required brick and clicking in open space could possibly be legitimately interpreted as a desire to lose the entire selection? Whilst still holding Ctrl? Basic stuff.

Lassoo selection should use the projected brick outline (or a convex hull of the projection) NOT the bounding box to decide what is inside the lassoo rectangle. Ctrl-lassoo should obviously not clear the current selection first.

As I've reported elsewhere, the colour palettes must NOT be fixed size as they don't fit on a netbook screen (1024x600).

The other thing I'd like is some more sensible data management. The massive binary blob of XML files that is the 400MB .lif (ignoring the oxymoronic construction itself!) is unnecessarily inefficient and causes a huge amount of delay. If you are going to use a binary format, then build in an appropriate index at the start so the whole massive file doesn't have to be scanned!

No, I can't ignore the oxymoron: If you're going to have a binary file, don't inflate it and slow it down by filling it with now-useless XML, use a binary format. Or, if you're going to inefficiently define stuff in XML, then don't hide it in an uneditable binary blob!

Do "welcome screen" thumbnail loading and rendering in another thread - stalling the UI thread so the user can't click the 'New' button until LDD has loaded and rendered a thumbnail of a previous model is yet more poor engineering.

I know LDD is free but it has Lego's name on it, and that means the same degree of quality and attention to detail should apply to its engineering as to the rest of Lego's products. I find the LDD software frustrating, slow and frequently disappointing.

On one hand, I agree. My younger brother has a netbook and encounters many of these same errors. At the same time, I think it should be considered that as free software, we have to give the LDD team some slack. After all, from my experience, the quality of LDD is far better than some of the extremely glitchy LEGO computer software of the 90s and early 00s, and those cost money!

Now, as far as computers are concerned, I'm pretty lenient about things running poorly. I tend to keep my patience with software even if it crashes frequently or runs slowly-- in most cases, I just learn to put up with or work around its flaws. And I'm sure the LEGO computer games from the 90s, on my mom's old PC which often ran poorly on its own, helped condition me to put up with more than I probably ought to. But I still think LDD is a magnificent piece of software and I love how it's always being improved further with its ever-expanding bricks palette, not to mention the sense of accomplishment in reporting bugs and errors on this forum so the design team can put our time spent building to good use.

[hrontos]

nemo, on 17 August 2011 - 06:56 PM, said:

I'd like all the basic UI errors to be fixed.

eg, when Ctrl-clicking to add bricks to a selection, who could argue that just missing the required brick and clicking in open space could possibly be legitimately interpreted as a desire to lose the entire selection? Whilst still holding Ctrl? Basic stuff.

Lassoo selection should use the projected brick outline (or a convex hull of the projection) NOT the bounding box to decide what is inside the lassoo rectangle. Ctrl-lassoo should obviously not clear the current selection first.

As I've reported elsewhere, the colour palettes must NOT be fixed size as they don't fit on a netbook screen (1024x600).

The other thing I'd like is some more sensible data management. The massive binary blob of XML files that is the 400MB .lif (ignoring the oxymoronic construction itself!) is unnecessarily inefficient and causes a huge amount of delay. If you are going to use a binary format, then build in an appropriate index at the start so the whole massive file doesn't have to be scanned!

No, I can't ignore the oxymoron: If you're going to have a binary file, don't inflate it and slow it down by filling it with now-useless XML, use a binary format. Or, if you're going to inefficiently define stuff in XML, then don't hide it in an uneditable binary blob!

Do "welcome screen" thumbnail loading and rendering in another thread - stalling the UI thread so the user can't click the 'New' button until LDD has loaded and rendered a thumbnail of a previous model is yet more poor engineering.

I know LDD is free but it has Lego's name on it, and that means the same degree of quality and attention to detail should apply to its engineering as to the rest of Lego's products. I find the LDD software frustrating, slow and frequently disappointing.

On one side I agree, that fixed size of design palette is design flaw. On the other hand, when reading all these and other complains, it looks like we forgot what is the purpose of this software.

I am pretty sure, if TLG would like to make a perfect LEGO building software they could do it and sell it. But purpose of LDD is completely different. It is just a tool to support real LEGO play. I have 6 years old son and he can use it. It was designed for kids and it perectly fits for the purpose. We are using it far beyond it's original purpose. I mean, what sense of play it has for kids to build virtual model of several thousands of bricks? Spending hours at computer. It is just as silly as running in front of your TV with xbox and kinect instead of playing real football. I want them to do real builds and to play real football.

I appreciate a lot from TLG that they published design of the bricks which cannot be bought and therefore are not making real money for TLG. They invest some extra effort just for the LEGO fan comunity. Yes, the UI can be improved. We can push it to Photoshop style, with many toolbars and buttons. But what would the 8 or 10 years old kid do? Did you noticed how simple the sample models are? This gives you a clear estimation on who is the target audience. TLG is mainly toy supplier, so they have no reason to create profi version of LDD. They want to focus on the toys and not on the software. It looks like we are trying to race cross coutry motocross race on something which designed as perfect bicycle for young kids. I remember the very first versions of the LDD and we have to admit, that if was really pushed  a lot towards the wishes of adult LDD users while still keeping it usable also for 6 year old kid.

We can discuss also the huge lif files. It saves a disk space comparing to thousands of xml files. It can be mapped to memory, so it is accessed directly without completely being read while still giving the ability to use xml processing tools. I consider it very nice that they keep the brick definition open to average programmer giving some oportunities to push it beyond the original purpose. Binary format would be closed and useless.

If the UI will improve, it would be nice. I can live without lassoo and without mirror tools. With real bricks it also doesn't work.  
But I want them to continue supplying more bricks and improve the building instructions. This not in contradiction with original purpose and helps also kids to build models using wider palete of bricks with better instructions.

Edited by hrontos, 17 August 2011 - 11:24 PM.

[Superkalle]

nemo, on 17 August 2011 - 06:56 PM, said:

I'd like all the basic UI errors to be fixed.

eg, when Ctrl-clicking to add bricks to a selection, who could argue that just missing the required brick and clicking in open space could possibly be legitimately interpreted as a desire to lose the entire selection? Whilst still holding Ctrl? Basic stuff.

Lassoo selection should use the projected brick outline (or a convex hull of the projection) NOT the bounding box to decide what is inside the lassoo rectangle. Ctrl-lassoo should obviously not clear the current selection first.

As I've reported elsewhere, the colour palettes must NOT be fixed size as they don't fit on a netbook screen (1024x600).

The other thing I'd like is some more sensible data management. The massive binary blob of XML files that is the 400MB .lif (ignoring the oxymoronic construction itself!) is unnecessarily inefficient and causes a huge amount of delay. If you are going to use a binary format, then build in an appropriate index at the start so the whole massive file doesn't have to be scanned!

No, I can't ignore the oxymoron: If you're going to have a binary file, don't inflate it and slow it down by filling it with now-useless XML, use a binary format. Or, if you're going to inefficiently define stuff in XML, then don't hide it in an uneditable binary blob!

Do "welcome screen" thumbnail loading and rendering in another thread - stalling the UI thread so the user can't click the 'New' button until LDD has loaded and rendered a thumbnail of a previous model is yet more poor engineering.

I know LDD is free but it has Lego's name on it, and that means the same degree of quality and attention to detail should apply to its engineering as to the rest of Lego's products. I find the LDD software frustrating, slow and frequently disappointing.

I'm not sure why you joined this forum You're two first posts have been filled with nothing by negative "this is basic engineering" and "SCHOOLBOY ERROR" kind of comments. You are naturally free to have an opinion, I just don't understand the purpose since you anyway have decided that LDD is crap. Try some of the Ldraw based softwares and maybe they are more to your liking

[PerryMakes]

Actually - I'd suggest that that Nemo attempts a few "official" builds before writing this software off as junk.  Not only will it help with the efforts in creating this extensive library - but from my own experience - I've found that seriously using the tool for extended build sessions has greatly swayed my opinion.  It's actually quite amazing what it CAN do   And the comments regarding target audience are dead on - this is not the AutoCAD / 3ds Max / SolidWorks in the world of LEGO ... it's more like the Google SketchUp ... which is made evident by the fact you can barely read the manual, launch the software, and become proficient in very little time (thank goodness, the manual isn't going to win in technical documentation awards any time soon)  (and thank goodness for that... because I'm not even sure there -are- any technical documentation awards!!!)  Where was I? ...

I think it's awesome that there are a few threads here for submitting bugs, discussing what we'd like to see in future versions, and the one I especially love... a pretty large catalog of official models built with LDD!  But what was mentioned earlier regarding the target audience - no matter how awesome and perfect we want this software to be... it's a toy for children!

Regards ~ Perry

[nemo]

PerryMakes said:

Actually - I'd suggest that that Nemo attempts a few "official" builds before writing this software off as junk.

I didn’t say it was junk, I have listed some of its flaws. Actually I quite like it, but it is more frustating and slow than it needs to be.

I have built 139 significant projects using various versions of LDD, totalling 2.52MB, and I am a senior software engineer. Am I allowed to express an opinion now?  

Superkalle said:

I'm not sure why you joined this forum

To report the bugs and design flaws, obviously.

I’m not proposing any additional functionality or tools, I’m applying what pressure I can to get the ones we have working properly. Claiming that the target audience is young is no excuse for sloppyness (the reverse, actually).

hrontos said:

We can discuss also the huge lif files. It saves a disk space comparing to thousands of xml files.

Not much – the XML is not compressed. And since the XML is wrapped in a proprietary binary blob it cannot be accessed or edited... so there’s no point in it being XML in the first place. That just makes the file bigger, the reading slower, and requires an XML parsing library in the executable making that bigger too.  

hrontos said:

Binary format would be closed and useless.

.lif is closed. It’s not very complicated I grant you, but it can’t be trivially edited, or can it?  

Edited by nemo, 18 August 2011 - 03:11 PM.

[hrontos]

nemo, on 18 August 2011 - 03:09 PM, said:

Not much – the XML is not compressed. And since the XML is wrapped in a proprietary binary blob it cannot be accessed or edited... so there’s no point in it being XML in the first place. That just makes the file bigger, the reading slower, and requires an XML parsing library in the executable making that bigger too.  

.lif is closed. It’s not very complicated I grant you, but it can’t be trivially edited, or can it?  

It is not about compression. Taking into account that each file on disk consumes at least 4KB (or whatever cluster size you have), large file is much better, than having thousands (4500+) of files having 2KB or less each, because each would consume at least 4KB of disk space so it would waste quite a lot.
Yes, it could be compressed, but it is actually nice, that it is uncompressed. In Windows there is a possibility to map a memory to a disk file instead of pagefile, so portions of any file can be access just like the portions of memory. For example the XML parser can directly access it. If it would be compressed, it would require reading and decompressing somewhere else into memory. But this is a different discussion since this not a programming forum.

We can argue how much lif is closed. It is enough closed for a user and enough open for a programmer. It is not designed to be edited by anybody, stealing TLG intelectual property out of it or making invalid changes and complaining at TLG. But it is enough open to be read and used by somebody, who is really interested in.

[PerryMakes]

nemo, on 18 August 2011 - 03:09 PM, said:

I have built 139 significant projects using various versions of LDD, totalling 2.52MB, and I am a senior software engineer. Am I allowed to express an opinion now?  

Of course not!  I am a senior software engineer as well, and we all know that you must have FIVE megabytes of significant projects before expressing your opinion!  I'm very surprised you did not know that...  

EDIT:  You can probably pick out who the software developers are by looking for posts that have been "edited" 1 or 2 minutes after they were posted.  In others words, rather than finding the errors first, we push out the goods first ... and fix problems later  

Edited by PerryMakes, 18 August 2011 - 04:33 PM.

[Superkalle]

nemo, on 18 August 2011 - 03:09 PM, said:

I have built 139 significant projects using various versions of LDD, totalling 2.52MB, and I am a senior software engineer. Am I allowed to express an opinion now?  

Yes you are, but there is no reason shout "SCHOOLBOY ERROR" and the like when you are in a forum with peers. We are on your side you know   Also, the issues you brought up have been discussed before in the forum, just so you know you are not the only one feeling frustrated about them.

Then about the loading of thumbnails - you know the thumbnail is a 3D object you can rotate, right? Just like the bricks in the brick palette. That's why it takes time to load it. Honestly I don't understand the purpose with interactive objects in the startup window and I think it'd be enough if they just show the pre-rendered PNG thumbnail from the LXF-file - just to speed things up.

[nemo]

Superkalle, on 18 August 2011 - 10:48 PM, said:

Yes you are, but there is no reason shout "SCHOOLBOY ERROR"

I have to quote Kryten from Red Dwarf here:

Kryten from Red Dwarf said:

A superlative suggestion, sir, with just two minor flaws. One: we don't have any defensive shields. And two: we don't have any defensive shields. Now I realise that, technically speaking, that's only one flaw; but I thought it was such a big one, it was worth mentioning twice.

In other words, yes I really did have to write it in capitals.  

Quote

Then about the loading of thumbnails - you know the thumbnail is a 3D object you can rotate, right? Just like the bricks in the brick palette. That's why it takes time to load it.

And that is precisely why they should be loaded in another thread so that the UI continues to work in the mean time.

Quote

I think it'd be enough if they just show the pre-rendered PNG thumbnail from the LXF-file - just to speed things up.

Again, a separate rendering thread would solve that – it could load the PNG quickly and then load the whole LXF slowly if it wanted.

What it does and how long it takes does not matter if the user is not forced to wait while it happens!

PerryMakes, on 18 August 2011 - 04:29 PM, said:

we all know that you must have FIVE megabytes of significant projects before expressing your opinion!

Ah, but did I mention how elegant and concise they are?

Quote

In others words, rather than finding the errors first, we push out the goods first ... and fix problems later

• I have no idea what you mean.
  
• I’m not QA yet. Nor senile.

I dislike the way this forum concatenates unrelated replies just because they are consecutive.

Edited by nemo, 22 August 2011 - 04:21 PM.

[Calabar]

nemo, on 22 August 2011 - 04:18 PM, said:

I dislike the way this forum concatenates unrelated replies just because they are consecutive.

Probably you have to set "Topic Display Mode" as "Standard".
Look for it in your profile (try: Your control panel > Forums > View/Posting/Email Prefs)

[Brickdoctor]

Calabar, on 22 August 2011 - 04:43 PM, said:

Probably you have to set "Topic Display Mode" as "Standard".
Look for it in your profile (try: Your control panel > Forums > View/Posting/Email Prefs)

He means how the forum automatically merges two consecutive posts by the same user within a short amount of time into one post.

[Calabar]

oh, he mean that?  
I thought he was referring to the strange forum configuration I found when I came here for the first time!  

Anyway, the reason to concatenate consecutive posts is to avoid spamming.
I'd like this function will not work for regulators and moderators, because it is a bit uncomfortable when I have to reserve posts for index purpose.
But I think it is a good function for general use. A post have not to necessarily be monothematic.

[Superkalle]

nemo, on 22 August 2011 - 04:18 PM, said:

In other words, yes I really did have to write it in capitals.  

A smile does all difference.  

And if I haven't said it before, welcome to the forum.  

[bbqqq]

1. Click and drag mouse wheel (middle/3rd button) to pan the camera. (shift + right mouse button drag doesn't convenient enough)
2. Auto create quick user bricks and colors palette from all bricks and colors in the work space.(user colors should be one click change)
3. Filter bricks (and decals) by typing number or name in search box.
4. Easy to import custom decal.(at least for local use, not to save with lxf to prevent lxf file become too big.)
5. Photo quality render.(at least just still image screenshot, can wait long render time)
6. Option to turn off the studs grid in build mode.
7. Tool to apply allow collision property to selected bricks.(can build model that use flexibility  of real brick, Why limit ourself and give up the advantage of virtual digital world)
8. Force align/connect tool. select pair/pairs of joins (studs) on difference brick then auto  align/connect as best (auto assign collision bricks as allow collision property if happen).
9. Move select brick to any direction by input number.(stud units support decimal)
10. When you try to slide in an axle or bush by draging the mouse. A sound and icon remind you that you already slide it to touch another brick. (so no need to zoom in and check)
11. Camera option FOV (old LDD 1.x 2.x function) and depth of field (render).
12 Custom wallpaper in all three mode.
13. Bring back and improve running train function. can control speed, direction and switch track.
14. Function to make movie / animation.
15. Add mechanic, physic, PF part, NXT part, train part function simulator.(SR 3D builder)
16. Total weight/price of all/selected bricks realtime display.
17. For non design by me buyable bricks. Have option to get roughly price from internet server database.
18. When a brick selected. four remain pose preview icon pop up related with four arrow keys. So you will never turn the brick wrong way again and again.(always turn brick to desire pose in one key/click)

Edited by bbqqq, 18 September 2011 - 07:49 PM.

[Bojan Pavsic]

1. Better groups.
  - unhide group
  - move groups from one parent group, to another (possible now with selecting the group, creating a subgroup at destination, then deleting the parent group).
  - naming a group, disabling group preview (way faster than all the unnecessary rendering).
2. Hinges
  - the ability to fix a hinge (so it's non-moveable): fixed value, min, max
  - IK (inverse kinematics) algorithms (move the endpoint, automaticly calculates the angles of hinges)
3. Camera
  - add the ability to add set min and max distance from the camera (could be helpful to "see" through walls - min distance and to make rendering faster on bigger files - max distance)
4. File support
  - run multiple instances, "AllowMultipleLDDInstances" from settings doesn't work or i'm not using it right or add the ability to open multiple files at once (i think the first option is easier, but the second is better - memory usage)
  - LDD projects that would include multiple LXF files (like 3 modular buildings, each in it's own file, displayed together on a street). That would help a lot on bigger projects.
5. Customization
  - custom keybindings / mousebindings

Edited by Bojan Pavsic, 16 September 2011 - 07:39 AM.

[alienwar9]

I second the idea to allow multiple LXF files and multiple LDD instances!

Which gave me an idea for a feature. If we could "lock" certain models or chunks of a build. Say I have a floor of a modular house, and its completely finished and I want to move it around, see if it fits on the other floor, etc. It would be really great to be able to lock that whole floor so that LDD recognizes it as one big piece, instead of the hundreds of pieces its made up of. That would save space for the program so it runs faster, and it would help people from accidentally taking parts off of the floor or chunk.

Like if you have a vehicle and want to move it around a lot, if you had it locked you could just click on it and move it, without having to worry about bounding it, or having to make a group of it and then move it.

I'm not sure how it would work, but if LDD could "compress" the group of bricks into one solid object with much less connection points and geometry, it would even allow people to take (ahem) parts of larger builds and put them together without having to worry if the program will crash. So if someone wants to put all the corner cafe buildings together, they would put 3 or 4 large locked pieces together, rather than 8-9,000 pieces.

What would be really great is if you could even select the locked bricks and easily unlock them while building, and LDD would load the full model in, so you could change a piece that doesn't fit on the fly. Maybe if LDD takes a total LXF file and loads it as one piece, that might work?