208 replies to this topic

[Superkalle]

Hikaro Takayama, on 09 October 2011 - 04:38 AM, said:

Well, let me just put it this way:  #1 the computer is an HP (i.e. POS), #2: It has more issues than the New York Times archives (among other things, the mouse pointer becomes disassociated from the cursor if you try to start too many programs at once, and the only way to fix it is to reboot), and #3: a Windows re-install is pretty much out of the question, due to the fact that I bought this system for $50 from my one friend who was moving to Japan, and he didn't give me any of the system restore disks... Like I said, my only concern is to keep it limping along until I can build a suitable replacement (I may end up just using my dual-core portable, but I'd have to transfer all my data and install all my anti-spyware programs and such on the portable, and I don't really have the time and inclination to do that at this point). Also I may have over exagerated a bit, it's more like 3 minutes...

However, I did try purging the "Recent Models" entry in the LDD.ini file, and that did dramatically reduce the loading time... I guess I'll just have to remember to purge the recent models entry... Also, another factor with the slow loading time, particularly when it's connecting to the server to check for updates to the DBM brick lists, would probably be my crappy internet connection, i.e. Verizon Wireless (it's the only thing faster than dialup available where I live currently, and its only 2x as fast as dialup... I'm hoping to be moving into a new place that is near enough to town for DSL or Cable internet so I can dispense with Verizon's crappy, over-priced wireless internet entirely).

...Still, even with these issues and limitations, running LDD on this computer is still better than trying to use LDraw on my old 386sx... XD

Hope you take this the right way, but I'm not sure why even you wrote that it takes five minutes to load the screen when your computer specs and connecton are so extremely poor. When you write 5 minutes naturally people come to the help. Anyway, it's time to wrap up computer spec talk and get back on topic  

[nemo]

Superkalle, on 08 October 2011 - 10:47 AM, said:

The start screen does take a long time to load if you have large LXF-files in the recent-file list. That's because the thumbnails of the previous files are in fact 3D objects...

No, it takes a long time because it is single threaded, forcing the user to wait until it has loaded the .LXF and all the bricks and resources used by that file – and we know how unbearably slow the .LIF access is.

The problem is provoked by large .LXFs, but it is caused by LDD. So to return to topic, what I want in LDD5 is massively improved data access times and multithreading... just having an additional UI thread would make a big difference.

[Superkalle]

nemo, on 12 October 2011 - 12:08 PM, said:

No, it takes a long time because it is single threaded, forcing the user to wait until it has loaded the .LXF and all the bricks and resources used by that file – and we know how unbearably slow the .LIF access is.

It's a bit apples and pears. What I was explanining was just why it is slow today, and that is not primarily becuase it's not multi-threaded, but because it needs to load all 3D data. I'm no expert, but I think simple, quick solution is to use the PNG-thumbnail, not re-write the application to be multithreaded. That also gives the benefit that you can see all recently used files, not only that you can interupt the loading  

[alienwar9]

I have been a big proponent of LDD becoming multi-threaded, so it came as a big surprise to me when I was stress testing LDD to make it crash (yes, on purpose ) that I found LDD tasking 50% of my cpu when I was moving and rotating the camera view. Why is 50% odd? Because my cpu is quad core. So apparently some functions of LDD do operate on more than one core. However, LDD still maxes out doing some functions at only 25%.

Don't know if anyone else has noticed that. Oh, and I am still using version 4.1.6

"even with huge files it shouldn't take more then 10-20 seconds",     
...it takes me 30, on MY pc.


To stay on topic at least a little bit , I'd love to see LDD implement a "free-rotate" where you don't have to have a piece connected to another piece to rotate it in increments less than 90 degrees.
(mentioned already? bah! I still want it.)

[Calabar]

alienwar9, on 12 October 2011 - 05:33 PM, said:

To stay on topic at least a little bit , I'd love to see LDD implement a "free-rotate" where you don't have to have a piece connected to another piece to rotate it in increments less than 90 degrees.
(mentioned already? bah! I still want it.)

I asked something similar in my list on post #2.
But I was happy just to be able to have some "extra" rotation angle!  

Calabar, on 03 August 2011 - 12:26 AM, said:

- (Placement) When you drag a brick, you can rotate it "on the fly". I'd like: 1) more intuitive rotation, sometimes I need much time to find the right direction! 2) more angles, for example 45° rotation clicking two arrows together, or a free rotation working as in the brick palette.

[Hikaro Takayama]

Superkalle, on 12 October 2011 - 03:28 PM, said:

It's a bit apples and pears. What I was explanining was just why it is slow today, and that is not primarily becuase it's not multi-threaded, but because it needs to load all 3D data. I'm no expert, but I think simple, quick solution is to use the PNG-thumbnail, not re-write the application to be multithreaded. That also gives the benefit that you can see all recently used files, not only that you can interupt the loading  

Well, leaving aside my ranting about my slow computer, that is basically what I was saying would be nice: Some less memory-intensive startup screen, and I think this solution would work for everybody...

[Calabar]

nemo, on 12 October 2011 - 12:08 PM, said:

No, it takes a long time because it is single threaded, forcing the user to wait until it has loaded the .LXF and all the bricks and resources used by that file – and we know how unbearably slow the .LIF access is.

But... it is a startup screen, so I think it should be full loaded before you can start using LDD.
The problem is that the loading time depends on the models the screen have to load, and that is not good because big lxf files could need much time to be loaded.
Using png preview images stored in lxf files could solve the problem, but the software would loose a bit of its "coolness".
Perhaps a good approach would be to use the png image and try to load the lxf file only if the user try to move the png image as if it would be a 3D model (but... the delay would be acceptable?).
An option to allow user to choose if use 3d models or images at startup would be another useful solution.

[MattTheLegoman]

Just don't worry about the start-up screen. Find your model on the computer and open using LDD. EG C:\Users\MattTheLegoman\Documents\My Games\LEGO Creations\Models

My gripe for LDD4 is the brick sorting. A few extra dividers in LDD5 for the minifig stuff EG animal parts, hand held, minifig hairstyles, foliage, would be beneficial.

[Toa_Of_Justice]

Brickdoctor, on 04 August 2011 - 05:50 PM, said:

On that note, change Undo to include every action, not just brick placement. So if you select a brick you don't want to select or deselect some bricks you didn't want to deselect, you can use Undo to remedy that. And if you accidentally hide the wrong brick, you can undo it without having to reveal all the hidden bricks and starting over.

Great idea. LDD should also allow Undo to work after saving a file. Currently, saving a file kills the Undo function.

(Example: I just finished a huge load of work on a file, then I save it, only to discover that I made a small mistake. I reach for the Undo button, but to no avail... )

Besides the above, I would appreciate it very much if LDD didn't remove "incorrectly placed" parts automatically. Instead, it should highlight the faulty part(s) in a model (perhaps like the Buyability tool does) and give the builder a chance to correct the problem(s). The "UnplaceableBricksDump.lxfml" file is useless for me--it just repeats the same action as in the original faulty file, but also colors all the good parts yellow. Also, how can everyday users be expected to know that's the file they ought to check for "incorrectly placed" parts? It doesn't seem very obvious to me.

If I can think of any more suggestions, I'll add them to this post.

-Toa Of Justice

EDIT: Here's another one: Allow multiple instances, please! Currently, this dialog box comes up every time I try to open another file alongside my current one...



Neither suggestion provided by the dialog box is helpful. It used to be that the new model would open up in the same window (if I made any unsaved changes, LDD would ask me to save them before loading the new model). The old behavior was OK for me, but this new behavior is not.

If multiple instances aren't feasible, at least bring back the old behavior, please!

Edited by Toa_Of_Justice, 19 October 2011 - 04:42 PM.

[Superkalle]

Some quick comments:

Toa_Of_Justice, on 19 October 2011 - 04:32 PM, said:

Great idea. LDD should also allow Undo to work after saving a file. Currently, saving a file kills the Undo function.

Most Windows software that I know of have the same functionality, i.e. a Save kills all undo. Maybe it's a Windows design guideline.

Quote

Besides the above, I would appreciate it very much if LDD didn't remove "incorrectly placed" parts automatically. Instead, it should highlight the faulty part(s) in a model (perhaps like the Buyability tool does) and give the builder a chance to correct the problem(s).

The problem is that the incorrectly placed parts are colliding with some other part - hence they are simply not possible to show, even in a "buyability tool" feature.
The "UnplaceableBricksDump.lxfml" file is not supposed to be used by normal users - it's actually intended only for LDD developers because they have ways during development to turn off collision control, hence they can open the file without any bricks being removed and then spot the issues.

[Toa_Of_Justice]

Superkalle, on 19 October 2011 - 09:47 PM, said:

Most Windows software that I know of have the same functionality, i.e. a Save kills all undo. Maybe it's a Windows design guideline.

In my experience, Microsoft Word 2007 does not have that functionality. Neither does Microsoft Paint in Windows 7.

Quote

The problem is that the incorrectly placed parts are colliding with some other part - hence they are simply not possible to show, even in a "buyability tool" feature.
The "UnplaceableBricksDump.lxfml" file is not supposed to be used by normal users - it's actually intended only for LDD developers because they have ways during development to turn off collision control, hence they can open the file without any bricks being removed and then spot the issues.

I understand. How would you suggest a way of allowing LDD builders to fix collisions on their own? I believe simply removing offending elements is just confusing.

-Toa Of Justice

[Superkalle]

Toa_Of_Justice, on 20 October 2011 - 05:47 PM, said:

In my experience, Microsoft Word 2007 does not have that functionality. Neither does Microsoft Paint in Windows 7.


I understand. How would you suggest a way of allowing LDD builders to fix collisions on their own? I believe simply removing offending elements is just confusing.

-Toa Of Justice

Cool with MSPaint - just tried it and it works just like you say. Didn't know that.

About removed elements, one thing that the LDD developers could easily implement is to preseent a list of removed elements using a dialogue box, or just output a textfile with them - or why not generate and LXF with the removed elements in. It would be so easy.
In the meantime, what you can do are one of two things:
1) Unzip and open the "UnplaceableBricksDump.lxfml" in a text editor. Search for MaterialID 21 (red), because those are the bricks that were removed due to collision.
2) Open and "Save as" the file. Then import that file along with the original LXF into LDD Manager. Then run the Compare Models function.

[Toa_Of_Justice]

Superkalle, on 20 October 2011 - 06:15 PM, said:

Cool with MSPaint - just tried it and it works just like you say. Didn't know that.

About removed elements, one thing that the LDD developers could easily implement is to preseent a list of removed elements using a dialogue box, or just output a textfile with them - or why not generate and LXF with the removed elements in. It would be so easy.
In the meantime, what you can do are one of two things:
1) Unzip and open the "UnplaceableBricksDump.lxfml" in a text editor. Search for MaterialID 21 (red), because those are the bricks that were removed due to collision.
2) Open and "Save as" the file. Then import that file along with the original LXF into LDD Manager. Then run the Compare Models function.

Thanks for the tips. I'll try them next time I get a warning about removed bricks.

What I normally do is use the Select Connected tool and lift the connected bricks away from the building surface. If I notice anything left behind, I try to guess what got removed based on those bricks. For example, I recently opened a model with removed bricks, only to discover after lifting most of it away that two TECHNIC axles were removed, since I noticed some floating TECHNIC bushings. I replaced the axles, saved the file, and reopened it without further incident.

My technique locates where bricks used to be, and your technique discovers which bricks went AWOL. Together, our techniques should be of great help to the LDD community.

-Toa Of Justice

[Zblj]

Ability to assign a key to create a certain brick, for instance P creates a normal black pin.

[DLuders]

@ Superkalle:  Do you know when LDD 5.0 will be released?  As I recall, the two previous LDD versions (3.0 and 4.0) were released in October 2009 and October 2010, respectively.  Do you expect LDD 5.0 to come soon?  

[Superkalle]

DLuders, on 28 October 2011 - 01:30 PM, said:

@ Superkalle:  Do you know when LDD 5.0 will be released?  As I recall, the two previous LDD versions (3.0 and 4.0) were released in October 2009 and October 2010, respectively.  Do you expect LDD 5.0 to come soon?  

I honestly have no clue. But you are right, there is usually some kind of update late fall each year.

If there is not a new release, hopefully there can be a brick update though.

[vynsane]

The program loading issues are a little overstated - sure, there are some lag issues on out-dated systems, but for the most part it's just a perception issue - the program 'starts' immediately and loads all necessary files after that, whereas most programs 'load' initially, taking some time to actually 'start'.

For example, on my MacBook Pro, if I were to click on Thunderbird (my email client) and LDD, LDD would 'open' first, after one bounce of the icon, and then load the necessary files to actually 'run' the program, whereas Thunderbird will load in the 'background' while the icon will bounce 3 or 4 times in the dock and THEN 'open'. If LDD were to bounce a few times and load the files it needs before opening, most people wouldn't be the wiser.

[Lukas 45]

Hmm..
Ability to export the models for 3D/After Effects?  

[SpiderSpaceman]

vynsane, on 28 October 2011 - 03:19 PM, said:

The program loading issues are a little overstated - sure, there are some lag issues on out-dated systems, but for the most part it's just a perception issue - the program 'starts' immediately and loads all necessary files after that, whereas most programs 'load' initially, taking some time to actually 'start'.

Just as an untested hypothesis, the amount of templates you have saved has to affect the load time, eh?

Edited by SpiderSpaceman, 02 November 2011 - 09:03 PM.

[brickmack]

I'd like people to be able to create their own bricks and put them into the program, and some kind of online library where people could upload and share bricks and models and prints and such. Also I'd like to see it be open source, but I'm not sure if LEGO would do it.

[Superkalle]

brickmack, on 30 October 2011 - 04:48 PM, said:

Also I'd like to see it be open source, but I'm not sure if LEGO would do it.

That would be cool, I agree  

The thing is though that TLG likes to maintain control, both over the program and the bricks, because then they can ensure quality and features so it fit's the target group (which is children, and in turn their parents). Also, TLG wants to be perceived as safe, not only the products themselves, but also any digital experience. We've seen it in LEGO Universe, where players couldn't even use numbers in the chat-window - just because they shouldn't exchange phone numbers (something sick pederast could use to get info). Now, I'm not saying there is anything risk like that in LDD, but at least this is what I think is the reason TLG will not make it Open Source, at least not for some time. If you allow people to create their own bricks and decorations, it can lead to many strange things. For Lego Universe I think TTP was a few days.  

[jasonsmith]

I don't mind if Lego keeps a hold of LDD. It would be nice for it to continue to be developed of which they have already shown. I'd like to see some more power options for us older folks in 5.0 It's a great program which has a huge amount of potential. Lego also has the resources to make it incredible if they so desired. In respect to opensource, it would be nice to see MLCad released to the community, but alas that's another long long thread.

[Superkalle]

jasonsmith, on 31 October 2011 - 10:12 PM, said:

In respect to opensource, it would be nice to see MLCad released to the community, but alas that's another long long thread.

Even though off-topic I can't help but to ask - anyone know why it is not?

[jester]

As for me i want more details and prints on details

Edited by jester, 01 November 2011 - 05:39 PM.

[Superkalle]

jester, on 01 November 2011 - 08:16 AM, said:

as for me i want mor details and prints on details

Hi there

Please note this is a forum for AFOLs. We expect a certain level of posts here, including using capital letters when starting a sentence and proper punctuation.

Thanks