LDCad 1.7 Alpha 1 (win+linux)

[N. W. Perry]

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.

[Roland Melkert]

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.

[N. W. Perry]

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)?

[Roland Melkert]

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.

[N. W. Perry]

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?

[Cam's Bricks]

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.


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.

[Roland Melkert]

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.

[Cam's Bricks]

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.

[Cam's Bricks]

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?

[Roland Melkert]

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?

[Cam's Bricks]

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.

[Roland Melkert]

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?

[Cam's Bricks]

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.

[Roland Melkert]

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.

[Jaco van der Molen]

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.

[Cam's Bricks]

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

[Roland Melkert]

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:

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

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.

[Roland Melkert]

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

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

[Cam's Bricks]

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

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.

[Roland Melkert]

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?

[Cam's Bricks]

...
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.

[Cam's Bricks]

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.

[Jaco van der Molen]

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!

[Jaco van der Molen]

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

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.

[Roland Melkert]

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.

[N. W. Perry]

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?

[Roland Melkert]

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.

[N. W. Perry]

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!)

[Roland Melkert]

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.

[N. W. Perry]

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…)

[Roland Melkert]

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.

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

[N. W. Perry]

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 

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.

[N. W. Perry]

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?

[Philippe Hurbain]

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)

[N. W. Perry]

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".

[Philippe Hurbain]

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 . Use case?

[N. W. Perry]

I see what you want (change order of path points), but I fail to understand the purpose . 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.

[Roland Melkert]

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

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.

[N. W. Perry]

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

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. :-)

[N. W. Perry]

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?

[Roland Melkert]

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

[Cam's Bricks]

I'll put it on the Beta 1 todo list, as I'm (finally) in the testing phase of Alpha 2

Big +1 here

[Sam Potter]

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