LDCad 1.7 Alpha 1 (win+linux)

[Roland Melkert]

Hello all,

I finally picked up working on LDCad 1.7 this week.

The first 1.7 test version is available at
http://www.melkert.net/LDCad/nextVer

   

Please note this is a unfinished potentially unstable version. DO NOT copy it over your existing installation.

New is:

!DATA support
It is fully integrated into the normal way of working, but it might need some additional tweaks based on feedback.

Collada export
This was intended as a blender export, but as I discovered glTF somewhere in the middle it is unfinished and might be removed again later. Unless someone has a good reason to support both glTF and collada.

glTF2 export
This format seems to be the better choice for a blender export workflow.
It is much more complete then the collada export, but still needs alot of work.
I'm very much looking for someone who wants to help me optimize the output for blender import.
It includes texture information, but for some reason blender doesn't use it. I'm still looking into that so if anyone knows more please let me know.


Besides the big features there are numerous tweaks and bug fixes, some of which I forgot to keep track of.

All feedback/bug reports are welcome.

[Willy Tschager]

No icons or thumbnails:

   

BTW, how about setting the Gray or Dark GUI template as default (which isn't included either).

w.

[Roland Melkert]

No icons or thumbnails:

BTW, how about setting the Gray or Dark GUI template as default (which isn't included either).

The gray and dark templates are included, but it seems your installation went wrong (especially deploying the .sf files) as it fails to load any of the resources.

Did you extract all files into a writable location?

I will need your log files (unless the can't be written ether) to determine the exact problem.

[Willy Tschager]

Did you extract all files into a writable location?

My bad. Not thinking about much I just copied over to an new folder in "Programs/LDraw (64 Bit). Running it as an admin solved my problem.

w.

[Roland Melkert]

The first 1.7 test version is available at
http://www.melkert.net/LDCad/nextVer
.............
All feedback/bug reports are welcome.

So everything works perfectly then

Just wanted to let you know if you have any issue (including with 1.6) this is the time to report, as I'm working on the program during my vacation.

[Orion Pobursky]

So everything works perfectly then

Just wanted to let you know if you have any issue (including with 1.6) this is the time to report, as I'm working on the program during my vacation.

I'm on vacation right now as well so won't be able to evaluate until I get back.

[Johann Eisner]

Everything is going well so far.
Is there a possibility to take over the favorites from the 1.6d to the 1.7alpha?
(Win64)

[Roland Melkert]

Is there a possibility to take over the favorites from the 1.6d to the 1.7alpha?

Yes, copy the partBin.fav file from your 1.6 installation (%appdata%/LDCad/config) into the config folder alongside the 1.7 exe.

[Philippe Hurbain]

So everything works perfectly then
Just wanted to let you know if you have any issue (including with 1.6) this is the time to report, as I'm working on the program during my vacation.

Finally installed - works fine so far (but I've not done much with it yet!)

[Jaco van der Molen]

Great news! I will try this soon. Tnx.

[N. W. Perry]

So far, so good!

I am having issues with animation playback (playback is too slow error msg), but this is not unique to 1.7.

[Roland Melkert]

I am having issues with animation playback (playback is too slow error msg), but this is not unique to 1.7.

Is rendering during editing <3ms?

Because rendering during animation playback has lots of overhead, as it needs to reprep for each frame etc.

So even when it reports <4ms in the left bottom corner it still can be too slow for 4fps as it only times the actual rendering not the preparations.

[Johann Eisner]

Yes, copy the partBin.fav file from your 1.6 installation (%appdata%/LDCad/config) into the config folder alongside the 1.7 exe.

Works fine!
Thanks.
So far everything has worked and I haven't had any problems.

[N. W. Perry]

Is rendering during editing <3ms?

Because rendering during animation playback has lots of overhead, as it needs to reprep for each frame etc.

So even when it reports <4ms in the left bottom corner it still can be too slow for 4fps as it only times the actual rendering not the preparations.

No, it seems to settle at 5ms minimum. And this was at the default fps of 25 for animation.

[Roland Melkert]

No, it seems to settle at 5ms minimum. And this was at the default fps of 25 for animation.

Sorry I meant ,30ms for a 25fps (40ms) frame rate.

So rendering seems to be more then sufficient, what os are you using.

The only known problems with animation timing I know of are with the (older) Linux versions.

[N. W. Perry]

Sorry I meant ,30ms for a 25fps (40ms) frame rate.

So rendering seems to be more then sufficient, what os are you using.

The only known problems with animation timing I know of are with the (older) Linux versions.

Mac OS 10.14.6. I'm sure it's something in my system, albeit something that didn't use to be happening. One time when the error message came up it complained about something like 8846 ms of rendering time—which indeed would be too slow for 25 fps!

[Roland Melkert]

Mac OS 10.14.6. I'm sure it's something in my system, albeit something that didn't use to be happening. One time when the error message came up it complained about something like 8846 ms of rendering time—which indeed would be too slow for 25 fps!

If it worked with the same LDCad version in the past, then it is most likely a WINE issue.

There is one alternative way for doing the timings I could look into, but the reason I didn't use it in the past was lack of precision.

But I could make it a fallback option.

[Willy Tschager]

My bad. Not thinking about much I just copied over to an new folder in "Programs/LDraw (64 Bit). Running it as an admin solved my problem.

w.

Running LDCad in C:\Programs\LDraw\LDCad 1.7 as Admin solved my issue with the icons but a the same time all other folder for config files and such got created in the C:\Programs\LDraw\LDCad 1.7 folder as well and not in C:\Users\Willy\AppData\Roaming\LDCad 1.7 as expected.

I can add the unofficial folder to the library but I cannot change the GUI unless I run the .exe as Admin again.

w.

[Roland Melkert]

Running LDCad in C:\Programs\LDraw\LDCad 1.7 as Admin solved my issue with the icons but a the same time all other folder for config files and such got created in the C:\Programs\LDraw\LDCad 1.7 folder as well and not in C:\Users\Willy\AppData\Roaming\LDCad 1.7 as expected.

This is what it should do, as this is a portable version. It is configured to do nothing outside its own folder by design.

It should therefore not be placed in a restricted folder like program files.

If you want it there anyway, you need to reconfigure the program by supplying a ldcad.cfg alongside the exe file.

This is what the setup does, and your own AIOI does that too, so you could use that one as an example.

Just make sure it uses a different sub folder in the roaming tree to work separately from the 1.6 version (if installed).

[Johann Eisner]

Running LDCad in C:\Programs\LDraw\LDCad 1.7 as Admin solved my issue with the icons but a the same time all other folder for config files and such got created in the C:\Programs\LDraw\LDCad 1.7 folder as well and not in C:\Users\Willy\AppData\Roaming\LDCad 1.7 as expected.

I can add the unofficial folder to the library but I cannot change the GUI unless I run the .exe as Admin again.

w.

The portable version of LPup3D works the same way.
There, too, it is best to run the program as administrator, as otherwise certain write operations cannot or only partially be carried out.

[Willy Tschager]

This is what it should do, as this is a portable version. It is configured to do nothing outside its own folder by design.

It should therefore not be placed in a restricted folder like program files.

If you want it there anyway, you need to reconfigure the program by supplying a ldcad.cfg alongside the exe file.

This is what the setup does, and your own AIOI does that too, so you could use that one as an example.

Just make sure it uses a different sub folder in the roaming tree to work separately from the 1.6 version (if installed).

Every day I learn something new. Thanks for clearing this.

w.

[Milan Vančura]

Hello Roland.

I have time to test LDCAD now, while working on our new project. However, I haven't found any hint about !DATA - how can I test it, please?

About my wishlist: you already know it , unfortunately many of my wishes are probably time-consuming to develop. So I try to ask for something "little": please, may you add "search" type of color wheel? Similar like in PartBin: empty at the beginning and showing all colors with _name_ matching the typed string. Nowadays, the only search is by color number - that's not user-friendly much...

First improvement is LDCAD color wheels configuration without dithered colors, it speeds up searching, but still it's always "a tour trough several wheels" to find a new color.
BTW, what are dithered colors for? I'm still nervous I miss something important if I removed them from the configuration

[Roland Melkert]

I haven't found any hint about !DATA - how can I test it, please?

!DATA was mostly invented to include the textures of unofficial parts in a (omr) MPD.
It has been added to the embed features and there is a new session kind which only accepts png images.

please, may you add "search" type of color wheel? Similar like in PartBin: empty at the beginning and showing all colors with _name_ matching the typed string. Nowadays, the only search is by color number - that's not user-friendly much...

I always thought there aren't enough colors to mandate a search box, given the amount of space it takes. But with the recent new colors that might need some reconsidering.

BTW, what are dithered colors for? I'm still nervous I miss something important if I removed them from the configuration

They where used to mix colors by alternating 2 colors from a 16 item palette close together making them appear as different (custom) colors from a distance. I think it had to do with the CGA/EGA monitors of the time. LDCad fakes them by calculating the (a+b)/2 RGB values.

You can disable them in the prefs/ldraw menu without editing the configuration.

If a model uses one of those colors it will automatically be added to the color bin during that LDCad's run.

[Johannes Ahlmann]

Hi Roland,

I have been doing quite a bit of rendering of lego in Blender/ Cycles, and would be very interested in collaborating.

BTW, I am particularly interested in automation and command-line uses. Any chance that the new export functionalities might be exposed in the LUA API?

Also see here: https://forums.ldraw.org/thread-24780.html

Regards,
Johannes

[Magnus Forsberg]

They where used to mix colors by alternating 2 colors from a 16 item palette close together making them appear as different (custom) colors from a distance. I think it had to do with the CGA/EGA monitors of the time. LDCad fakes them by calculating the (a+b)/2 RGB values.

You can disable them in the prefs/ldraw menu without editing the configuration.

If a model uses one of those colors it will automatically be added to the color bin during that LDCad's run.

All official parts that used dithered colours have been reworked, and there should be none left in the library.

[Milan Vančura]

Thank you for the clarification, Roland.

!DATA was mostly invented to include the textures of unofficial parts in a (omr) MPD
It has been added to the embed features and there is a new session kind which only accepts png images.

I do not understand this one - what is the prefered way of adding a bitmap texture to a part? TEXMAP or !DATA ? And do they both support png?

I tried TEXMAP, using your helper script generating stickers and merged the result at proper place on the part (without sticker thickness, of course). This works but I cannot compare it with !DATA because I did not find any useful tutorial about it. Is it a worth, BTW? Isn't TEXMAP the current way of doing this?

I always thought there aren't enough colors to mandate a search box, given the amount of space it takes. But with the recent new colors that might need some reconsidering.

Sure, it's a question. My idea was to be able to type the key-part of the name to get very limited list quickly. Instead of typing "Red" and trying many similar colors one by one, type i.e. "sand" and see the answer quickly. Or if you do not know that pearl colors are among metalic ones,simply type "pearl" etc.

On the other hand, the real Solid colors take 3 wheels, without dithered ones. Not that bad... So, anyway, what about  moving dithered colors out of Solid colors, creating new category (like metalic, transparent etc. are).

[Travis Cobbs]

I do not understand this one - what is the prefered way of adding a bitmap texture to a part? TEXMAP or !DATA ? And do they both support png?

!DATA is used to encode the actual image data for a texture directly into an LDR file. Having a !DATA definition for a texture has absolutely no affect (other than making the file bigger) if the image is not referenced by some !TEXMAP. !DATA technically supports any arbitrary binary data, but since the only thing that makes use of it is !TEXMAP, it's only really useful if it's an image. (Note that !TEXMAP only officially supports PNG images, although other formats might work in some renderers.)

Due to how it works, the !DATA meta-command was added to the MPD spec. I don't know if there are any tools to generate !DATA entries for a given PNG file. The syntax is simple, though. There is the 0 !DATA <filename> line, followed by 0 !: lines, where everything after the 0 !: is the Base64-encoded data from the PNG file (with line length of 80). The <filename> used on the !DATA line can then be used in any !TEXMAP, and it will be shown as the texture without requiring the actual file to be present as a separate file on the disk. There is an example in the MPD spec.

!DATA would be used to encode the textures needed by unofficial parts in an MPD file (for example for use on the OMR). The unofficial parts themselves would not use it. The containing MPD would use it. !DATA is illegal in official parts.

[Milan Vančura]

!DATA is used to encode the actual image data for a texture directly into an LDR file. Having a !DATA definition for a texture has absolutely no affect (other than making the file bigger) if the image is not referenced by some !TEXMAP. !DATA technically supports any arbitrary binary data, but since the only thing that makes use of it is !TEXMAP, it's only really useful if it's an image. (Note that !TEXMAP only officially supports PNG images, although other formats might work in some renderers.)

Due to how it works, the !DATA meta-command was added to the MPD spec. I don't know if there are any tools to generate !DATA entries for a given PNG file. The syntax is simple, though. There is the 0 !DATA <filename> line, followed by 0 !: lines, where everything after the 0 !: is the Base64-encoded data from the PNG file (with line length of 80). The <filename> used on the !DATA line can then be used in any !TEXMAP, and it will be shown as the texture without requiring the actual file to be present as a separate file on the disk. There is an example in the MPD spec.

!DATA would be used to encode the textures needed by unofficial parts in an MPD file (for example for use on the OMR). The unofficial parts themselves would not use it. The containing MPD would use it. !DATA is illegal in official parts.

Thanks a lot, Travis, this is excelent summary. Canyou add this to the Documentation so people can find it?

[Travis Cobbs]

Thanks a lot, Travis, this is excelent summary. Canyou add this to the Documentation so people can find it?

!DATA is already documented in the MPD spec. I requested that the link to the MPD spec be updated to indicate that !DATA is in there.

Maybe somebody could create a user-friendly explanation of !DATA usage with !TEXMAP, but I'm not sure where the best place for that would be (not the specs). I think it was assumed that tools (like MPDCenter) would be updated to automatically support !DATA. I don't think this has happened yet.

[Orion Pobursky]

I think it was assumed that tools (like MPDCenter) would be updated to automatically support !DATA. I don't think this has happened yet.

This alpha of LDCad is the first program to support creation of MPD files with embedded image data.

[Roland Melkert]

I have been doing quite a bit of rendering of lego in Blender/ Cycles, and would be very interested in collaborating.

BTW, I am particularly interested in automation and command-line uses. Any chance that the new export functionalities might be exposed in the LUA API?

I would very much like feedback on the current glTF2 export from a blender user's point of view.

One note on using the exports is to ether remove the default light source (in a new blender scene) or the one in the glTF2 data before rendering with cycles as it will look 'over exposed' otherwise.

I'm also open to suggestions about the default material properties (as supported by the glTF2 format).

As for scripting batches this isn't possible in the current version as scripts are very 'current open model' oriented.

I will look into adding functions for automating loading/exporting models to the macro portion of the lua interface.

[Milan Vančura]

!DATA testing

In short: I'm lost This is what I've tried and how LDCAD 1.7 Alpha works on my Linux machine (Debian Jessie, x86_64) - sorry for such a long story,I try to describe how to reproduce the strange behavior I got, step by step:

0. Note: where the !DATA support is hidden in GUI: Session->Create new...->Data. This is what I used.

1. Huge black square with a white cross is displayed in the main window, "Edit data header" popup over it and, on top, another popup "LDCAD Error": This is not a png file. With two such messages in Details section, same timestamp. And yes, after clicking "OK" button, second popup with the same error appears. "OK" again and I'm in the Header popup window.

2. I was confused by "Load" and "Save" labels on buttons, at first, so I tried to type the image full path  manually. Accept clicked. I got the same error again: "This is not a png file". Probably because LDCAD replaced all slash chars to backslash chars in the image path.??

3. Load button. Opens a choose file dialog, I selected one of my png files, hit OK. I see "Data File size:....." which looks OK, although the end of the text is hidden behind Load and Save buttons. But the Filename field is not updated with the selected png file and that huge black square with white cross is still here. Even after "Accept" button hitting. So did LDCAD load that png file or not?

4. In the Part bin, I switched to the tab "MPD File content". I see main.ldr and black square submodels there. But after switching to main.ldr and back to "png" subfile, the thumbnail in the part bin got updated! I see the correct png there. In the main window the big black square is still there. But it looks like a moment of hope!

5. I switched back to main.ldr and drag png submodel from part bin to the main window. I got an error "Part usage not allowed in this kind of subfile.".

6. Hypothesis: although I understood Travis' description in the opposite way, it might be that LDCAD allows png subfiles in .dat files only. So I closed LDCAD, started from scratch but, in the end,I got the same error message.

7. The huge black square smiles at me, still.

Did I do anything wrong? What's the intended usage? And how/where I can set the image dimensions in LDus?

Thanks, Roland.

Edit: I saw (in the text editor) the !DATA section was created correctly. So I tried to type the subfile with !TEXMAP lines manually and reopen the file in LDCAD again. Then it works, I can use the new subfile as a sticker. So what's missing is GUI for TEXMAP creation - both for sticker creation and for printed pattern creation.

[Travis Cobbs]

I'm not going to comment about the LDCad 1.7 functionality. However, your second screenshot implies a misunderstanding of the !DATA meta command, either by you, or by Roland. In it, the !DATA section is placed after the !TEXMAP START and before the !TEXMAP END. Unless this is done as a UI convenience, and none of that information is really in that location in the file, then this is invalid.

!DATA behaves very similarly to a 0 FILE entry in an MPD, and 0 FILE entries are not (and can not) be nested. The !DATA line right after the !TEXMAP START immediately ends the sticker.ldr file. And the type 4 line under the data, as well as the !TEXMAP END line should then be treated as invalid data in the !DATA section. (Only !: lines are allowed in !DATA sections.)

[Milan Vančura]

I'm not going to comment about the LDCad 1.7 functionality. However, your second screenshot implies a misunderstanding of the !DATA meta command, either by you, or by Roland. In it, the !DATA section is placed after the !TEXMAP START and before the !TEXMAP END. Unless this is done as a UI convenience, and none of that information is really in that location in the file, then this is invalid.

Thank you for this comment, Travis. I think the file, although just my quick&dirty test, is correct from this POV but I'm glad you clarified the principle for me so I can be more sure.
I attach the original file as is, not as it looks in UI, so you can check it.

Edit: BTW, I _like_ this way how LDCAD displays subfile links: the line showing a subfile link has a plus sign at the beginning and you can display the referenced subfile by clicking on it. It does not mean the subfile definition is there, youcan see the subfile four times if there are four links to this subfile and you "open" all of them. This is a great feature. Usually you let lines as they are (either pointing to some part or a subfile) but you can check the subfile quicky if you need.

[Roland Melkert]

In short: I'm lost This is what I've tried and how LDCAD 1.7 Alpha works on my Linux machine (Debian Jessie, x86_64) - sorry for such a long story,I try to describe how to reproduce the strange behavior I got, step by step:

It seems the new data subfile tries to initialize with an empty png causing the png errors.

When you load the png image using the header it is actually loaded, but the black placeholder texture isn't updated, the one in the bin is though.

I will sort this out for the Alpha 2.

@Travis
The !DATA block is displayed nested in the source window you can tell by the white '-' in front of the texture meta.

Did I do anything wrong? What's the intended usage? And how/where I can set the image dimensions in LDus?

No, this is indeed a gui only problem.

As for the "Part usage not allowed in this kind of subfile" message, !DATA subfiles can only be used with !TEXTURE lines, but most of the time you won't be doing this manually as it will be generated by embedding unofficial content.

I must admit using the !DATA from 'scratch' is more of a part editing thing, which LDCad was never designed for. But I had to include creating !DATA subfiles manually as it is deeply tight into the the 'normal' way of doing things.

[Milan Vančura]

As for the "Part usage not allowed in this kind of subfile" message, !DATA subfiles can only be used with !TEXTURE lines, but most of the time you won't be doing this manually as it will be generated by embedding unofficial content.

I must admit using the !DATA from 'scratch' is more of a part editing thing, which LDCad was never designed for. But I had to include creating !DATA subfiles manually as it is deeply tight into the the 'normal' way of doing things.

From my (user's) POV: one of great features of LDCAD is the possibility to edit/add snap info for parts. Because... ...psychologically: imagine my situation: I'm working on some project and in the worst moment (Murphy's law), under time pressure, I find some part does not behave as I need. And then the difference: instead of waiting for a new LDCAD release with a fix (and reporting the bug and discussions about the fix etc.) I may solve it myself. Quickly. Immediately. In time of the project. That's the difference.

Yes, from your (developer/architect) POV, it is something near to part editing which LDCAD was not designed for, originally. But see how important it is.

And, for the same reason, I was so glad and curious about !DATA support: I hoped it adds a possibility to add a part with pattern to my part set. Again: quickly and immediately. Instead of waiting an unknown time for somebody creating it, at least as an unofficial version in the tracker. Because I'm not a part designer and although I understand some basics I highly respect people who know to really design a part. Just if I could not only add !DATA submodel but use it as well At least somehow. For example if you integrated your WWW script creating stickers from png into LDCAD...

BTW, another feature from this rank would be to set and save the rotation center of a part. Currently I can set it but this setting disappears when I deselect the part or so. It would be very helpful if it can be saved in shadow or something like that. Again - to be able to solve a problem quickly.
And more, if it was possible to select snap objects and use them, for example for this purpose: imagine a part with several snapping points/objects and being able to select among them which one is the part rotation center.

[N. W. Perry]

If it worked with the same LDCad version in the past, then it is most likely a WINE issue.

There is one alternative way for doing the timings I could look into, but the reason I didn't use it in the past was lack of precision.

But I could make it a fallback option.

I’m not certain which version I last tested it with, as I don’t really use animation and only activate it to look at the examples. But that may change with the new interactive capabilities. 

[N. W. Perry]

Sure, it's a question. My idea was to be able to type the key-part of the name to get very limited list quickly. Instead of typing "Red" and trying many similar colors one by one, type i.e. "sand" and see the answer quickly. Or if you do not know that pearl colors are among metalic ones,simply type "pearl" etc.

On the other hand, the real Solid colors take 3 wheels, without dithered ones. Not that bad... So, anyway, what about  moving dithered colors out of Solid colors, creating new category (like metalic, transparent etc. are).

I would actually find it helpful to group like colors together as well (reds, blues, transparent greens, etc.). Stud.io does this in its color search and it’s a feature I like about that program.

But that’s a little beyond your search suggestion, since not all reds have “red” in the name, for example.

[N. W. Perry]

Yes, from your (developer/architect) POV, it is something near to part editing which LDCAD was not designed for, originally. But see how important it is.

As I’ve said before, if LDCad were to eventually include full part-editing capability, then I’d have everything I need.

[Roland Melkert]

Yes, from your (developer/architect) POV, it is something near to part editing which LDCAD was not designed for, originally. But see how important it is.

It is mainly the way how rendering and model interaction is setup. Editing parts means working with loose vertices etc which demand a different way of selecting as the current engine is line oriented.

I was going to address that in 2.0 but that project has stagnated. It might even need a complete rewrite if and when I pick it up (hence the decision to do a 1.7).

...... For example if you integrated your WWW script creating stickers from png into LDCAD...

I have been playing with the idea of adding a sticker (and arrow) generator (like the path and spring ones) to 1.7.

BTW, another feature from this rank would be to set and save the rotation center of a part. Currently I can set it but this setting disappears when I deselect the part or so. It would be very helpful if it can be saved in shadow or something like that. Again - to be able to solve a problem quickly.
And more, if it was possible to select snap objects and use them, for example for this purpose: imagine a part with several snapping points/objects and being able to select among them which one is the part rotation center.

This has been suggested before and is on my 'would like to do, but not sure how' list.

In the meantime you can use a static rotation center by 'locking' the current one.

Or make a group and assign a non zero center to it.

[Milan Vančura]

It is mainly the way how rendering and model interaction is setup. Editing parts means working with loose vertices etc which demand a different way of selecting as the current engine is line oriented.

I was going to address that in 2.0 but that project has stagnated. It might even need a complete rewrite if and when I pick it up (hence the decision to do a 1.7).

I have been playing with the idea of adding a sticker (and arrow) generator (like the path and spring ones) to 1.7.

This has been suggested before and is on my 'would like to do, but not sure how' list.

In the meantime you can use a static rotation center by 'locking' the current one.

Or make a group and assign a non zero center to it.

Ah, I did not know it's such a big difference for the rendering engine. I said I did not know enough about part editing   So, for now, the sticker generator would be a good step forward. Just to be able to use the stored !DATA pattern in LDCAD GUI, interactively. It's a difference, to be able to move and rotate a sticker in graphical interface of LDCAD or compute the sticker transformation matrix

About the part rotation center: thanks a lot for your fair answer. For now, I use groups as you suggested. I don't know to use static rotation center in practice, it always bites me, sooner or later Groups work well and they are also persistent, even trough LDCAD restart or file reload. On the other hand, the problem with groups is that they cannot be copied with this rotation center information kept. Neither Ins nor ctrl-C – ctrl-V saves this information. Is there another way to make a copy of a group with this info kept?

[Milan Vančura]

Another request, a small one (hopefully): I found there is a menu item "smaller menu font". Could you add "Smaller Status bar font" as well, please? I cannot see end part of many messages on my laptop because they simply do not fit in the statusbar.

[N. W. Perry]

Another request, a small one (hopefully): I found there is a menu item "smaller menu font". Could you add "Smaller Status bar font" as well, please? I cannot see end part of many messages on my laptop because they simply do not fit in the statusbar.

Ooh, yes. I have this problem too and keep forgetting to mention it. (I bet the answer is already there, though, by editing some config file…)

[Roland Melkert]

About the part rotation center: thanks a lot for your fair answer. For now, I use groups as you suggested. I don't know to use static rotation center in practice, it always bites me, sooner or later Groups work well and they are also persistent, even trough LDCAD restart or file reload. On the other hand, the problem with groups is that they cannot be copied with this rotation center information kept. Neither Ins nor ctrl-C – ctrl-V saves this information. Is there another way to make a copy of a group with this info kept?

If you need to use groups multiple times, isn't it better to make a submodel for it?

I will look into the amount of work needed to make a 'group aware' copy function as I can't remember the core problem of why it's currently not included.

[Roland Melkert]

Another request, a small one (hopefully): I found there is a menu item "smaller menu font". Could you add "Smaller Status bar font" as well, please? I cannot see end part of many messages on my laptop because they simply do not fit in the statusbar.

Ooh, yes. I have this problem too and keep forgetting to mention it. (I bet the answer is already there, though, by editing some config file…)

There is no hidden option for this at the moment, it is one of the few hardcoded things

Shouldn't be too hard to add though.

[N. W. Perry]

Speaking of groups and their center, there's an interesting quirk—bug?—when a group exists across multiple subfiles. When selecting such a group, you have to click on a part (in nested mode) that is actually in the group's top-level subfile, not the subfile of the current session. Otherwise, the selection center/editing pin will appear way off in the distance somewhere.

(This is not unique to 1.7, by the way.)

[Milan Vančura]

If you need to use groups multiple times, isn't it better to make a submodel for it?

I will look into the amount of work needed to make a 'group aware' copy function as I can't remember the core problem of why it's currently not included.

Thank you, Roland.

About submodel: The advantage of a group is that it is a quick workaround not affecting the result instructions creation. Submodel also might be a workaround but one must be careful about its side effects for instructions. With submodels, I'll have to mark all their instances as "Take as a part" in lpub3d and still, I believe, they will be mentioned separately in the BOM. I'll probably need set a replacement in PLI (with the same part) for each instance to avoid this - I'm not sure. Really complicated and error prone.

Being able to work with snap objects would be a great improvement. Using them as a part pivot point, telling LDCAD which snap objects to count with only for the next step... (try to place some bigger submodel with PS on: LDCAD computes possible snaps for all MxN bricks. If I could tell him I want to place it JUST to this one point...) What about the version 1.8? You know, you got caught in a trap: as the author of such good ldraw editor you came under "pressure" of its users   I found my request of the feature "to be able to select snap objects as rotation points" from 2016, I even created a video showing the feature usefulness!

[Milan Vančura]

There is no hidden option for this at the moment, it is one of the few hardcoded things

Shouldn't be too hard to add though.

Great, thanks!

[Milan Vančura]

One question about scripting:

I got an idea lua scripts might help me with copying groups with their pivot point kept. And while looking around for LDCAD scripting examples, I found methods not mentioned on your Scripting API web page. Probably because lua in LDCAD evolved since the documentation was written. But what surprised me was that I could not get the list of methods by simple dump function. Are ldc objects somehow special? Or is the dump function too basic?
(I'm sorry I'm lua greenhorn, I just try to learn as I use it.)
 

Code:

local seen={}

function dump(t,i)
  seen[t]=true
  local s={}
  local n=0
  for k in pairs(t) do
    n=n+1 s[n]=k
  end
  table.sort(s)
  for k,v in pairs(s) do
    print(i,v)
    v=t[v]
    if type(v)=="table" and not seen[v] then
      dump(v,i.."\t")
    end
  end
end

function dumpLdc()
  dump(ldc,"")
end
--Register macros==============
function register()
  local macro=ldc.macro('Dump ldc')
  macro:setHint('Dump ldc')
  macro:setEvent('run','dumpLdc')
end

register()

[Roland Melkert]

One question about scripting:

I got an idea lua scripts might help me with copying groups with their pivot point kept. And while looking around for LDCAD scripting examples, I found methods not mentioned on your Scripting API web page. Probably because lua in LDCAD evolved since the documentation was written. But what surprised me was that I could not get the list of methods by simple dump function. Are ldc objects somehow special? Or is the dump function too basic?
(I'm sorry I'm lua greenhorn, I just try to learn as I use it.)

That script only lists the 'static' functions, ldc.vector() etc returns lua 'user data' which has its own set of functions.

That said the current lua interface is 99% readonly oriented, so you can't copy groups as you currently can't create groups using pure script.

The documentation is ancient (~version 1.4), I've been working on updating it but its boring and therefor slowly progressing

I've uploaded the part I already done, as it might be somewhat helpful.
http://www.melkert.net/LDCad/docs/scriptAPI2

Don't mind the 150 or so "todo's"

Please note there are some Alpha 2 things (input/control/etc) in there not available in 1.6/alpha1