LDCad 1.6 Alpha 3 (win+linux)

[Roland Melkert]

Hi all,

I've released LDCad 1.6 Alpha 3.

Quite a few bugfixes and general tweak/changes in this one.

But it also introduces some (hopefully handy) new features, like:

- Selection MPD embedding.
- Selection MPD detachment.
- Full LDraw org header editing (Including full history and help).
- LPub, LSynth, MLCad meta are recognized and highlighted / editable in the source window.

It also vastly improves the new region selection feature, it is actually usable now

And I finally got to include a 64 bit Windows version as the mingw-64 now includes a suitable threading model for use with my static linkage setup.

I'm not sure if and how I will include the 64 bit version in the installer though, any thoughts on that are welcome.

This is still an Alpha version so it might be (very) unstable use it separate from your normal LDCad installation and make backups of the files you want to edit.

Download it here:
http://www.melkert.net/LDCad/nextVer

I again only made the 64 bit Linux version as the 32 bit VM is currently (way) out of date. Nobody seems to need the 32 bit version anyway but if you really do need it please let me know.

Any feedback / thoughts / suggestions are welcome.

ps: Fun fact I've passed the 1000 commits mark in svn

[Philippe Hurbain]

Great news! Started to play with it a bit...
- My Avast antivirus complained that these files (both 32 and 64b) are very unusual (as far as I guess, means that local AV software can't analyse them) and that they were sent to Avast labs for further analysis... (Edit: a few hours later, got a notification that the file was sound )
- What is the potential benefit of 64 bit version? faster? even bigger LDraw files editable?

It also vastly improves the new region selection feature, it is actually usable now

Indeed! one little caveat though, looks like selecting an axle by the middle is impossible, I guess because there is no vertex there? (Edit: after applying to real model building, area select proves very useful!)

[Philippe Hurbain]

- Looks like the flex parts are broken... "Content" meta is missing so nothing gets displayed.
- "Select same step" issue is corrected... but not if the step is the last in the model. In this case first step parts are selected instead.
- Trying to add a flex part to a submodel while in nested mode hangs LDCad

[David Manley]

Hi all,

I've released LDCad 1.6 Alpha 3.

<snip>

Any feedback / thoughts / suggestions are welcome.

Hi Roland,

a suggestion for your consideration.

When parts are selected in a "source" window, they can be dragged within the window to move their position in the instruction steps e.g. move them from one step to another. If would be useful when dragging them to the top/bottom of the source window if the window content were to scroll while the mouse was positioned near the top/bottom. This would allow the parts to be more easily moved to a building step not currently visible in the "source" window.

Regards,

David

[Philippe Hurbain]

If would be useful when dragging them to the top/bottom of the source window if the window content were to scroll while the mouse was positioned near the top/bottom. This would allow the parts to be more easily moved to a building step not currently visible in the "source" window.

Already asked for that, but Roland wisely answered that auto-scroll rarely works at usable speed (either too fast or too slow...). Instead, even with selection attached to cursor, you may scroll source window using keyboard (up/dn, pgup/dn, home/end) or mousewheel.

[Philippe Hurbain]

Not really related to 1.6...
Part 92909 is missing connectivity for 32494:

Code:

0 //NOTE current version has no solution for the nodged sphere socket (see 32494.dat), just define a fixed ori sphere for now
0 !LDCAD SNAP_GEN [group=nudge1] [gender=F] [bounding=sph 6] [pos=0 0 30]

[Roland Melkert]

Great news! Started to play with it a bit...
- My Avast antivirus complained that these files (both 32 and 64b) are very unusual (as far as I guess, means that local AV software can't analyse them) and that they were sent to Avast labs for further analysis... (Edit: a few hours later, got a notification that the file was sound )

That's the first time that has happened as far I know. It's hard to say what the problem is given such a vague description though. Maybe they just don't like the filesize or something.

- What is the potential benefit of 64 bit version? faster? even bigger LDraw files editable?

The 64bit version is about 5% faster rendering wise on my setup. The exe is slightly smaller but it uses more memory. The main selling point of 64 bit versions is the option to use the full system memory pool but LDCad isn't that hungry to begin with (I haven't seen it using more then 500MB unless you are loading really large models). So in the end it's just the 5% boost I guess

Indeed! one little caveat though, looks like selecting an axle by the middle is impossible, I guess because there is no vertex there? (Edit: after applying to real model building, area select proves very useful!)

Yes after some larger chunk tests, it tests every vertex of the part until at least one is inside the region's frustum. That method gives the least (zero) false positives.

[Roland Melkert]

- Looks like the flex parts are broken... "Content" meta is missing so nothing gets displayed.
- "Select same step" issue is corrected... but not if the step is the last in the model. In this case first step parts are selected instead.
- Trying to add a flex part to a submodel while in nested mode hangs LDCad

Can't believe I missed this, I'll do a Alpha 3a for this asap. Thanks for reporting.

[Roland Melkert]

Hi Roland,

a suggestion for your consideration.

When parts are selected in a "source" window, they can be dragged within the window to move their position in the instruction steps e.g. move them from one step to another. If would be useful when dragging them to the top/bottom of the source window if the window content were to scroll while the mouse was positioned near the top/bottom. This would allow the parts to be more easily moved to a building step not currently visible in the "source" window.

Regards,

David

Like Philo wrote waiting forever on a scrolling window is something I hate myself so I left that out. Instead you could (temporary) open a second source window and drag and drop in between them. Just be sure to disable 'follow selection' and 'follow step' in one of them.

Also the mouse wheel scroll does work while dragging lines (hold ctrl down to scroll faster).

[Roland Melkert]

Not really related to 1.6...
Part 92909 is missing connectivity for 32494:

Code:

0 //NOTE current version has no solution for the nodged sphere socket (see 32494.dat), just define a fixed ori sphere for now
0 !LDCAD SNAP_GEN [group=nudge1] [gender=F] [bounding=sph 6] [pos=0 0 30]

Thanks, this actually needs a new kind of shape/meta variant so the orientation can be forced at 180 deg.

[Roland Melkert]

Alpha 3 has been replaced by Alpha 3a.

I've fixed the template issue Philo reported.

[Travis Cobbs]

- What is the potential benefit of 64 bit version? faster? even bigger LDraw files editable?

The 64bit version is about 5% faster rendering wise on my setup. The exe is slightly smaller but it uses more memory. The main selling point of 64 bit versions is the option to use the full system memory pool but LDCad isn't that hungry to begin with (I haven't seen it using more then 500MB unless you are loading really large models). So in the end it's just the 5% boost I guess

64-bit versions are usually inherently more secure from malicious activity, since their 64-bit address space gives address space layout randomization a vastly bigger playground. For LDraw-base programs, this probably isn't a big deal.

[Philippe Hurbain]

That's the first time that has happened as far I know. It's hard to say what the problem is given such a vague description though. Maybe they just don't like the filesize or something.

The good thing is that it did not complain about 1.6 alpha 3a...

So in the end it's just the 5% boost I guess

Good to know... though LDCad is already quite fast on a machine able to use a 64b exe!

Yes after some larger chunk tests, it tests every vertex of the part until at least one is inside the region's frustum. That method gives the least (zero) false positives.

And it does work very well. If really needed, maybe the shadow library could provide a way to add extra vertices in the handful of parts (mainly axles) that miss them? A 32L axle might be missed quite often

[Merlijn Wissink]

Alpha 3 has been replaced by Alpha 3a.

I've fixed the template issue Philo reported.

Ok, so a few minutes ago I downloaded the new version, fired it up, started a new model and then... it crashed.
Luckily I had only placed a few bricks so not much was lost. Apparently it crashes when I press CTRL + C to copy a part. Maybe a alpha 3b would be necessary? 

[Roland Melkert]

Ok, so a few minutes ago I downloaded the new version, fired it up, started a new model and then... it crashed.
Luckily I had only placed a few bricks so not much was lost. Apparently it crashes when I press CTRL + C to copy a part. Maybe a alpha 3b would be necessary? 

The ctrl+c issue has been reported before but I can't replicate it myself.

Does it crash every time for you? Or only with a specific part / selection etc or completely at random?

Can you describe exactly what you did just before the crash even things like the location of the cursor during the ctrl+c press can be important in order for me to find this bug.

[Roland Melkert]

The good thing is that it did not complain about 1.6 alpha 3a...

They probably added a signature to the db.

And it does work very well. If really needed, maybe the shadow library could provide a way to add extra vertices in the handful of parts (mainly axles) that miss them? A 32L axle might be missed quite often

If it's really needed I could also generate some interpolations just for use with the tests. Just need some rules on when to do that (or not).

[Merlijn Wissink]

Ok, so a few minutes ago I downloaded the new version, fired it up, started a new model and then... it crashed.
Luckily I had only placed a few bricks so not much was lost. Apparently it crashes when I press CTRL + C to copy a part. Maybe a alpha 3b would be necessary? 

The ctrl+c issue has been reported before but I can't replicate it myself.

Does it crash every time for you? Or only with a specific part / selection etc or completely at random?

Can you describe exactly what you did just before the crash even things like the location of the cursor during the ctrl+c press can be important in order for me to find this bug.

Hmm, didn't know it was reported before.

I tested it again and it only crashes in the 64bit version, the 32bit version works fine.

It crashes every time I try to copy a part in the 3d viewer, either using CTRL + C or right mouse button > copy. When copying with either CTRL + C or right mouse button > copy in the source window, it doesn't crash (and pasting works too there).

[Roland Melkert]

Hmm, didn't know it was reported before.

I tested it again and it only crashes in the 64bit version, the 32bit version works fine.

It crashes every time I try to copy a part in the 3d viewer, either using CTRL + C or right mouse button > copy. When copying with either CTRL + C or right mouse button > copy in the source window, it doesn't crash (and pasting works too there).

Thanks it crashes in the 64bit version for me too, shouldn't be to hard to find/fix now

In the meantime consider using the 'ins' key instead of ctrl+c as a workaround.

[Magnus Forsberg]

In the meantime consider using the 'ins' key instead of ctrl+c as a workaround.

Anyone other than me having Insert/Delete on the same key on my keyboard?
I makes me don't wanna learn to use that key.

Actually, I don't even know how to activate the Ins-key. Neither 'Ctrl', 'Shift', 'Alt' nor 'Alt gr' activates it.

[Niklas Buchmann]

Maybe there is an 'Fn' key that will switch to the alternate function, a lot of laptop computers use this.

Sadly, using INS does not work if you want to move parts from one model or submodel to another, I don't think there is an alternative to using copy/paste in that case. I keep losing work because of that bug (and because I'm often forgetting to save...) - weren't there plans for an autosave function at some point?

/This was meant to be a reply to #19, can anyone move it?

[Roland Melkert]

I keep losing work because of that bug (and because I'm often forgetting to save...) - weren't there plans for an autosave function at some point?

This is only in 1.6 I hope? Because the copy bug mentioned above is a 1.6 only issue as the affected code doesn't exist in 1.5.

[Niklas Buchmann]

I keep losing work because of that bug (and because I'm often forgetting to save...) - weren't there plans for an autosave function at some point?

This is only in 1.6 I hope? Because the copy bug mentioned above is a 1.6 only issue as the affected code doesn't exist in 1.5.

Yes, this is in the 1.6 alphas only, I reported that bug in the 1.6 alpha 1 thread. In the previous alpha versions the crashes seemed to happen randomly and I could never find a pattern, the Alpha 3 however seems to crash every single time I use copy or cut.

I know that bug is there and I should remember to save before using copy (or avoid using copy/paste altogether in the alpha 3), but when I forget to and lose work I'm just angry at myself.   After all, LDCad is a great, free piece of software and the new features of the 1.6 version outweigh the bugs for me.

[Roland Melkert]

Yes, this is in the 1.6 alphas only, I reported that bug in the 1.6 alpha 1 thread. In the previous alpha versions the crashes seemed to happen randomly and I could never find a pattern, the Alpha 3 however seems to crash every single time I use copy or cut.

I know that bug is there and I should remember to save before using copy (or avoid using copy/paste altogether in the alpha 3), but when I forget to and lose work I'm just angry at myself.   After all, LDCad is a great, free piece of software and the new features of the 1.6 version outweigh the bugs for me.

Ah good to know,

I don't really understand why it didn't crash always from the start as I was freeing the global copy paste options object instead of a local one (the difference one little '!' can make)

I fixed the issue in the latest build.

I'll release an Alpha 3b later this week(end) hoping to collect some more issues first though.

[Roland Melkert]

I've released Alpha 3b.

It fixed three semi severe issues, namely:

- '0 Unofficial part' failed to parse  (1.6 only bug)
- Copy now and then crashes the program  (1.6 only bug)
- Clicking a color bin menu item during startup / busy gui could crash the program (1.5 bug)

Hopefully this will be a more stable version.

As always any feedback on the new features / annoyances etc are welcome.

[Roland Melkert]

A question to the (advanced) Linux users...

Should I keep compiling releases on (fully updated) Debian 7.5 to maximize compatibility or should I upgrade to Debian 8 ?

[Philippe Hurbain]

Hi Roland,
- Looks like DYNHP rendering mode is broken (does nothing)
- I no longer see the "unofficial" tag in parts bin, though option is said to be enabled
- Could it be possible for hide/unhide function not to reset current selection? Case in point, make a selection containing a completely hidden part AND the parts that hide it (eg. an axle 2 between two angle connectors)?
- Last line of 62531s01.dat shadow should be

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 8 2   R 6 16   R 8 2] [pos=-30 -40 -80] [ori=0 -1 0 1 0 0 0 0 1]

instead of

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 8 2   R 6 16   R 8 4] [pos=-30 -40 -80] [ori=0 -1 0 1 0 0 0 0 1]

(currently it prevents insertion of a pin long with bush that fits IRL).

[Roland Melkert]

- Looks like DYNHP rendering mode is broken (does nothing)
- Last line of 62531s01.dat shadow should be

I noticed something weird about dynhp awhile ago but completely forgot about it thanks for reminding me.

- I no longer see the "unofficial" tag in parts bin, though option is said to be enabled

Yes it seems the filetype meta isn't read correctly at the moment causing the engine to 'guess' the filetype of even the library parts. Writing those metas has a flaw too so it is basically unusable at the moment, but it isn't too bad in practice though. It will be fixed in the next one.

- Could it be possible for hide/unhide function not to reset current selection? Case in point, make a selection containing a completely hidden part AND the parts that hide it (eg. an axle 2 between two angle connectors)?

You mean when unhiding in the source window (which now allows for partial out of order unhiding). Or just in general when invisible things are selected?

[Philippe Hurbain]

I meant in general. Indeed I discovered that I can select hidden things in source window, but it's not so convenient...

[Niklas Buchmann]

I noticed two things regarding rotation and placement of parts:

1) Seems to be a bug: When you have a 'floating' part (mouse button held down) you can by default use the arrow keys to rotate it along the two axis of the current editing plane and PGUP/PGDN to rotate it along the normal of the editing plane. When the editing plane changes because you rotate the camera, those keys are updated to reflect the new editing plane. However, if you use the F/S/T keys to change the editing plane, that update does not happen and the rotation keys are still mapped to the old orientation of the editing plane.

2) The 1.6 version seems to have different options under 'editing movement pin' than before and I think it changed for the worse. You still have placement and rotation mapped to the current editing plane (I like to use CTRL+arrow keys to rotate parts, so that's good for me), but moving the selection center (I like to use SHIFT+arrow keys for this) is now mapped to the absolute XYZ coordinates. I think this is very counter-intuitive because you now have to deal with two different coordinate systems at the same time.
What I would like is to have the selection center movement mapped to the editing plane as well (the way it was in 1.5, I think) and possibly a global option of mapping all movements and rotations to the absolute XYZ coordinates.

[Roland Melkert]

1) Seems to be a bug: When you have a 'floating' part (mouse button held down) you can by default use the arrow keys to rotate it along the two axis of the current editing plane and PGUP/PGDN to rotate it along the normal of the editing plane. When the editing plane changes because you rotate the camera, those keys are updated to reflect the new editing plane. However, if you use the F/S/T keys to change the editing plane, that update does not happen and the rotation keys are still mapped to the old orientation of the editing plane.

I think the main thing here is you shouldn't be able to change the editing plane while holding a part in float this was blocked in 1.5 but somehow got unblocked while making the hot key changes. I'll block it again.

2) The 1.6 version seems to have different options under 'editing movement pin' than before and I think it changed for the worse. You still have placement and rotation mapped to the current editing plane (I like to use CTRL+arrow keys to rotate parts, so that's good for me), but moving the selection center (I like to use SHIFT+arrow keys for this) is now mapped to the absolute XYZ coordinates. I think this is very counter-intuitive because you now have to deal with two different coordinate systems at the same time.
What I would like is to have the selection center movement mapped to the editing plane as well (the way it was in 1.5, I think) and possibly a global option of mapping all movements and rotations to the absolute XYZ coordinates.

Everything should behave as in 1.5 per default, I'll recheck the default mappings thanks for reporting Niklas.

[Niklas Buchmann]

2) The 1.6 version seems to have different options under 'editing movement pin' than before and I think it changed for the worse. You still have placement and rotation mapped to the current editing plane (I like to use CTRL+arrow keys to rotate parts, so that's good for me), but moving the selection center (I like to use SHIFT+arrow keys for this) is now mapped to the absolute XYZ coordinates. I think this is very counter-intuitive because you now have to deal with two different coordinate systems at the same time.
What I would like is to have the selection center movement mapped to the editing plane as well (the way it was in 1.5, I think) and possibly a global option of mapping all movements and rotations to the absolute XYZ coordinates.

Everything should behave as in 1.5 per default, I'll recheck the default mappings thanks for reporting Niklas.

I just noticed that you introduced remappable hotkeys in 1.6, so this likely was a change between the 1.6 Alpha 1 and 2 and not before.

Thanks for looking into it!

[Roland Melkert]

[quote pid='22464' dateline='1468435284']
I just noticed that you introduced remappable hotkeys in 1.6, so this likely was a change between the 1.6 Alpha 1 and 2 and not before.

Thanks for looking into it!
[/quote]

I can't replicate this are you using Alpha 3b in a new folder (so default options?) if not please reset the hotkey bindings to the default (right click on the toolbar -> hotkey config -> reset all) and see if it still feels wrong after that.

[Niklas Buchmann]

I just noticed that you introduced remappable hotkeys in 1.6, so this likely was a change between the 1.6 Alpha 1 and 2 and not before.

Thanks for looking into it!

I can't replicate this are you using Alpha 3b in a new folder (so default options?) if not please reset the hotkey bindings to the default (right click on the toolbar -> hotkey config -> reset all) and see if it still feels wrong after that.

You're right, I had mixed up the left and right keys when I assigned them...

What confused me about this were the different names in the dialog window but when they are assigned correctly they work just fine.

[Roland Melkert]

I'm closing in on a Alpha 4 version,

So if anyone has some pending issues / bug reports please post them now so I might be able to address them before releasing Alpha 4 which will most likely be the last Alpha.

[Philippe Hurbain]

I'm closing in on a Alpha 4 version,

So if anyone has some pending issues / bug reports please post them now so I might be able to address them before releasing Alpha 4 which will most likely be the last Alpha.

Not really an issue, but... I would have expected "detach this subfile" to export the subfile as a mpd containing all submodels used by the subfile.

Otherwise, I can't find a way to know the step where a new part was added except from rewinding steps one by one (or by dichotomy for long sequences!). Is there a better way to do so?

[Philippe Hurbain]

I'm closing in on a Alpha 4 version,

So if anyone has some pending issues / bug reports please post them now so I might be able to address them before releasing Alpha 4 which will most likely be the last Alpha.

Just found something: front left wheel arch looks weird with alpha3b, when displaying the OMR compliant file with included unofficial parts. The non-OMR backup file does look good. Both files look OK with 1.5 or 1.6 alpha2a.

[Roland Melkert]

Not really an issue, but... I would have expected "detach this subfile" to export the subfile as a mpd containing all submodels used by the subfile.

I could add that as an option, in Alpha 4 you could also use the new file cleanup option to prepare a contained (omr) mpd afterwards.

Otherwise, I can't find a way to know the step where a new part was added except from rewinding steps one by one (or by dichotomy for long sequences!). Is there a better way to do so?

I think you mean the 'selected' option in the step menu. It will make the step of the main item of the selection the current step.

[Roland Melkert]

Just found something: front left wheel arch looks weird with alpha3b, when displaying the OMR compliant file with included unofficial parts. The non-OMR backup file does look good. Both files look OK with 1.5 or 1.6 alpha2a.

Both load ok in the current Alpha 4, so this was probably caused by the filetype meta bug I fixed a while back.

[Philippe Hurbain]

I could add that as an option, in Alpha 4 you could also use the new file cleanup option to prepare a contained (omr) mpd afterwards.

Looking for that!

I think you mean the 'selected' option in the step menu. It will make the step of the main item of the selection the current step.

Mmhhh... sorry, I have the strong feeling I already asked this...

[Philippe Hurbain]

Just found something: front left wheel arch looks weird with alpha3b, when displaying the OMR compliant file with included unofficial parts. The non-OMR backup file does look good. Both files look OK with 1.5 or 1.6 alpha2a.

Both load ok in the current Alpha 4, so this was probably caused by the filetype meta bug I fixed a while back.

Good! Just noticed that there is a problem in the tire too...

[Roland Melkert]

I could add that as an option, in Alpha 4 you could also use the new file cleanup option to prepare a contained (omr) mpd afterwards.

Looking for that!

It's a fun feature

   

I'm just not sure about the 'sync description' option. MPDCenter wants that but I can't find it in the OMR specs.

[David Manley]

I'm closing in on a Alpha 4 version,

So if anyone has some pending issues / bug reports please post them now so I might be able to address them before releasing Alpha 4 which will most likely be the last Alpha.

I'm wondering if the ROTSTEP viewing angle is a little off in LDCAD?

When the following model:

Code:

0 Author: David Manley
0 !LICENSE Free for non-commercial use.
1 14 0 16 20 1 0 0 0 1 0 0 0 1 3024.dat
0 STEP
1 4 0 0 0 1 0 0 0 1 0 0 0 1 3622.dat
0 ROTSTEP 41 37 0 ABS

is stepped through in LDCAD, the following view is shown after the second step:

   

However, in LPub, this is rendered as


  rot_step_lpub_pdf.jpg (Size: 5.52 KB / Downloads: 41)

which does reflect the angle as shown in MLCAD


  rot_step_mlcad.jpg (Size: 8.31 KB / Downloads: 40)

Attempting the render in LPub3D, gives another angle altogether.


  rot_step_lpub3d_pdf.jpg (Size: 4.45 KB / Downloads: 40)

I think that MLCad introduced the ROTSTEP meta-command and LPub reflected the rotation accordingly. Unless there's a setting which I have accidentally tweaked , it appears the angle in LDCAD is a little bit out. This makes it a lot harder to use the "sample view" capability in LDCAD (which is nice) since what you see on the screen is not what appears in the build instruction.

Regards,

David

[Roland Melkert]

I'm wondering if the ROTSTEP viewing angle is a little off in LDCAD?

I think these slight differences are caused by one or more of the following things:

Field of view settings (LDCad's default is quite wide).
Overall projection kind (iso/perspective).
The way the orientation is calculated (LDPub seems to use longitude latitude (for use with LDView) instead of direct matrix manipulation like the MLCad spec states).
The models center or lookat might be different. (Might be slightly better in Alpha 4 as it will rezoom visible parts per step change if 'Auto step rotation' is enabled)


Not relevant here as you are using ABS, but the REL variant of the meta seems to behave different in LPub then described in the MLCad specs. Given that LPub is widely used and all the exiting models etc I tried to mimic the LPub way (basically the matrix multiplication order seems to be wrong in LPub or I'm missing something else).

But to make a long story short it probably does need some fine tuning. I will do some more comparisons using MLCad to see if I can find some logic in it all