LDCad 1.5 Beta 1b (win+linux)

[Roland Melkert]

LDCad 1.5 Beta 1a 1b is now available.

Now new features (hence the 'a'), I've mostly fixed a stability issues and restored some features which stopped working due to all the internal changes made for the source window.

Hopefully this version restores the 1.4b stability while adding the full 1.5 feature set.

This version also includes new snap info for many parts, I've updated all '100% info' bin groups in regards of the 2015-01 LDraw update.

It also includes snap info files donated by Philippe Hurbain, Milan Vančura and Jason McReynolds. Thanks to all

For beta 2 I'm hoping to add some minor useful features, I'm thinking about model duplication with an optional mirroring feature (only a dumb positional flip for now). And maybe a similar flipping feature for selections. If anyone has additional (simple) feature requests let me know.

As always the latest version is at:
http://www.melkert.net/LDCad/download

I've also been working on the definitive 1.5 mascot, but it isn't ready yet. Can you guess which model it is

   

edit: I've uploaded 1.5 Beta 1b it addresses a potentially very annoying bug concerning file reloading.

[Jason McReynolds]

Yeah! Haven't had much time to really play with the new release, but I can confirm that in my brief tests that the "Selection indication (Bounding box)" bug has been squashed!

For beta 2 I'm hoping to add some minor useful features, I'm thinking about model duplication with an optional mirroring feature (only a dumb positional flip for now). And maybe a similar flipping feature for selections. If anyone has additional (simple) feature requests let me know.

As far as additional requests go, one that I like in LDD is the ability to select all parts that are connected to a part you select. Not sure if that's "simple", or if others would find it useful, but there you go. Also, and this has been mentioned by others, is the ability to left-click (or whatever combo works ) and drag the mouse to select multiple parts.

[Philippe Hurbain]

Yeah ! (bis)
In the wish list, I discovered that I constantly try to double-click in the source window to open item properties (too many years of MLCad usage...). Would it make sense to add this possibility?
And a reminder: don't create a submodel if user cancels header dialogue while submodel is still empty.

[TestOne]

Dear Roland, first of all I want to thank you, your work is great and becomes better and better at each release.

I think I've found a bug with latest Beta1a. To reproduce it try the following:
1. Open an MPD model
2. Close it through the menu
3. Open the model again

This time it will not load the model, but just a red 3 axis cross will be shown instead.

Hope these steps will help you to track down the problem, which was not present in the Beta1 release.

[Roland Melkert]

Hope these steps will help you to track down the problem, which was not present in the Beta1 release.

They do, thanks for reporting this as it is a severe defect resulting from one of the last bug fixes i made. If nothing else pops up I'll prepare a Beta 1b later tonight.

[Roland Melkert]

I've replaced Beta 1a with Beta 1b it fixes the issue reported by TestOne.

As a little bonus it also adds the string with end studs template (incl snapping info)

Hope this version will last longer

[TestOne]

Hi Roland, the problem when closing and reopening the model has been fixed, thank you.

Now I have another problem. I'm trying to build a copy of the 10179-1: Ultimate Collector's Millennium Falcon. I just passed the 2000 lines in the MPD file (1631 parts and 2073 lines) and with the Beta1 release of LDCAD I have no problems to load my model, but with Beta1b (and also with Beta1a) it seems LDCAD cannot load the full model, it gets stuck before loading the parts' sprites with the message "loading/prepping please wait..". If I manually delete the lines exceeding the 1999 lines, the model loads correctly, as soon as I leave 2000 or more lines, the model doesn't load. This is the only model I have with more than 2000 lines in the MPD file, can you inspect on this?

I don't know if this is the right place to ask, but related to the 10179-1 model, is there a way with LDCAD to bend the riggings (part number 47996) just like on the real model engine?

[Philippe Hurbain]

I just tried to open this model of 10179 with latest beta, no problem here.
Bendable riggings: An old question... Maybe it's possible to create a suitable template for LDCad, but at the moment it's still above my head...

[Roland Melkert]

I just passed the 2000 lines in the MPD file (1631 parts and 2073 lines) and with the Beta1 release of LDCAD I have no problems to load my model, but with Beta1b (and also with Beta1a) it seems LDCAD cannot load the full model, it gets stuck before loading the parts' sprites with the message "loading/prepping please wait..". If I manually delete the lines exceeding the 1999 lines, the model loads correctly, as soon as I leave 2000 or more lines, the model doesn't load. This is the only model I have with more than 2000 lines in the MPD file, can you inspect on this?

This sounds very weird, there are no internal limits on the number 2000 so something else must be causing this.

Could you send me your LDCad logfile of one of the problem sessions and the 2000+ version of the mpd by email so I can try myself.

[Roland Melkert]

As far as additional requests go, one that I like in LDD is the ability to select all parts that are connected to a part you select. Not sure if that's "simple", or if others would find it useful, but there you go. Also, and this has been mentioned by others, is the ability to left-click (or whatever combo works ) and drag the mouse to select multiple parts.

Connecting brick selection isn't simple I'm afraid, but it isn't impossible it might be added when I improve the snapping handling to work with multiple points at once. A selection rectangle is planned for 1.6 but i might push it forwards again as I have many plans for 1.6

In the wish list, I discovered that I constantly try to double-click in the source window to open item properties (too many years of MLCad usage...). Would it make sense to add this possibility?
And a reminder: don't create a submodel if user cancels header dialogue while submodel is still empty.

I believe double click did open the property dialog in the first 1.5 Alpha version(s) but I dropped it thinking it makes more sense to use the same behavior as in the 3d area. Middle button opens the dialog box, left button opens the referenced model (or part if enabled). Canceling a new submodel is on my Beta 2 to do list.

[Niklas Buchmann]

The more I work with hinge plates and bricks, the more it is annoying me that the center of the brick is used as the rotation center. Of course it is possible to move the selection center to the hinge center and then do the rotation, but this takes time and the next time the brick is selected, the rotation center is back at the brick center. If you don't use a custom selection center and try to align the hinge parts after rotation, they often snap to other nearby parts instead of their intended counterpart, making alignment impossible.

My proposal would be to allow the definition of a custom rotation center for each brick, using the existing shadow library and its editing tools. Any thoughts on this?

I also noticed that there are hotkeys for two of the three editing pin modes (M for moving and R for rotating) but not for the third, the move selection center mode. Maybe it might even be a good idea to give direct access to the selection center move, maybe using ALT + arrow keys.

[Roland Melkert]

Of course it is possible to move the selection center to the hinge center and then do the rotation, but this takes time and the next time the brick is selected, the rotation center is back at the brick center.

You could solve this by using submodels and make sure the hinge rotation point is at the submodel origin. You can also use groups (even on a single brick) as it offers an alternative center.

My proposal would be to allow the definition of a custom rotation center for each brick, using the existing shadow library and its editing tools. Any thoughts on this?

It's been sugested before to make it possible to use snapping points as rotation centers by selecting them in some way. But I'm still not sure how to do that gui wise.

I also noticed that there are hotkeys for two of the three editing pin modes (M for moving and R for rotating) but not for the third, the move selection center mode. Maybe it might even be a good idea to give direct access to the selection center move, maybe using ALT + arrow keys.

I currently try to avoid using the alt for anything as it acts weirdly in Linux but I'll look into assigning it a logical key.

[Niklas Buchmann]

Of course it is possible to move the selection center to the hinge center and then do the rotation, but this takes time and the next time the brick is selected, the rotation center is back at the brick center.

You could solve this by using submodels and make sure the hinge rotation point is at the submodel origin. You can also use groups (even on a single brick) as it offers an alternative center.

I do use submodels for that purpose a lot, but only once that part of the model has become somewhat finished and organized. If you just want to play around with the position of some bricks, creating and using a submodel is too complicated for my taste.
I don't really like to use groups because I find them somewhat unfinished and hard to use. I think they ungroup way too easily accidently when you use undo or copy/paste.

My proposal would be to allow the definition of a custom rotation center for each brick, using the existing shadow library and its editing tools. Any thoughts on this?

It's been sugested before to make it possible to use snapping points as rotation centers by selecting them in some way. But I'm still not sure how to do that gui wise.

You're right, one rotation point might not be enough for some hinge parts like 18649 with its two handles or the 2923 double hinge bar. However, a single key for changing between rotation points would be fine for me. The position of the editing would of course be indicating which rotation center is active.

[Philippe Hurbain]

It's been sugested before to make it possible to use snapping points as rotation centers by selecting them in some way. But I'm still not sure how to do that gui wise.

Using the Tab / shift Tab key to go through all possibilities is a common practice. Now for a part that has MANY snapping point this can be a burden, but maybe some order/priority could be defined in the shadow file?

[Milan Vančura]

It's been sugested before to make it possible to use snapping points as rotation centers by selecting them in some way. But I'm still not sure how to do that gui wise.

Using the Tab / shift Tab key to go through all possibilities is a common practice. Now for a part that has MANY snapping point this can be a burden, but maybe some order/priority could be defined in the shadow file?

Yes, this is a common practice in some applications. But here, we face the problem of too many such objects to select from. That's why I prefer mouse this time. LDCad already knows to show snap points, just define another hot key showing them clickable and that click sets the local coordinate system.

The second feature would be to be able to set the selection/part centre without manual creation of submodel. Maybe the submodel is needed, I do not know the internal design of LDCad. In such case it's about more comfortable way to set it up.

A pair of these features allow the user to select exactly "what is put on what".

[TestOne]

I just passed the 2000 lines in the MPD file (1631 parts and 2073 lines) and with the Beta1 release of LDCAD I have no problems to load my model, but with Beta1b (and also with Beta1a) it seems LDCAD cannot load the full model, it gets stuck before loading the parts' sprites with the message "loading/prepping please wait..". If I manually delete the lines exceeding the 1999 lines, the model loads correctly, as soon as I leave 2000 or more lines, the model doesn't load. This is the only model I have with more than 2000 lines in the MPD file, can you inspect on this?

This sounds very weird, there are no internal limits on the number 2000 so something else must be causing this.

Could you send me your LDCad logfile of one of the problem sessions and the 2000+ version of the mpd by email so I can try myself.

Since you stated there are no limits to number 2000 or so, I decided to uninstall everything (I used LDraw AIO before) and download manually the updated October parts and latest LDCad. Now on this PC I can open my model with more than 2000 lines. Tonight I'll try with the other PC where I had the problem and see what happens. If I encounter again this issue I'll send you the email with log and model. Thank you

[Roland Melkert]

I could add a special generic property to all core snap meta's to indicate if it should be available for selection or not. The default value for this property could be snap type depended (e.g. 'yes' for SNAP_FGR, but 'no' for SNAP_CYL).

[Roland Melkert]

It might be library depended, maybe some part gets stuck in a infinite loop or something (i did make some changes to circular reference detection) if one of part loading threads get stuck this way it would cause the behavior you describing.

[Roland Melkert]

For beta 2 I'm hoping to add some minor useful features, I'm thinking about model duplication with an optional mirroring feature (only a dumb positional flip for now). And maybe a similar flipping feature for selections. If anyone has additional (simple) feature requests let me know.

A question for the people whom have been working with the shadow files.

I've been thinking about the mirroring feature and it will need additional information at some point (a mirror transformation matrix (per axis?) and in some cases a replacement part reference (e.g. left/right wing)).

I'm now thinking to add this info using the shadow files and a new meta. Or would it be more practical to do this in a central config file?

Any thoughts on this.

[Jason McReynolds]

I've been thinking about the mirroring feature and it will need additional information at some point (a mirror transformation matrix (per axis?) and in some cases a replacement part reference (e.g. left/right wing)).

I'm now thinking to add this info using the shadow files and a new meta. Or would it be more practical to do this in a central config file?

Any thoughts on this.

My initial thought after reading this would be to keep the mirroring data in a separate config file. Granted, I'm not as familiar with LDraw file specs, but the thought of adding additional info in the shadow files that doesn't really relate to them could be confusing and complicate the file structure, i.e., would we need to see this info in the source code window (does it add value), or would it just clutter things up? I could just not understand the full extent of the shadow files though, and this might fit in fine. I can see from one point that, if you want to make this data easily accessible/modifiable, then this could be a good approach, but does this data compliment what's already there?

Also, the fledgling coder in me thinks that a more "modular" design for this data makes sense, just in case you need to manipulate it differently later, or rip it out all together, it would be easier to do if it wasn't jumbled in with the shadow files.

Just thinking out loud...

[Philippe Hurbain]

No strong opinion here, but since we already have an infrastructure with the shadow files, I tend to prefer the new meta in shadow.

[Owen Dive]

If you have the info in the shadow files, you expose yourself to asymmetries in the library. For example, part A mirrors to part B, but part B mirrors to nothing (or part C!). Nothing that can't be overcome, but it's a risk that needs to mitigated. Of course, depending on the structure you use for a central config file, this issue may be present there as well.

I admit that this question was not directed at me (I haven't been playing with the shadow files!), but I would really really like to see this mirror building functionality implemented, so I thought I'd add my 2 cents.

Owen.

[Jason McReynolds]

This version also includes new snap info for many parts

I doing some more building I've noticed that 2 x plates and bricks don't have snap meta defined for the anti-studs on the bottom of them. Parts should be able to snap to those. Is there an easy way to define it once for all of them? I didn't see any sub-parts that could be modified for these, just the low-level primitives.

Some examples parts are:
3001
3002
3003

3022
3021
3020

[Roland Melkert]

You mean the center ones in between the normal 2xn ones? I left those out on purpose as it will ruin normal snapping behavior with the current implementation.

It will need multi point matching and 'used' points exclusion to be of any real use. Something I hope to add in a future version.

[Jason McReynolds]

You mean the center ones in between the normal 2xn ones? I left those out on purpose as it will ruin normal snapping behavior with the current implementation.

Yes, those are the ones I'm referring to.

It will need multi point matching and 'used' points exclusion to be of any real use. Something I hope to add in a future version.

Sounds good, thanks for the info!

[Milan Vančura]

Hello Roland.

I'm busy these days but I have at least some results of snap data 1.5b testing:

The automatic check of externally modified files does not work in Beta1b.

A warning pop-up window correctly appears when file cannot be saved. Also, another warning pops up when one tries to save the shadow file opened from the archive. Thanks for that. But there is still a problem: after such non-successful save action LDCad marks this file as 'saved' and next ctrl+S does nothing, no warning (LDCad probably believes the file is "unmodified").

snapping:

2546 (parrot): the result is there are two snap objects at exactly same place, one coming from each half. Is this OK?

43744 (phoenix): you changed the head hole diameter from 2 to 1.8 what means that hair decorations and similar parts no longer fit this hole in LDCad. Are you sure this reflects the real parts? I do not have any phoenix here to test now but I believe this hole should fit those parts => diameter 2. Whatever it looks like in ldraw model. Maybe we should request a fix of this part?

61780 : you added the center antistud, even you commented here that these antistuds make LDCad "ruin the snapping behavior" - that's why I left the axle hole there only, originally. So should it be there?

cow head does not snap the cow body - it works with my version of snap data but not with your one (1.5Beta1b). I must say I do not see the exact reason. Horse head+body works in your version well.

mirrored snap objects in general: animal bodies or heads are usually made of two mirrored halves. How to define snap objects for those "halves" in a way that the whole head matches the neck of whole body at the correct position only and not at the half-offset, too? (is this description understandable without picture?)

[Roland Melkert]

Sorry I kinda missed this post.

The automatic check of externally modified files does not work in Beta1b.

All of them? I'll have to check this more closely because it seems to work for me (on Windows at least).

A warning pop-up window correctly appears when file cannot be saved. Also, another warning pops up when one tries to save the shadow file opened from the archive. Thanks for that. But there is still a problem: after such non-successful save action LDCad marks this file as 'saved' and next ctrl+S does nothing, no warning (LDCad probably believes the file is "unmodified").

I'll correct this.

2546 (parrot): the result is there are two snap objects at exactly same place, one coming from each half. Is this OK?

You can prevent that be setting the mirror property to 'none'.

43744 (phoenix): you changed the head hole diameter from 2 to 1.8 what means that hair decorations and similar parts no longer fit this hole in LDCad. Are you sure this reflects the real parts? I do not have any phoenix here to test now but I believe this hole should fit those parts => diameter 2. Whatever it looks like in ldraw model. Maybe we should request a fix of this part?

I usually use the visual diameter unless it's a modeling mistake, Could someone with the real part check this?

61780 : you added the center antistud, even you commented here that these antistuds make LDCad "ruin the snapping behavior" - that's why I left the axle hole there only, originally. So should it be there?

I make an exception if its part of a hole (like in technic plates etc).

cow head does not snap the cow body - it works with my version of snap data but not with your one (1.5Beta1b). I must say I do not see the exact reason. Horse head+body works in your version well.

I'll check and fix this if needed.

mirrored snap objects in general: animal bodies or heads are usually made of two mirrored halves. How to define snap objects for those "halves" in a way that the whole head matches the neck of whole body at the correct position only and not at the half-offset, too? (is this description understandable without picture?)

I'm not sure what you describing here but I'm guessing the mirror=none option will help here too.

[TestOne]

Sorry I kinda missed this post.

The automatic check of externally modified files does not work in Beta1b.

All of them? I'll have to check this more closely because it seems to work for me (on Windows at least).

If I externally modify an mpd file (I often use an external text editor to rearrange groups while working with LDCad on Windows), LDCad tells me that the file got changed. Never tried with other kinds of files with Beta1b.

[Milan Vančura]

The automatic check of externally modified files does not work in Beta1b.

All of them? I'll have to check this more closely because it seems to work for me (on Windows at least).

I tested external modification of model files, part files and shadow files. Notifications do not work for any of them in Beta1b but, on the other hand, all of them work in Beta1.
I cannot test Beta1a because the download link no longer works.

Everything tested on Linux, 64-bit. (Debian Jessie)

[Milan Vančura]

Thanks for a tip with mirror=none. I learn more and more about snap data

About the problem "body + head", both constructed from halves:
I checked Beta1b snap data and it works well for body+head combinations but you can see the problem with, for example, a horse head and horse head armor - see the attached picture (test.png).
mirror=none does not help here, I believe, because we cannot know which half (left or right) is "primary" for each part and which one is "mirrored". My idea is to use caps parameter. If mirroring of SNAP_CYL works correctly and mirrors "caps" direction as well, it should work. Do you agree?
I made a schema for better understanding, see the second picture (schema.png), please.

[Milan Vančura]

43744 (phoenix): you changed the head hole diameter from 2 to 1.8 what means that hair decorations and similar parts no longer fit this hole in LDCad. Are you sure this reflects the real parts? I do not have any phoenix here to test now but I believe this hole should fit those parts => diameter 2. Whatever it looks like in ldraw model. Maybe we should request a fix of this part?

I usually use the visual diameter unless it's a modeling mistake, Could someone with the real part check this?

I asked Czech AFOL community for a help and I have it confirmed now. So, please, change the SNAP_CYL diameter back to 2.

I already requested a fix of the part.

[Roland Melkert]

I tested external modification of model files, part files and shadow files. Notifications do not work for any of them in Beta1b but, on the other hand, all of them work in Beta1.
I cannot test Beta1a because the download link no longer works.

Everything tested on Linux, 64-bit. (Debian Jessie)

I tested on debian 64 (my build vmware image) and it is indeed broken. I changed the way the file monitoring component is used between beta 1 and 1a/b which is nothing special but it seems the linux implementation has a bug or something, I try upgrading wxWidgets to 3.0.2 later this week. Thanks for reporting.

[Roland Melkert]

Thanks for a tip with mirror=none. I learn more and more about snap data

About the problem "body + head", both constructed from halves:
I checked Beta1b snap data and it works well for body+head combinations but you can see the problem with, for example, a horse head and horse head armor - see the attached picture (test.png).
mirror=none does not help here, I believe, because we cannot know which half (left or right) is "primary" for each part and which one is "mirrored". My idea is to use caps parameter. If mirroring of SNAP_CYL works correctly and mirrors "caps" direction as well, it should work. Do you agree?
I made a schema for better understanding, see the second picture (schema.png), please.

I think it can be solved using a generic snap meta instead of a cylinder one in the half subpart of the head and armor. Both set to not mirror. These kind of situations are why I added the GEN meta as the shape matching for this needs more then just pens and pins and also is very specific to a limited set of parts.

I'll take a closer look this weekend and post a new shadow csl file if useful. These

[Roland Melkert]

I asked Czech AFOL community for a help and I have it confirmed now. So, please, change the SNAP_CYL diameter back to 2.

I already requested a fix of the part.

I will change it back, thanks for confirming.

[Roland Melkert]

Attached the newest shadow (renamed to .csl) with added / corrected info.

I didn't add info myself as I'm taking a little break from LDCad (by playing Saints Row IV

Thanks to Philippe Hurbain and Jason McReynolds for donating again.

ps Jason: I think the cow head isn't snapping because of a bug, I'll have to look into that some more. Ether way it will be fixed in beta 2.

[Roland Melkert]

I did some more testing and it turns out it does work on debian, just not while using 'touch' which is weird on its own. But using e.g. vim (see attachment) it does work for me.

Could you send me your logs or check if it mentions something like "File change event | Notify for "

[Milan Vančura]

Thanks, Roland, you work on this.
It behaves differently on my machine. I edit files in vim and save them - no window pops up in LDCad.
There is nothing special in the log file - no line appears when I save the modified file in vim. Only these sets of three lines appear in the log - but they appear again and again, regardless I modify any file externally or not:

Code:

28058 | 2015-11-11_01:01:18 | Progress | Process external changes | Starting
28059 | 2015-11-11_01:01:18 | Info     | Process external changes | Nothing to do.
28060 | 2015-11-11_01:01:18 | Progress | Process external changes | done.

I tried this test with all kind of files (model, part, shadow), same results: no reaction in LDCad window and no line in the log file.

[Roland Melkert]

Those messages appear when the program get focus (again) it will then process all file change events it received while not being active. But apparently none where received.

This is identical to when you use 'touch', the reason for touch not working is because it only changes the file's meta data I've changed the event monitor to include attribute changes so touch should work in beta 2.

But vim does a rename/new file/del update so it should work like expected. Or are you using symbolic links and / or some special filesystem?

[Milan Vančura]

No. No symlinks etc. - nothing special. And I always edit even file data to make a real change. And even then no even is caught, no popup window, nothing in the log.

[Roland Melkert]

Which flavor of debian 8.2 are you using so I can try a corresponding live iso from

http://debian.mirror.cambrium.nl/debian-...so-hybrid/

[Milan Vančura]

AFAICS all iso's there are of the same Debian (8.2 = Jessie). They differ only in te desktop environment pre-installed. I use LXDE but I believe this problem must be DE-independent.
I use no (additional) unofficial repositories (AFAIK) and, to be sure, I attached the output of 'ldd LDCad' so you can compare it with your system. Also, my offer to test some special build of LDCad (with some bug-specific debug prints etc.) is still valid, of course.

[Roland Melkert]

At first it worked for me in LXDE too, but just on a hunch I tried again while NOT using complete.zip (like i normally do on live iso's) by using the fully unpacked library instead. And for some reason it indeed stops monitoring the filesystem, probably on all debian versions I'll have to check that.

I have no clue on why but at least I can replicate it now, I'll try to find a solution/fix this weekend.

[Roland Melkert]

Just wanted people to know I found (and corrected) a semi severe bug which might be causing seeming random program hangs (rendering stops, but hints in status bar keeps working).

the cause lies in the (unsupported) "0 GROUP" meta. So be careful while opening mlcad made models. The problem can be avoided by setting the logging level (prefs/system) to something else then info.

This bug has been present since 1.3 or even earlier so I didn't think a Beta 1.5 1c is needed given no one reported this before I found it myself and I'm planning to release Beta 2 next or next next weekend anyway.

[Philippe Hurbain]

Indeed... obvious issue when trying to fix 8464 model!

[Roland Melkert]

The 8464 problem is how I discovered it myself

It should not be a problem if you change the logging setting though, this because the bug is purely caused by the code logging the 'unsupported' nature of the meta.

[Philippe Hurbain]

This problem can be worse... this file opens fine, but LDCad crashes as soon as you click on any part. Problem seems to be cured when all "0 GROUP -1" (left by SR3D) are removed.

[Roland Melkert]

You are right that one can cause problems even while using the log workaround, I'll have to look some more into this but I'm thinking it's source window related.