LDCad 1.7 Alpha 1 (win+linux)


LDCad 1.7 Alpha 1 (win+linux)
#1
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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#2
No icons or thumbnails:

   

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

w.
LEGO ergo sum
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#3
(2021-07-18, 10:15)Willy Tschager Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#4
(2021-07-18, 19:17)Roland Melkert Wrote: 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.
LEGO ergo sum
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#18
(2021-07-20, 13:50)Willy Tschager Wrote: 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.
LEGO ergo sum
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#19
(2021-07-30, 2:45)Willy Tschager Wrote: 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).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#21
(2021-07-30, 17:14)Roland Melkert Wrote: 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.
LEGO ergo sum
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#20
(2021-07-30, 2:45)Willy Tschager Wrote: 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.
If nothing goes right, go left.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#5
(2021-07-16, 23:00)Roland Melkert Wrote: 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 Big Grin

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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#6
(2021-07-24, 19:51)Roland Melkert Wrote: So everything works perfectly then Big Grin

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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#9
(2021-07-24, 19:51)Roland Melkert Wrote: So everything works perfectly then Big Grin
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!)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#7
Everything is going well so far.
Is there a possibility to take over the favorites from the 1.6d to the 1.7alpha?
(Win64)
If nothing goes right, go left.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#8
(2021-07-24, 22:14)Johann Eisner Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#13
(2021-07-24, 22:23)Roland Melkert Wrote: 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.
If nothing goes right, go left.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#10
Great news! I will try this soon. Tnx.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#11
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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#12
(2021-07-26, 16:20)N. W. Perry Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#14
(2021-07-26, 18:45)Roland Melkert Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#15
(2021-07-26, 23:40)N. W. Perry Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#16
(2021-07-27, 21:06)Roland Melkert Wrote: 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!
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#17
(2021-07-28, 2:08)N. W. Perry Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#37
(2021-07-28, 17:51)Roland Melkert Wrote: 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.  Wink
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#22
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 Smile, 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 Smile
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#23
(2021-08-02, 17:01)Milan Vančura Wrote: 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.

(2021-08-02, 17:01)Milan Vančura Wrote: 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.

(2021-08-02, 17:01)Milan Vančura Wrote: BTW, what are dithered colors for? I'm still nervous I miss something important if I removed them from the configuration Smile
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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#25
(2021-08-03, 21:55)Roland Melkert Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#26
Thank you for the clarification, Roland.



(2021-08-03, 21:55)Roland Melkert Wrote: !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?



(2021-08-03, 21:55)Roland Melkert Wrote: 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).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#27
(2021-08-04, 10:15)Milan Vančura Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#28
(2021-08-04, 17:22)Travis Cobbs Wrote: !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?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#29
(2021-08-04, 18:34)Milan Vančura Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#30
(2021-08-04, 19:23)Travis Cobbs Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#38
(2021-08-04, 10:15)Milan Vančura Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#24
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
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#31
(2021-08-04, 0:21)Johannes Ahlmann Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#32
!DATA testing

In short: I'm lost Smile 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. Smile

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.


Attached Files Thumbnail(s)
       
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#33
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.)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#34
(2021-08-06, 17:33)Travis Cobbs Wrote: 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.


Attached Files
.mpd   test_data_tag.mpd (Size: 1.48 KB / Downloads: 2)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#35
(2021-08-06, 11:16)Milan Vančura Wrote: In short: I'm lost Smile 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.

(2021-08-06, 11:16)Milan Vančura Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#36
(2021-08-06, 18:17)Roland Melkert Wrote: 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 Smile 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#39
(2021-08-08, 7:02)Milan Vančura Wrote: 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. Cool
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#40
(2021-08-08, 7:02)Milan Vančura Wrote: 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).

(2021-08-08, 7:02)Milan Vančura Wrote: ...... 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.

(2021-08-08, 7:02)Milan Vančura Wrote: 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#41
(2021-08-08, 20:17)Roland Melkert Wrote: 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 Smile  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 Smile

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 Smile 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?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#44
(2021-08-09, 10:51)Milan Vančura Wrote: 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 Smile 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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#47
(2021-08-11, 19:05)Roland Melkert Wrote: 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 Smile  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! Smile
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#46
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.)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#42
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.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#43
(2021-08-09, 11:40)Milan Vančura Wrote: 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…)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#45
(2021-08-09, 11:40)Milan Vančura Wrote: 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.

(2021-08-09, 16:14)N. W. Perry Wrote: 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 Smile

Shouldn't be too hard to add though.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#48
(2021-08-11, 19:07)Roland Melkert Wrote: There is no hidden option for this at the moment, it is one of the few hardcoded things Smile

Shouldn't be too hard to add though.

Smile Great, thanks!
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#49
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()
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#50
(2021-08-12, 11:52)Milan Vančura Wrote: 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 Smile

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" Big Grin

Please note there are some Alpha 2 things (input/control/etc) in there not available in 1.6/alpha1
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#51
(2021-08-12, 18:21)Roland Melkert Wrote: 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"  Big Grin

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

Thanks, Roland! "todo's" are ok - still better than pure list of methods got from the dump function - if I wrote any which worked with ldc Big Grin
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#52
The order of pasted lines in src window (bug or feature?)

I found that if more lines are selected and copied in src window their order after pasting them is as they were marked, not as their "parents" are in. This gives more possible actions if you know about this but it can be very surprising if you don't Smile Is this intentional?

Note: usually the order of lines does not make a difference but some meta commands/comments order is important. STEPs, for example. Or the order of path points.

In nested mode, Path point can be duplicated only if just one is selected

After selecting more than one path point (in nested mode), Ins key does nothing, silently. Same with Ctrl-C,Ctrl-V in edit window. But Ctrl-C,Ctrl-V in source window works. If the submodel with the path is open in the edit window (no nested mode), Ins works.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#53
(2021-08-18, 14:09)Milan Vančura Wrote: The order of pasted lines in src window (bug or feature?)

I found that if more lines are selected and copied in src window their order after pasting them is as they were marked, not as their "parents" are in. This gives more possible actions if you know about this but it can be very surprising if you don't Smile Is this intentional?
This is intentional, mainly so you can reorganize step related things.

(2021-08-18, 14:09)Milan Vančura Wrote: In nested mode, Path point can be duplicated only if just one is selected
This sounds like a bug, I will look into it.

Thanks for reporting Milan.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#54
You might set the following on the wishlist (also for 2.0):

A "H" (something like the "unOff") in the parts bin indicates that the part has a !HELP line. A click on the "H" will show that !HELP line content.

w.
LEGO ergo sum
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#55
(2021-08-19, 12:47)Willy Tschager Wrote: You might set the following on the wishlist (also for 2.0):

A "H" (something like the "unOff") in the parts bin indicates that the part has a !HELP line. A click on the "H" will show that !HELP line content.

w.

That's a good one.
I've often asked myself: - who, besides part authors, are able to read the Help info?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#56
Not a new issue, but it appears that the part count for the model correctly excludes any part refs that are duplicated due to buffer exchange. However, the parts within a submodel that is duplicated are not excluded (so they are double-counted and the final part count is too high).

Or maybe there's a setting I should check?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#57
(2021-11-10, 19:16)N. W. Perry Wrote: Not a new issue, but it appears that the part count for the model correctly excludes any part refs that are duplicated due to buffer exchange. However, the parts within a submodel that is duplicated are not excluded (so they are double-counted and the final part count is too high).

You mean it goes wrong when a submodel also uses buffer exchange or the whole (non exchange) model is counted?

Could you send me the problem file?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#58
(2021-11-10, 20:04)Roland Melkert Wrote: You mean it goes wrong when a submodel also uses buffer exchange or the whole (non exchange) model is counted?

I meant the second, but it may actually be both in this case.

Quote:Could you send me the problem file?

Yeah, here it is. (Note the main subfile is currently empty 'cos it's not finished yet.)

This model is actually progressively recursive, but I don't think that's the issue as it's present even at the first level of nesting. What I mean is that the submodel for box 1 is a subfile in box 2. Then that box 2 submodel is a subfile in box 3, and so on. So the double-counting starts to add up pretty quick.

I also include per-step part counts in the comments, which also reflect things like u-joints being actually one part instead of three, not counting stickers as parts, etc. So that doesn't exactly match LDCad's count, but I can at least account for the discrepancies.

(By the way, this is the same model in which I was having the snapping issue with axlehole prims, so maybe it will help to recreate that.)


Attached Files
.mpd   8448.mpd (Size: 966.36 KB / Downloads: 2)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#59
(2021-11-11, 1:56)N. W. Perry Wrote: I meant the second, but it may actually be both in this case.

I think I fixed it, how's this:
   

It's still 12 off but that's because of the universal joints.

I'm thinking about introducing a shadow meta to exclude certain parts from counts (e.g. the joint ends, so it only counts the joiners using an alternative part).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#60
(2021-11-11, 21:48)Roland Melkert Wrote: I think I fixed it, how's this:


It's still 12 off but that's because of the universal joints.

I'm thinking about introducing a shadow meta to exclude certain parts from counts (e.g. the joint ends, so it only counts the joiners using an alternative part).

Yeah, that should be right.

A shadow meta could be cool; of course you'd want to have the option to count those parts or not (and maybe whether or not to include stickers, etc.). But it's also true that I should probably be making better use of LDCad's shortcut templates, so that hinges and such are automatically broken up into component parts.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2021-11-11, 23:21)N. W. Perry Wrote: Yeah, that should be right.

I'm revisiting this issue as I'm double checking my todo list.

Doing so I noticed an issue with step part counts which isn't really a bug (I think) but probably very weird to an end user.

In your 8448.mpd?suspFront.ldr from above:

step 13
part cnt in step 21, part cnt in model: 486
step 14
part cnt in step 353, part cnt in model: 834
step 15
part cnt in step 353, part cnt in model: 486
step 16
part cnt in step 5, part cnt in model: 486

This 'feels' wrong but I guess it's actually correct, because:

Step 14 -> you clear the model and add the suspRear model to it.
Step 15 -> you restore step 13 and add the suspRear model to it.

So from the context of step 14 there are two suspRear instances active in the model resulting in the higher model part count.

Just looking for some thoughts about how this should act/work.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-22, 23:59)Roland Melkert Wrote: I'm revisiting this issue as I'm double checking my todo list.

Doing so I noticed an issue with step part counts which isn't really a bug (I think) but probably very weird to an end user.

In your 8448.mpd?suspFront.ldr from above:

step 13
part cnt in step 21, part cnt in model: 486
step 14
part cnt in step 353, part cnt in model: 834
step 15
part cnt in step 353, part cnt in model: 486
step 16
part cnt in step 5, part cnt in model: 486

This 'feels' wrong but I guess it's actually correct, because:

Step 14 -> you clear the model and add the suspRear model to it.
Step 15 -> you restore step 13 and add the suspRear model to it.

So from the context of step 14 there are two suspRear instances active in the model resulting in the higher model part count.

Just looking for some thoughts about how this should act/work.

Here's how I count these steps:
Step 13: part cnt 19
->less than yours because I count the u-joint as only 1 part
Step 14: part cnt 0
->because I count only parts that exist in the final model
Step 15: part cnt 345
->340 in the suspRear submodel, plus the 5 new parts
Step 16: part cnt 5
->now we're just back to normal, non-buffered building

These are all step part counts. The model count should be always static, in my opinion (but perhaps this could be user-selectable). Likewise, when I count parts per step, I'm only interested in those that contribute to the final total, so I don't count any that will be hidden by buffer exchange. (But I don't think it's wrong for LDCad to count them; obviously if there are parts in a step, you don't want to call it zero!)

As for the static model count, that's what LDCad does currently, and I think it's fine as long as it doesn't double-count parts that should be hidden in a buffer exchange. But I also don't feel it's wrong to do the variable model count as you have it now. Only thing is, shouldn't the model count in step 14 also count the double instances of the five new parts added in that step?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-23, 2:34)N. W. Perry Wrote: The model count should be always static, in my opinion (but perhaps this could be user-selectable).

You are right the model count should be the same in all steps.

But the step count themselves are correct, imho, when tracking just the add changes.

To correct this (gui wise) you would need LPub meta's to force alternative part information.

I might implement some of the LPub(3d) meta's at some point, but it's to big a change for the upcoming Alpha 2 version.

Thanks for your insight.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-23, 16:42)Roland Melkert Wrote: You are right the model count should be the same in all steps.

But the step count themselves are correct, imho, when tracking just the add changes.

To correct this (gui wise) you would need LPub meta's to force alternative part information.

I might implement some of the LPub(3d) meta's at some point, but it's to big a change for the upcoming Alpha 2 version.

Thanks for your insight.

I agree. The only reason I'm counting this way is because of the double-counting of hidden parts. Since that's fixed, I won't need to anymore. :-)

(And to be honest, most official models don't have a build structure so weird as 8448!)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#61
Lately I've been using more and more Stud.io Part Designer to add several decorations to parts. Unfortunately LDCad can't render the produced parts. 

I've read this post from 2019:

https://forums.ldraw.org/thread-23400.html

From what I understand, what Part Designer does is converting the applied image (must be PNG) to Base64 and add it to a META command PE_TEX_INFO. This is very similar to LDraw texmap.

@Roland, would you think that it would be possible to add to LDCad in the future the possibility to parse this command and therefore load decorated parts created with Part Designer?

Thank you.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#62
While Roland is certainly free to do whatever he wants, I'd much rather see Stud.io change use the official METAs for this purpose. Given Bricklink's past track record in cooperating with other community projects, I'm not gonna hold my breath for that to happen though.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#63
(2021-12-10, 16:11)Orion Pobursky Wrote: While Roland is certainly free to do whatever he wants, I'd much rather see Stud.io change use the official METAs for this purpose. Given Bricklink's past track record in cooperating with other community projects, I'm not gonna hold my breath for that to happen though.

I agree with Orion on this.

I'm not saying I will never support it, but it is very low on my to do list.

Technically speaking their LDraw export should convert those meta's into TEXMAP ones.

Especially since their internal format is already LDraw (the thing I dislike the most of studio is the fact most of its users don't even know it's secretly LDraw to begin with).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#84
(2021-12-10, 20:21)Roland Melkert Wrote: I agree with Orion on this.

I'm not saying I will never support it, but it is very low on my to do list.

Technically speaking their LDraw export should convert those meta's into TEXMAP ones.

Especially since their internal format is already LDraw (the thing I dislike the most of studio is the fact most of its users don't even know it's secretly LDraw to begin with).

I believe that Lasse D's Sticker Builder and Pattern folder work with the LDraw standard.
https://brickhub.org/i/apps/sticker_builder.htm
https://brickhub.org/i/apps/pf.htm

Is that correct? I dont have a windows computer to test on currently.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#86
(2022-03-10, 2:02)Cam's Bricks Wrote: I believe that Lasse D's Sticker Builder and Pattern folder work with the LDraw standard.
https://brickhub.org/i/apps/sticker_builder.htm
https://brickhub.org/i/apps/pf.htm

Is that correct? I dont have a windows computer to test on currently.

They use the general LDraw format, but the texture lines use the studio extension.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#64
(2021-07-16, 23:00)Roland Melkert Wrote: </snip>

All feedback/bug reports are welcome.

I am experiencing what appears to be a bug with not being able to zoom in using the '+' key. The '+' key on my numeric keypad will zoom in and the '-' key on my numeric keypad and non-numeric (i.e. normal) keypad zoom out but the '+ on my non-numeric keypad does not zoom the camera in.

Is anyone else experiencing this?

Regards.

David
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#65
(2022-02-08, 6:25)David Manley Wrote: I am experiencing what appears to be a bug with not being able to zoom in using the '+' key. The '+' key on my numeric keypad will zoom in and the '-' key on my numeric keypad and non-numeric (i.e. normal) keypad zoom out but the '+ on my non-numeric keypad does not zoom the camera in.

Is anyone else experiencing this?

Regards.

David

Actually, yes, now that you mention it. I recently bought a Bluetooth keyboard (with numpad) because the built-in keyboard in my laptop (without numpad) stopped working. When I did that, I started to get behavior like you describe.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#66
(2022-02-08, 6:25)David Manley Wrote: The '+' key on my numeric keypad will zoom in and the '-' key on my numeric keypad and non-numeric (i.e. normal) keypad zoom out but the '+ on my non-numeric keypad does not zoom the camera in.

(2022-02-08, 14:02)N. W. Perry Wrote: Actually, yes, now that you mention it. I recently bought a Bluetooth keyboard (with numpad) because the built-in keyboard in my laptop (without numpad) stopped working. When I did that, I started to get behavior like you describe.

This is probably because it samples shift+'+' instead of just '+'.

You can fix it by changing the key assignment for zoom to shift+'+'.

I'll have to look into how to detect this, but it is low on my todo list.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#67
(2022-02-08, 20:01)Roland Melkert Wrote: This is probably because it samples shift+'+' instead of just '+'.

You can fix it by changing the key assignment for zoom to shift+'+'.

I'll have to look into how to detect this, but it is low on my todo list.

I had a similar problem with, I believe, the \ key, which is also duplicated on the numpad. For whatever reason, the built-in keyboard recognizes those keys as if they come from the non-existent numpad, but the external keyboard does not.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#68
(2022-02-08, 23:27)N. W. Perry Wrote: I had a similar problem with, I believe, the \ key, which is also duplicated on the numpad. For whatever reason, the built-in keyboard recognizes those keys as if they come from the non-existent numpad, but the external keyboard does not.

You mean '/' which is on the keypad, and has a 'non shift' key on most keyboards.

It's together with '?' on mine, so a hot key using '?' wouldn't work as it will cause as SHIFT+'?' for me.

'\' is not on my numpad, it's only together with '|' above the enter key on my keyboard. So in my situation '|' won't work only SHIFT+'|'.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#69
(2022-02-09, 0:17)Roland Melkert Wrote: You mean '/' which is on the keypad, and has a 'non shift' key on most keyboards.

It's together with '?' on mine, so a hot key using '?' wouldn't work as it will cause as SHIFT+'?' for me.

'\' is not on my numpad, it's only together with '|' above the enter key on my keyboard. So in my situation '|' won't work only SHIFT+'|'.

Yes, sorry, I meant the forward slash "/".
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#71
(2022-02-09, 0:17)Roland Melkert Wrote: You mean '/' which is on the keypad, and has a 'non shift' key on most keyboards.

It's together with '?' on mine, so a hot key using '?' wouldn't work as it will cause as SHIFT+'?' for me.

'\' is not on my numpad, it's only together with '|' above the enter key on my keyboard. So in my situation '|' won't work only SHIFT+'|'.

I've looked into this a little more, and it turns out that for me, it's not '+' that's the problem, it's '='. I cannot assign that key to a hotkey combination for some reason. If I assign SHIFT+'+' (which is really SHIFT+'='), then the main pad + key works. If I assign just '+', then the number pad + key works. But if I press the Sample button and hit = (without SHIFT), nothing happens. I don't happen to need this combo myself, but it is common to use = without SHIFT as a zoom in shortcut.

My issue with '/' turns out to be something else altogether: I was assigning this to collapse nodes in the Source window (this didn't previously have a hotkey assignment), and I didn't realize that to collapse the current node, you must first re-select that line, even if it's already selected. That may be by design, although it feels like a bug.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#72
(2022-02-11, 14:57)N. W. Perry Wrote: I've looked into this a little more, and it turns out that for me, it's not '+' that's the problem, it's '='. I cannot assign that key to a hotkey combination for some reason. If I assign SHIFT+'+' (which is really SHIFT+'='), then the main pad + key works. If I assign just '+', then the number pad + key works. But if I press the Sample button and hit = (without SHIFT), nothing happens. I don't happen to need this combo myself, but it is common to use = without SHIFT as a zoom in shortcut.
It seems I didn't add the '=' (nor '\') to the key list at all Big Grin


(2022-02-11, 14:57)N. W. Perry Wrote: My issue with '/' turns out to be something else altogether: I was assigning this to collapse nodes in the Source window (this didn't previously have a hotkey assignment), and I didn't realize that to collapse the current node, you must first re-select that line, even if it's already selected. That may be by design, although it feels like a bug.
This is indeed a bug.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#98
(2022-02-11, 18:56)Roland Melkert Wrote: This is indeed a bug.

Finally got around to fixing this bug, but it turns out not to be a bug Smile

It expand/collapses the current 'hot' node (meaning the one under the mouse cursor) not the selected one.

I did change the hint to reflect this though.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#70
(2022-02-08, 20:01)Roland Melkert Wrote: This is probably because it samples shift+'+' instead of just '+'.

You can fix it by changing the key assignment for zoom to shift+'+'.

I'll have to look into how to detect this, but it is low on my todo list.

Thanks Roland, shift + '+' worked. That combination is obvious now that I think about it.

David
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#73
I can't remember if I've mentioned this before, but have you ever considered a way to view (if not also edit) the unaltered source of a file? This could be either as a "verbose" option for the source window, or maybe as a separate console window.

Right now I have to use an external editor, and there's no way to "poll" between the two programs. Also, the standard text editor on the Mac does not have a "reload" command (which is its own fault, of course), so I have to manually close and re-open the text file to see changes made in LDCad.

The types of source I most often need to see are a) group information, and b) exact dimensions of generated flexible parts, both of which I know have come up as possible features on their own. But it's also helpful sometimes to be able to quickly find something in an MPD file by using a text search, for example.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#74
(2022-02-17, 18:30)N. W. Perry Wrote: I can't remember if I've mentioned this before, but have you ever considered a way to view (if not also edit) the unaltered source of a file? This could be either as a "verbose" option for the source window, or maybe as a separate console window.

Right now I have to use an external editor, and there's no way to "poll" between the two programs. Also, the standard text editor on the Mac does not have a "reload" command (which is its own fault, of course), so I have to manually close and re-open the text file to see changes made in LDCad.

The types of source I most often need to see are a) group information, and b) exact dimensions of generated flexible parts, both of which I know have come up as possible features on their own. But it's also helpful sometimes to be able to quickly find something in an MPD file by using a text search, for example.

Group information is missing because it has a fairly complicated maintenance scheme. So in practice they are just fully regenerated upon save.

Flex dimensions are visible in 1.7 Alpha as part of the coordinate panel.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#75
Minor typo in the hotkey config file:
Code:
edtiSes_selRemoveRedir=

Probably only affects human readability…
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#76
(2022-03-03, 18:18)N. W. Perry Wrote: Minor typo in the hotkey config file:
Code:
edtiSes_selRemoveRedir=

Probably only affects human readability…

It is the 'remove redirections from selection' function, so I think it has the correct spelling unless I missing something.

It removes alias/coloured/moved/etc parts by replacing them with their targets.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#77
edti  should maybe be  edit ?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#78
(2022-03-03, 23:03)Magnus Forsberg Wrote: edti  should maybe be  edit ?

Didn't even noticed that Big Grin

I will fix that but it would revert to the default binding for anyone who ever changed it.

But I doubt that has been done often.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#79
(2022-03-03, 23:34)Roland Melkert Wrote: Didn't even noticed that Big Grin

I will fix that but it would revert to the default binding for anyone who ever changed it.

But I doubt that has been done often.

I only noticed that because I was going through my hotkeys manually and it was out of alphabetical order. Big Grin

I realized you can learn a lot about LDCad's capabilities by going through the possible hotkey commands…
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#80
(2022-03-04, 3:44)N. W. Perry Wrote: I realized you can learn a lot about LDCad's capabilities by going through the possible hotkey commands…

The hotkey dialog lists the same items, should be more readable Smile
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#81
(2022-03-04, 19:49)Roland Melkert Wrote: The hotkey dialog lists the same items, should be more readable Smile

True, although I found I can more easily search for duplicates across all the groups in the config file. The dialog only shows duplicates within each group. Also, some of the short names in the config file give an extra clue as to their function, especially for those that are similar.

By the way, if anyone is a Mac user and would like my hotkeys file, let me know. Mostly I've changed most instances of CTRL to ALT (which is CMD on the Mac) and changed INS to SPACE. (This is because the Mac has no Insert key, but also I've found I really dig inserting pieces with the space bar!)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#82
EDIT: see post below
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#83
EDIT: see post below
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#85
(2021-07-16, 23:00)Roland Melkert Wrote: 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.

Forgive my ignorance, but is it not possible to install the linux version on mac? I see some threads about using wine and will look into those soon but just had a high level thought about implementation and thought I would ask.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#87
(2022-03-10, 2:13)Cam's Bricks Wrote: Forgive my ignorance, but is it not possible to install the linux version on mac? I see some threads about using wine and will look into those soon but just had a high level thought about implementation and thought I would ask.

There is currently no native apple version, mostly because I don't use any apple product myself.

The WINE approach seems to work for most people though.

Alternative would be to dual boot into Linux (using a live ISO on usb thumbdrive if needed) or maybe parallels (never tried that but it seems logical).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#88
(NOTE: New stuff is at the end. I realized I made a lot of suggestions scattered around different replies, so this is mainly just to consolidate them in one post.)

Bugs/issues:

Copy/paste settings
  • There are 10 options in the copy/paste dialog but I only found 9 in the config file. The missing one appears to be "copyStripNonVis" (although this does appear to work in the GUI…?).
Hotkeys dialog
  • In edit placement control group: "Negative 54 degree rotation around Z-axis" (all the others correctly say "45 degree").
(By the way, is it me or are (ctrl+)right and left key descriptions opposite of what they really do (pos and neg Y rotation)? I've had to switch these to get the results I expect.)
  • In all the editing pin groups, "Negative movement on the current dead plane axis" seems to always be in the wrong subgroup (Center instead of Movement).
  • I'd like to be able to assign a hotkey to the apostrophe '  but it doesn't recognize it (cmd+' is standard for bringing up a prefs menu).
Animation playback issue moved to new thread.

Feature suggestions:

Paths
  • When dragging a bezier handle, could we maybe shift+drag to simultaneously change the following/preceding handle also? This would allow symmetrical reshaping. (Idea stolen from Inkscape.)
Editing
  • It would be very handy to have a 1-click rotation to that special value of 53.1301/36.8699 degrees (the 0.6 0.8 matrix), which is so central to Technic building. A grid stepping in this amount would be interesting, but I know these should really add up to 360, so maybe this is macro territory? Or maybe the manual rotation dialog could have radio buttons with these and certain other special angles (or even user-defined "favorite" angles)? <- I think the "favorites" idea is my favorite so far. Smile
Header dialog
  • This is very, very tiny…but maybe also trivial to fix. When opening the header dialog and switching to the "tags" tab, there is consistently a delay of 2-3 seconds while, I assume, the category and keywords lists are loaded. Maybe these lists should be loaded only when/if they are opened? because 99 times out of 100, I only go to that tab to set the file type (model, part, unofficial etc.) and don't need those drop-down lists at all.

    On the other hand, for the same reason, maybe the file type meta should be moved to the main page of the header dialog, because its official placement is in the main part of the header? Better still, could it be possible to set a default for the file type?
Rotation steps (NEW)
  • If a ROTSTEP meta appears at the end of a file, could there be an option for LDCad not to add an extra step number? That way, if the last step of a model has a rotation (or cancels a previous rotation), we can use the ROTSTEP function to display it correctly without having an extra blank step at the end of the model.
In the future (NEW):
I just realized that if LDCad 2.0 does come to pass, and if it does support all LPub metas as had been considered, then that means it will support BUILD_MOD, which is essentially identical to the FLOAT meta idea I've been wishing for for so long. Big Grin Big Grin Big Grin

If this is the case, I wonder if it would be possible (either as a user-configurable setting, or perhaps as an option in file cleanup) to comment out the type 1 lines between the BUILD_MOD BEGIN and BUILD_MOD END_MOD tags—in other words, the parts that exist in their temporary state? That way, the file that LDCad saves would contain no duplicate parts nor any helper parts, and thus be immediately viewable in LDView, Stud.io, etc. At the same time, LDCad would still display these commented lines during its own editing sessions.

In fact, at the risk of wishful thinking, this sounds simple enough, and fixes such a long-standing problem, that maybe BUILD_MOD might be able to appear in the nearer future than other LPub metas…? (And it might even be possible to do with the existing BUFEXCHG commands, too…)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#89
(2022-03-19, 18:12)N. W. Perry Wrote: hen dragging a bezier handle, could we maybe shift+drag to simultaneously change the following/preceding handle also? This would allow symmetrical reshaping. (Idea stolen from Inkscape.)
I like this idea, i will look into it for the next next version (Alpha 3/Beta 1)


(2022-03-19, 18:12)N. W. Perry Wrote: It would be very handy to have a 1-click rotation to that special value of 53.1301/36.8699 degrees (the 0.6 0.8 matrix), which is so central to Technic building. A grid stepping in this amount would be interesting, but I know these should really add up to 360, so maybe this is macro territory? Or maybe the manual rotation dialog could have radio buttons with these and certain other special angles (or even user-defined "favorite" angles)? <- [i]I think the "favorites" idea is my favorite so far. Smile
Favorite angles could be an interesting feature. It could be done with macro's too tough as you can assign hotkeys to macro's.


(2022-03-19, 18:12)N. W. Perry Wrote: This is very, very tiny…but maybe also trivial to fix. When opening the header dialog and switching to the "tags" tab, there is consistently a delay of 2-3 seconds while, I assume, the category and keywords lists are loaded. Maybe these lists should be loaded only when/if they are opened? because 99 times out of 100, I only go to that tab to set the file type (model, part, unofficial etc.) and don't need those drop-down lists at all.
I'll have to check but I'm fairly sure (some of) those lists are already loaded on demand. The issue is mainly caused by wxWidgets extremely slow list updates (even when you suppress screen updates), which might be addressed in one of their later builds.


(2022-03-19, 18:12)N. W. Perry Wrote: If a ROTSTEP meta appears at the end of a file, could there be an option for LDCad not to add an extra step number? That way, if the last step of a model has a rotation (or cancels a previous rotation), we can use the ROTSTEP function to display it correctly without having an extra blank step at the end of the model.[/list]
This is mostly a LDraw format problem as the step meta indicates the END of a step so there are always (step meta count + 1) steps in a model.
The step must be counted or you wouldn't be able to navigate (back) to the last step.
Could hide it in view mode though, but not sure if that's really worth all the hassle.


(2022-03-19, 18:12)N. W. Perry Wrote: If this is the case, I wonder if it would be possible (either as a user-configurable setting, or perhaps as an option in file cleanup) to comment out the type 1 lines between the BUILD_MOD BEGIN and BUILD_MOD END_MOD tags—in other words, the parts that exist in their temporary state? That way, the file that LDCad saves would contain no duplicate parts nor any helper parts, and thus be immediately viewable in LDView, Stud.io, etc. At the same time, LDCad would still display these commented lines during its own editing sessions.
There is a macro which does something very similar with the MLCad HIDE meta, maybe you can adapt that?


(2022-03-19, 18:12)N. W. Perry Wrote: In fact, at the risk of wishful thinking, this sounds simple enough, and fixes such a long-standing problem, that maybe BUILD_MOD might be able to appear in the nearer future than other LPub metas…? (And it might even be possible to do with the existing BUFEXCHG commands, too…)
2.0 is very unlikely to be picked up anytime soon given I hardly get to work on 1.7 these days.

The main reason I started a 1.7 is because 2.0 is nowhere near where I wanted it to be.

it's basically just an pseudo HTML 'div' orientated GUI rendering engine at the moment.
   

Don't mind the childish look, it uses hand drawn 'test' textures.

That said the new LPub build mod meta are very interesting so I might support them in 1.7 beta 1/2 depending on how hard they are to implement.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#90
(2022-03-19, 20:24)Roland Melkert Wrote: Favorite angles could be an interesting feature. It could be done with macro's too tough as you can assign hotkeys to macro's.

Indeed, although I think the favorites idea might be good enough to offer out of the box. (An extension of this idea might be "project parameters", where the user could select certain often-used values, like colors, rotation angles, etc. that are common to a specific model. But LDCad doesn't really work with project files, so this might be too much.)

(2022-03-19, 20:24)Roland Melkert Wrote: I'll have to check but I'm fairly sure (some of) those lists are already loaded on demand. The issue is mainly caused by wxWidgets extremely slow list updates (even when you suppress screen updates), which might be addressed in one of their later builds.

The more I think about it, it seems that allowing a default setting for the file type is probably the simplest/best. In fact, I think this might have even been a planned feature at one point. And it makes sense, since LDCad is an editor, that most files created by the user will be models by default (and then maybe you could have a check box for whether to add the LDRAW_ORG qualifier).

(2022-03-19, 20:24)Roland Melkert Wrote: This is mostly a LDraw format problem as the step meta indicates the END of a step so there are always (step meta count + 1) steps in a model.
The step must be counted or you wouldn't be able to navigate (back) to the last step.
Could hide it in view mode though, but not sure if that's really worth all the hassle.

Yes, or in this case, STEP meta + ROTSTEP meta + 1. Because I guess the ROTSTEP meta, what, takes the place of a STEP meta in the parser? My idea was that if a ROTSTEP meta (or even a regular STEP meta) occurs at the end of a file—i.e., has no geometry lines following it—then it could be excluded from the count, or alternately take the place of the +1. That way, the only step that wouldn't be counted is the empty extra one at the end, which is just what you'd want anyway.

I know this is a quirk of the LDraw spec, and of course you shouldn't have to re-work your program to account for its shortcomings. But then again, is the last step of a file required not to have a STEP meta, or just allowed not to? Because it seems to me that the last STEP meta of a file only indicates the end of the last step—not the existence of an additional step after it (you'd need to add at least one more part or something to imply that). But I also know that it might be a necessity of the coding process to be able to count the steps correctly.

(2022-03-19, 20:24)Roland Melkert Wrote: There is a macro which does something very similar with the MLCad HIDE meta, maybe you can adapt that?

Perhaps…although the difference is that these would be lines between two metas, and I think the MLCad metas affect only single lines? I could probably figure it out, though.

Thinking about it some more, all that's really necessary would be a commenting out function. You could select some lines in the source and window and just choose "comment out" from a menu. Or, you could have it configurable, where you have a dialog that gives you the option of commenting out all lines that either follow a specific meta (such as MLCAD HIDE or MLCAD GHOST), or are between two given metas (like BUFEXCHG STORE/RETRIEVE or BUILD_MOD BEGIN/END_MOD). Basically, a bunch of boolean options.

Though I do wish that BUILD_MOD (and BUFEXCHG, for that matter) had the fallback built in, so that other tools wouldn't have to adapt to them…

(2022-03-19, 20:24)Roland Melkert Wrote: That said the new LPub build mod meta are very interesting so I might support them in 1.7 beta 1/2 depending on how hard they are to implement.

I think they are definitely worth exploring, independently of whether you eventually support all of LPub's metas—which are very very many, as you know, and not all of them are of particular importance to an editing program.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#91
(2022-03-19, 20:24)Roland Melkert Wrote: That said the new LPub build mod meta are very interesting so I might support them in 1.7 beta 1/2 depending on how hard they are to implement.

The only downfall for that is that the develoment of LPub3D has again came to a stop some time ago.
I am uncertain of Trevor is still developing since I have lost contact with him too. I also have no idea if he reads the forums or comments in his Github page for LPub3D :-(

Does anyone have an idea where Trevor is and has contact with him?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#92
(2022-03-20, 15:35)Jaco van der Molen Wrote: The only downfall for that is that the develoment of LPub3D has again came to a stop some time ago.
I am uncertain of Trevor is still developing since I have lost contact with him too. I also have no idea if he reads the forums or comments in his Github page for LPub3D :-(

Does anyone have an idea where Trevor is and has contact with him?

His most recent post here was a year and some days ago, and the most recent updates to LPub3D appear to have been the October before that (2020).
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#93
(2022-03-21, 1:08)N. W. Perry Wrote: His most recent post here was a year and some days ago, and the most recent updates to LPub3D appear to have been the October before that (2020).

Indeed. I was helping him test the buildmod feature, but suddenly all went silence.
It was (is) a very promising feature and we got things to work quite nice.
Still a few bugs here and there though.

I have tried to contact him, but he is not responding to e-mail, PM or Github messages.
I sincerly hope he is allright.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#94
(2022-03-21, 12:28)Jaco van der Molen Wrote: Indeed. I was helping him test the buildmod feature, but suddenly all went silence.
It was (is) a very promising feature and we got things to work quite nice.
Still a few bugs here and there though.

I have tried to contact him, but he is not responding to e-mail, PM or Github messages.
I sincerly hope he is allright.

I hope so too!
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-03-19, 18:12)N. W. Perry Wrote: It would be very handy to have a 1-click rotation to that special value of 53.1301/36.8699 degrees (the 0.6 0.8 matrix), which is so central to Technic building. A grid stepping in this amount would be interesting, but I know these should really add up to 360, so maybe this is macro territory?

I rewrote the rotation pin handling to allow for angles which do not add up to 360 degrees.

As a result it is now also possible to do free hand rotation using the pin.

Do you know of any other useful ones besides the 53.13 one (for use in the default grid) ?

I'm also thinking about supporting alternative notation for the grid angles (like "asin 0.8" instead of 53.13 or fractions like "100/3")

This way the value will have double precision in memory.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-27, 1:07)Roland Melkert Wrote: I rewrote the rotation pin handling to allow for angles which do not add up to 360 degrees.

As a result it is now also possible to do free hand rotation using the pin.

Do you know of any other useful ones besides the 53.13 one (for use in the default grid) ?

I'm also thinking about supporting alternative notation for the grid angles (like "asin 0.8" instead of 53.13 or fractions like "100/3")

This way the value will have double precision in memory.

Maybe there's another useful angle in one of the other Pythagorean integer triangles, but 53.13 is the only one I've found so far. (If there is another, it's probably in this article).

While on the subject of rotations and precision, I thought it might also be cool to be able to reset the rotation of a part in the editing plane only. This would be especially helpful for path points, which usually don't want to be reset to the global axes.

And/or, it might be neat if you could "snap to grid" for rotations—i.e., to round the matrix to the nearest rotation step value, as a way of clearing out rounding errors after multiple rotations. (Maybe this already happens under the hood…)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-27, 3:56)N. W. Perry Wrote: While on the subject of rotations and precision, I thought it might also be cool to be able to reset the rotation of a part in the editing plane only. This would be especially helpful for path points, which usually don't want to be reset to the global axes.
Do you mean using just 2 dimensions? as ctrl+home already takes the relative grid into account.

(2022-04-27, 3:56)N. W. Perry Wrote: And/or, it might be neat if you could "snap to grid" for rotations—i.e., to round the matrix to the nearest rotation step value, as a way of clearing out rounding errors after multiple rotations. (Maybe this already happens under the hood…)
Also just in 2D? Could be handy, I'll put it on my next version's todo as I'm (finally) close to finishing the Alpha 2's todo list Big Grin
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-27, 19:05)Roland Melkert Wrote: Do you mean using just 2 dimensions? as ctrl+home already takes the relative grid into account.

Also just in 2D? Could be handy, I'll put it on my next version's todo as I'm (finally) close to finishing the Alpha 2's todo list  Big Grin

Yes, in 2D for both ideas. For example, if want to un-rotate a path point, but still have its Y-axis point along the path as it's supposed to. Ctrl+home will make the Y-axis vertical. Also useful for tinkering with Technic assemblies.

I guess in most cases, it's not really resetting the rotation, but just rounding to the nearest 90-degree matrix.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
As an extension/companion to this idea, it would be neat to have an option in the part properties dialog to display the orientation as Euler angles alongside the matrix. I constantly use this tool to find out what angles were used to rotate a part to its current orientation; perhaps it would be no big deal to incorporate the same math?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-05-09, 15:58)N. W. Perry Wrote: As an extension/companion to this idea, it would be neat to have an option in the part properties dialog to display the orientation as Euler angles alongside the matrix. I constantly use this tool to find out what angles were used to rotate a part to its current orientation; perhaps it would be no big deal to incorporate the same math?

I'll put it on the Beta 1 todo list, as I'm (finally) in the testing phase of Alpha 2 Smile
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-05-10, 21:18)Roland Melkert Wrote: I'll put it on the Beta 1 todo list, as I'm (finally) in the testing phase of Alpha 2 Smile

Big +1 here
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#95
This looks like a bug specific to 1.7: The config file is set to 8 decimal places on the clipboard, but I'm consistently getting only 5 when copying values from selection info. I definitely got more decimal places in 1.6d.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#96
(2022-03-24, 4:22)N. W. Perry Wrote: This looks like a bug specific to 1.7: The config file is set to 8 decimal places on the clipboard, but I'm consistently getting only 5 when copying values from selection info. I definitely got more decimal places in 1.6d.

The setting is only for ldraw coordinates but I suppose it is logical to also use it for selection information.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#97
(2022-03-24, 18:36)Roland Melkert Wrote: The setting is only for ldraw coordinates but I suppose it is logical to also use it for selection information.

Never mind, my mind is going haywire. I was sure that there used to be more digits in 1.6, but indeed it captures only 5.

That said, with the default coord precision increased to 6 decimals, it would make sense to capture at least 6 for measured distances, also. (I'm not sure offhand how many decimal places would be necessary for angles to match the precision of the rotation matrix.)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
#99
(2022-04-10, 19:22)Roland Melkert Wrote: Finally got around to fixing this bug, but it turns out not to be a bug Smile

It expand/collapses the current 'hot' node (meaning the one under the mouse cursor) not the selected one.

I did change the hint to reflect this though.

Ah, perhaps that behavior will make more sense now!

Here's another thing: it seems like nag message states are not being retained for warnings about shadow editing. I know there are 2 or 3 different messages, but I feel like I've checked "don't show again" on all of them repeatedly, yet they keep appearing.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-10, 22:21)N. W. Perry Wrote: Here's another thing: it seems like nag message states are not being retained for warnings about shadow editing. I know there are 2 or 3 different messages, but I feel like I've checked "don't show again" on all of them repeatedly, yet they keep appearing.

Some of those messages will ask again the next time you start the program by design.

Mostly because they can cause unexpected behavior during usage.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-11, 18:45)Roland Melkert Wrote: Some of those messages will ask again the next time you start the program by design.

Mostly because they can cause unexpected behavior during usage.

Is that true more in 1.7 than 1.6? Only because it's definitely much more common in the alpha.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-11, 22:36)N. W. Perry Wrote: Is that true more in 1.7 than 1.6? Only because it's definitely much more common in the alpha.

I haven't changed this in 1.7 (Don't see something obvious in svn history ether).

Only these should ask again, all others are stored in the ini:

- select all while in nesting mode.
- save zipped content.
- edit zipped content.
- glTF animation export.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-12, 17:48)Roland Melkert Wrote: I haven't changed this in 1.7 (Don't see something obvious in svn history ether).

Only these should ask again, all others are stored in the ini:

- select all while in nesting mode.
- save zipped content.
- edit zipped content.
- glTF animation export.

Those are definitely the ones I mean (well, haven't tried the gITF export). Come to think of it, I am using more zipped locations than before, so maybe that's all it is.

Do you have a recommended way of updating shadow info for official files, other than unzipping the official shadow library (and thus risking overwrite when updates are installed)?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-12, 18:32)N. W. Perry Wrote: Do you have a recommended way of updating shadow info for official files, other than unzipping the official shadow library (and thus risking overwrite when updates are installed)?

Not sure what you mean, unpacking the .sf/.csl file prevents overwriting as the update process only replaces the .sf file which will be unpacked by the main exe if it is newer then the last unpack date.

Loose .dat shadow files are never overwritten.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-12, 18:48)Roland Melkert Wrote: Not sure what you mean, unpacking the .sf/.csl file prevents overwriting as the update process only replaces the .sf file which will be unpacked by the main exe if it is newer then the last unpack date.

Loose .dat shadow files are never overwritten.

I guess I just mean, if I want to use the newest .sf file but also keep any changes I've made to official files. In the past, my process has always been to use the .csl archive as my official shadow library, until I need to change something. Then I unpack it, make changes, and use the upacked directory as my shadow library until a new .sf file is available. Then I switch back to the updated .csl archive and hope everything lines up.

But I believe it's not possible to have two shadow locations for the same library, right? For example, the .csl archive for all the "official" shadow files, plus a directory of loose .dat files with my own changes?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
Hey Roland,

I am interested to know if some stepping scripts or buttons can be added? Only of the only features of Studio I find implemented well is the instructions stepping. 

Here is a quick screen shot to show what I am after.
[Image: mjhs17X.png]

In the screen shot you can see that I am on step 2 and I can see a wireframe of the blue brick in step 1 and the yellow brick from step 3 is not shown. There are also two buttons at the bottom that allow me to take a selection of parts and add them to a new step before or after the current step. 

Would it be possible to have scripts with button or a stepping toolbar that would have some of these actions on it?

Is it possible to show the previous steps in a faded and//or wire frame method? 

I know this next piece is possible but it would be nice to have it as a button on a tool bar?

If I select more than one part, I also have the option create a sub model from those parts.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-14, 0:50)Cam's Bricks Wrote: I am interested to know if some stepping scripts or buttons can be added? Only of the only features of Studio I find implemented well is the instructions stepping. 
....
Is it possible to show the previous steps in a faded and//or wire frame method? 
....
If I select more than one part, I also have the option create a sub model from those parts.

Currently stepping only controls visibility of parts.
There are special bin groups you can use to see the newly added parts etc though (just like in booklets).

Adding the selection to a new submodel can be done using the selection/reorganize menu.

All clickable actions in the menus can be added to the toolbar using its configuration dialog (right click on the menu bar).

   

But there is currently no icon for the create submodel action, you could make one yourself if you wanted though.

For this add a "editSes_selMove2Sf.png" to the "gui/default/menuBar" folder.

It would probably be just as good to set a hotkey for this action if you need it often.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-14, 17:40)Roland Melkert Wrote: But there is currently no icon for the create submodel action, you could make one yourself if you wanted though.

For this add a "editSes_selMove2Sf.png" to the "gui/default/menuBar" folder.

It would probably be just as good to set a hotkey for this action if you need it often.

I can add this. I may look into scripting up some stepping functions but I am sure I will be back for more questions.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
New report about 1.7 this morning, I un-zipped the Win version and started the 64-bit program. I pointed it to my LDraw directory and its going on 30 minutes of the loading splash screen. is this normal?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-18, 13:40)Cam's Bricks Wrote: New report about 1.7 this morning, I un-zipped the Win version and started the 64-bit program. I pointed it to my LDraw directory and its going on 30 minutes of the loading splash screen. is this normal?

Not at all, the splash should be only visible for a few seconds.

I have never heard of this issue before, could you mail me the contents of the 'logs' folder?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-18, 18:45)Roland Melkert Wrote: Not at all, the splash should be only visible for a few seconds.

I have never heard of this issue before, could you mail me the contents of the 'logs' folder?

I have just sent the email now.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-18, 19:39)Cam's Bricks Wrote: I have just sent the email now.

It seems to crash/hang during reading of the part files.

Which library are you using?

Does it hang/crash again when you just retry?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-18, 21:03)Roland Melkert Wrote: It seems to crash/hang during reading of the part files.

Which library are you using?

Does it hang/crash again when you just retry?

A retry didnt work. 

I deleted the instance of LDCad and made fresh library location using the complete.zip and unofficial zip. That loaded a model one time then it was red crosses loading further parts. 

Then I unzipped the libraries and I am back to not moving past the splash screen.

I have attached my logs here for you.


Attached Files
.txt   logFile-2022-04-19-10-15-28.txt (Size: 16.15 KB / Downloads: 2)
.txt   logFile-2022-04-19-10-16-07.txt (Size: 16.15 KB / Downloads: 3)
.txt   logFile-2022-04-19-12-57-55.txt (Size: 16.15 KB / Downloads: 3)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-19, 17:00)Cam's Bricks Wrote: A retry didnt work. 

I deleted the instance of LDCad and made fresh library location using the complete.zip and unofficial zip. That loaded a model one time then it was red crosses loading further parts. 

Then I unzipped the libraries and I am back to not moving past the splash screen.

I have attached my logs here for you.

Those logs are all the same (apart from timestamps).

You could try to use the library packed by selecting the folder holding complete.zip when asked to select the library folder.

Also if you want to use a second library you should place it in its own top level folder (LDCad does not officially support a library which lives inside another library's location).

The next Alpha will automatically also use the unofficial folder if present though.


Very strange things are going on here though, anyone else had similar problems with 1.7?

Could you please also try 1.6d to make sure this isn't 1.7 specific thing.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-19, 18:45)Roland Melkert Wrote: Those logs are all the same (apart from timestamps).

You could try to use the library packed by selecting the folder holding complete.zip when asked to select the library folder.

Also if you want to use a second library you should place it in its own top level folder (LDCad does not officially support a library which lives inside another library's location).

The next Alpha will automatically also use the unofficial folder if present though.


Very strange things are going on here though, anyone else had similar problems with 1.7?

Could you please also try 1.6d to make sure this isn't 1.7 specific thing.

Isn’t this a google drive thing?
Judging by the paths I conclude your LDraw installation is on Google Drive sync and virtual drive letter? Does LDCad has write permission on drive G: ?

I experienced similar issues with other software I tried to use from such a Google Drive Sync drive and folders.

Try to copy the whole thing to your main C: drive?
That’s where I have all LDraw software running smooth as an androids butt.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-19, 20:18)Jaco van der Molen Wrote: Isn’t this a google drive thing?
Judging by the paths I conclude your LDraw installation is on Google Drive sync and virtual drive letter? Does LDCad has write permission on drive G: ?

This seems to be the issue. It is working when moved to a non-google drive directory. 

Next issue is that the color bin files are present but there the color wheel in LDCad says "missing" for all colors. This is for both 1.6d and 1.7
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-20, 18:21)Cam's Bricks Wrote: Next issue is that the color bin files are present but there the color wheel in LDCad says "missing" for all colors. This is for both 1.6d and 1.7

Like this:

.png   nocol.png (Size: 7.87 KB / Downloads: 140)

If so it sounds like a missing or weird LDConfig.ldr

This file is usually in the official library's root folder.

You can select a different one using the "prefs/ldraw/configuration files" menu.

Or maybe it got confused resulting from the files move (assuming you didn't just reinstall).

If so just delete the whole config folder to force a re-ask/scan of the library location.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-19, 20:18)Jaco van der Molen Wrote: Isn’t this a google drive thing?
Judging by the paths I conclude your LDraw installation is on Google Drive sync and virtual drive letter? Does LDCad has write permission on drive G: ?

Thanks Jaco, I didn't think of this as I don't use google drive. But I do have a G: drive (my steam disk) so it didn't look weird to me Smile

Do these problems only concern the program files? Or even when using it for LDraw content only?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-20, 19:11)Roland Melkert Wrote: Thanks Jaco, I didn't think of this as I don't use google drive. But I do have a G: drive (my steam disk) so it didn't look weird to me Smile

Do these problems only concern the program files? Or even when using it for LDraw content only?

I am not sure which is more problematic but the long load times were happening when the unpacked library was on the google drive but worked for a session while it was still in zip form. 

The only use case I can see for supporting/solving this issue, is that in my case, I have several computers I swtich between and always have my library on my google drive. Maintaining a local copy of the official and even unofficial library is simple in each location but any custom parts are not as easy.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-20, 19:22)Cam's Bricks Wrote: I am not sure which is more problematic but the long load times were happening when the unpacked library was on the google drive but worked for a session while it was still in zip form. 

The only use case I can see for supporting/solving this issue, is that in my case, I have several computers I swtich between and always have my library on my google drive. Maintaining a local copy of the official and even unofficial library is simple in each location but any custom parts are not as easy.

On first start LDCad will load all LDraw files to cache their headers, this means it's opening about 14000 files.

Next time it will only check for timestamps to see if anything has changed.

Both of these things will be considerable slower on a network/virtual drive.

It's also why I usually advise people to use complete.zip as is where possible as it will do everything in memory only.

On top of this LDCad also uses a boatload of user customize able configuration files, causing even more disk io.

Your models (and prop complete.zip too) etc should be perfectly happy on an net/gdrive/external source though.

I would just advise to install LDCad itself using its setup version (so it goes into program files) to minimize google drive io?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-20, 20:36)Roland Melkert Wrote: ...
On top of this LDCad also uses a boatload of user customize able configuration files, causing even more disk io.

Your models (and prop complete.zip too) etc should be perfectly happy on an net/gdrive/external source though.

I would just advise to install LDCad itself using its setup version (so it goes into program files) to minimize google drive io?

So basically just keep a local copy of complete.zip (not via google drive but in the file structure of the non-virtual drive) and then just have my own custom files and models in my google drive? 

That seems as though it will suffice. 

Thanks for your help.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-20, 20:43)Cam's Bricks Wrote: So basically just keep a local copy of complete.zip (not via google drive but in the file structure of the non-virtual drive) and then just have my own custom files and models in my google drive? 

That seems as though it will suffice. 

Thanks for your help.

Just to close my own loop, above solution worked much better. 

I have the portable version of LDCad on my local drive along with a zip copy of the complete.zip and ldrawunf.zip I then added a look up at my much smaller library of personal custom parts. 

The load times are virtually instant now. 

Thanks again for all the help.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
Thumbs Up 
(2022-04-21, 19:30)Cam's Bricks Wrote: Just to close my own loop, above solution worked much better. 

I have the portable version of LDCad on my local drive along with a zip copy of the complete.zip and ldrawunf.zip I then added a look up at my much smaller library of personal custom parts. 

The load times are virtually instant now. 

Thanks again for all the help.

Great! Smile
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-04-20, 19:11)Roland Melkert Wrote: Thanks Jaco, I didn't think of this as I don't use google drive. But I do have a G: drive (my steam disk) so it didn't look weird to me Smile

Do these problems only concern the program files? Or even when using it for LDraw content only?

I work on various PC's and laptops, but all have a local installations of all LDraw stuff.

LDConfig.ldr is on Google Drive (as is pli.mpd for use with LPub3D and a settings.ldr file I use for all my instructions)

I keep a copy of customizations to various bins for LDCad on Google Drive too.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
I feel like this might already exist, but…is there a way to reverse a path? i.e., invert the order of points, invert prev/next control distances (and roll), flip Y-axis direction, and maybe also mirror the whole thing?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-05-03, 14:06)N. W. Perry Wrote: I feel like this might already exist, but…is there a way to reverse a path? i.e., invert the order of points, invert prev/next control distances (and roll), flip Y-axis direction, and maybe also mirror the whole thing?
I think that all you want to do can be done with mirroring. You can either select all control points in nested mode (the first selected defining symmetry origin) then right click -> mirror. Or you can go to flex part submodel then session -> mirror this subfile (symmetry origin is submodel origin)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-05-03, 14:31)Philippe Hurbain Wrote: I think that all you want to do can be done with mirroring. You can either select all control points in nested mode (the first selected defining symmetry origin) then right click -> mirror. Or you can go to flex part submodel then session -> mirror this subfile (symmetry origin is submodel origin)

It doesn't seem to affect the order of path points (i.e., make the first point the last and vice vera).

This could be a relatively simple macro, I'm sure. But it would also be nice as an option in the mirror dialog, as a checkbox for "reverse path direction".
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-05-03, 15:57)N. W. Perry Wrote: It doesn't seem to affect the order of path points (i.e., make the first point the last and vice vera).
This could be a relatively simple macro, I'm sure. But it would also be nice as an option in the mirror dialog, as a checkbox for "reverse path direction".
I see what you want (change order of path points), but I fail to understand the purpose Huh . Use case?
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-05-03, 17:56)Philippe Hurbain Wrote: I see what you want (change order of path points), but I fail to understand the purpose Huh . Use case?

I have a path template that I want to append to the beginning of another path (a knot onto a string, in this case), but the template was set up to be at the end instead of the beginning.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-05-04, 3:26)N. W. Perry Wrote: I have a path template that I want to append to the beginning of another path (a knot onto a string, in this case), but the template was set up to be at the end instead of the beginning.

Could be an interesting source window feature, but as I'm down to 4 points on my todo list it will have to wait Big Grin

In the mean time you could edit the template outside LDCad to flip the !LDCAD PATH_POINT lines.

Or rearange them one by one in the source window, but you'll have to disable auto grouping first.
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
(2022-05-04, 18:56)Roland Melkert Wrote: Could be an interesting source window feature, but as I'm down to 4 points on my todo list it will have to wait Big Grin

In the mean time you could edit the template outside LDCad to flip the !LDCAD PATH_POINT lines.

Or rearange them one by one in the source window, but you'll have to disable auto grouping first.

Yeah, I mean this has only just now come up for me, so clearly it's not a high priority. :-)
Reply
RE: LDCad 1.7 Alpha 1 (win+linux)
is there a to easy way to add reference images for modeling? (beside generating a sticker with stickerGen) if not can you please add that ability. thanks
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 4 Guest(s)