LDCad 2.0 GUI Thoughts

[Roland Melkert]

Hi all,

I'm working on the foundation of what is highly likely to become LDCad 2.0, although currently it has little to nothing to do with LDraw specifics.

While doing this a lot of (boring) fundamental classes and tools need to be (re)written. I've done so for strings, list, etc and the OpenGL gui  engine is next.

Problem is I'm not yet sure on what kind of GUI to give LDCad 2.0. I know many people dislike the 1.x one, but I rather like it myself so I want to improve upon it but keep the basis the same maybe making it very dynamic so it can support different looks.

Anyway in order to write the support classes (window handling etc) I need to know what it should be able to do rendering wise etc.

For this I would like to gather some feedback about the current 1.x gui, in other words what is it people really hate about it or what kind of behavior are they missing.

I'm not talking colors though, as you can already change those in 1.x. One thing I'm thinking about myself is something like the blender gui which should be able to (nearly) mimic the 1.6 look as a default template or something.

Any thoughts/ideas/feedback is welcome.

LDCad 2.0 teaser

  out.png (Size: 12.98 KB / Downloads: 602)

[Owen Dive]

I don't have a problem with the interface, but I suspect that the reason "many people dislike the 1.x one" is simply that it's different from what they're used to - in which case you probably can't win with a roll-your-own.

Owen.

[Orion Pobursky]

The reason "many people dislike the 1.x one" is simply that it's different

Not different per se but not the expected UI for the OS I'm using.  I'd rather have native controls or, barring that, a native look and feel. Plus the fonts seem blocky to me.

[Willy Tschager]

Hi Roland,

simple question, simple answer:

* The only thing I really hate are the menus, contextual menus and how they behave, that they fly on the GUI with the need to close them (sometimes).

* https://forums.ldraw.org/thread-21693-po...l#pid23067
* I'd like to have proper icons for grid stepping (for sure the 1,2,3 keys are handy but I have no visual feedback which grid I'm using. A pressed icon would help).
* Same for the 2D/3D switch (I know the v key but sometimes I forget about it :-)
* I'd like to have a separate search icon in the parts bin near the tabs
* as much as I like the color wheel I'd like to search for a color name/number
* https://forums.ldraw.org/thread-22200-po...l#pid25807
* https://forums.ldraw.org/thread-22200-po...l#pid25788

w.

[Magnus Forsberg]

I agree with Owen, Orion and Willy. The difference in behaviour is the most difficult obstacle when learning to use the program.

Personally I do not like the tooltip only being visible in the status bar. It's forcing me to constantly having to refocus both my eyes and the mousepointer.

I miss the possibility to use ctrl+Y as "redo" an action.

I don't like the pop-up menu on the middle mouse button.

https://forums.ldraw.org/thread-22117-po...l#pid25219

[Merlijn Wissink]

I think the biggest reason a lot of people don't like LDCad's gui is because it doesn't look familiar at all and it looks kinda... old. A lot of desktop software often has a gui that uses either native OS elements (winforms, QT, etc.) or just looks more fleshed out (JavaFX, MS Office Ribbon interface, Autodesk ribbon interface, stud.io). Yours is neither. It doesn't use/look like native OS elements, but it doesn't look particularly well-designed either (no offense   ).

Keeping a self-made gui is certainly possible. You absolutely don't need to go native, just take a look at Adobe software, Autodesk software or even Bricklink's stud.io for example; not native at all but pretty popular and people think it almost as easy to use as LDD.

I'm by far not a designer, but I think improving the looks of your gui will be the biggest improvement for most people, not necessarily its functionality. For example, yours is (currently) very flat and square. Flat is kinda a trend in modern web/app design, but in a different way. Modern design guidelines such as Google's Material Design (which I personally really like) and Microsoft's Metro use color, spacing and (slight) drop-shadows to separate ui elements, whereas you use borders (with pointy 90 degree corners) to separate the ui elements because everything is has the same blue color.

But that's just a single example. I think if you take a look at those design guidelines you might get some ideas on how to improve your ui. And I don't mean quite literally copying one of those designs (although you certainly could   ), I mean the thought behind them and why they did certain things.

But again, I'm not a designer, these are just my very personal 2 cents 

[Roland Melkert]

I think the biggest reason a lot of people don't like LDCad's gui is because it doesn't look familiar at all and it looks kinda... old. A lot of desktop software often has a gui that uses either native OS elements (winforms, QT, etc.) or just looks more fleshed out.....

Thanks for your insight Merlijn.

I'll look into those links, but I never liked metro though. The main reason LDCad's GUI is flat, is because it's easier to render.

[Roland Melkert]

The only thing I really hate are the menus, contextual menus and how they behave, that they fly on the GUI with the need to close them (sometimes).

They close when you click outside of them, the only real difference you can keep them open by pinning them down. The menu system in 20 will probably be somewhat different but the pinning feature will remain.

[Roland Melkert]

Personally I do not like the tooltip only being visible in the status bar. It's forcing me to constantly having to refocus both my eyes and the mousepointer.

I miss the possibility to use ctrl+Y as "redo" an action.

I don't like the pop-up menu on the middle mouse button.

Hint will be floating in 2.0, as I'm kinda forced to, because I'm planing to use a simpler host application library (glfw instead of wxWidgets).

You can assign ctrl+y to redo if you want.

You can also use the enter/return key for opening property dialogs.

[Roland Melkert]

Not different per se but not the expected UI for the OS I'm using.  I'd rather have native controls or, barring that, a native look and feel. Plus the fonts seem blocky to me.

The main reason for non native controls is / was the intensive use of OpenGL graphics for rendering the LDraw bricks in the part bin etc. Also I (still) have the future wish of using fullscreen OpenGL with the program.

Fonts are configurable, the default uses dejavusans or verdana on windows and freesans on Linux, you can change that though by editing gui/default/main.gu

[Philippe Hurbain]

I think Merlijn summarized well the "problem". I was never bothered by LDCad look and feel, probably because I'm an old timer and I've seen so many variants... One can wonder why Mlcad or Leocad got little criticism, that's probably because their interface, though quite outdated, is more aligned with OS standard look...

[Milan Vančura]

Hi Roland. Even I respect the fact you like working on your own GUI, I want to tell you my 'secret, selfish POV': I believe the situation changed during time you worked on the version 1.6. You came with many new ideas about scripting etc. that, I believe, you have completely new view on the representation of the data model and the capabilities the model should have, compared to what you started with, say, in LDCAD 1.0. (And maybe you have an idea how to allow us even something more like basics of mechanics in SR3DBuilder style?) And this is what I, as a user, am looking forward to. This is what I call a reason for 'LDCAD 2.0'.
From this POV, the own GUI (engine) is a priority 0.00001 - pop-up windows are rendered by GTK or what even today, AFAIK. So, from my, user, selfish POV, I'd like if you saved all that time of GUI work and concentrated on what you know the best, the ldraw editing. To be clear: I mean GUI engine, there is still a lot of work on the design of the application itself, of course. Some ideas are already presented in this thread and I support them: add a search box for colors etc.
I'm sorry if this is something different than what you wanted to hear But I really believe the value of LDCAD is in what it 'knows to do'. And if its GUI will be more 'OS standard', we get several advantages at the same time: your time saved for working on LDCAD functionality, people not surprised by the app look&feel, GUI features you can't have time to implement them all (KDE, GTK etc. are developed for years, in big teams of people).

[Roland Melkert]

I'm sorry if this is something different than what you wanted to hear But I really believe the value of LDCAD is in what it 'knows to do'. And if its GUI will be more 'OS standard', we get several advantages at the same time: your time saved for working on LDCAD functionality, people not surprised by the app look&feel, GUI features you can't have time to implement them all (KDE, GTK etc. are developed for years, in big teams of people).

This is probably true, but a very big part of the LDCad hobby, for me, is doing weird things. Writing 'normal' programs is my day job

This is why I even write my own string handling routines etc (hence the number/enum parsing tests in the above screen shot).

All in all I tend to view LDCad more as a game program then a office one.

The main reason for 2.0 instead of 1.7 are the internals whom were becoming messy in 1.6 because of all the unforeseen features like you suspected.

[Milan Vančura]

This is probably true, but a very big part of the LDCad hobby, for me, is doing weird things. Writing 'normal' programs is my day job

I know, and I respect this. I just wanted to say my opinion loudly to make it clear, to tell you how good job you do and how valuable your work about ldraw editing is for us. And, of course, I believe I'm not alone with this opinion - but somebody had to be the first one who tells you that

My experience is that LDCAD is ahead of any other LDraw editor. And your work on scripting (of everything) opens doors to a completely new level of features. And, BTW, this is the kind of GUI improvement I'd appreciate: improve the GUI of selecting parts so more than one selection is possible. This allows new/planned features like triangle setting, hinge bending, hoses creation/editing using snap points of other pieces (making the hose going through selected holes or clips) and more and more, including users' scripts like, for example a regular placement of selected pieces along a selected hose etc.
This is GUI I miss, GUI in terms of 'menus' looks so boring compared to this, doesn't it?

[Roland Melkert]

This is GUI I miss, GUI in terms of 'menus' looks so boring compared to this, doesn't it?

Fair point, but I'm also using the GUI stuff to 'practice' OpenGL shaders which I expect to influence the new brick/model rendering quality/speed.

[Jaco van der Molen]

Hi Roland,

Another suggestion I'd like to see is that the disk icon changes when a file save is successful.
Now it stays blue and I sometimes am in doubt I saved.
Once saved change it to something grey or light blue?

Thanks.

[Milan Vančura]

Hi Roland.

I know this is not about GUI only, a mix of ideas but it's the only topic for LDCad 2.0 so I put them here:

I found LDCad going extremely slow sometimes. Like updating the screen once per two seconds, nearly useless for any editing. I cannot trace real sources but it seems to be when I try to move a bigger submodel (50-100 bricks or bigger, approx.) with part snapping turned on. Also, the submodel snaps in many unwanted positions while dragged by mouse. My hypothesis is both problems are results of the same: LDCad calculates snapping for all snap objects of the moved submodel, including those "hidden" or "used" ones.
So this is my idea for LDCad 2.0: flag snap objects in the model when they are blocked and, by default, calculate snapping for "free" objects only.

Another step of this idea would be LDCad understanding the term "connected parts" - basics of mechanics in LDCad, similar to what it was in SR3D.

To end with something really about GUI only: the reason why the problem above is even worse experience is that LDCad makes the selected part "jumping" somewhere at the beginning of mouse dragging. So it doesn't help to move such submodel to a close position without snapping (no performance problems). Because when starting the next drag movement by mouse, the part (submodel) jumps. Please turn this jump function off

[Owen Dive]

Hi Roland.

I know this is not about GUI only, a mix of ideas but it's the only topic for LDCad 2.0 so I put them here:

I found LDCad going extremely slow sometimes. Like updating the screen once per two seconds, nearly useless for any editing. I cannot trace real sources but it seems to be when I try to move a bigger submodel (50-100 bricks or bigger, approx.) with part snapping turned on. Also, the submodel snaps in many unwanted positions while dragged by mouse. My hypothesis is both problems are results of the same: LDCad calculates snapping for all snap objects of the moved submodel, including those "hidden" or "used" ones.
So this is my idea for LDCad 2.0: flag snap objects in the model when they are blocked and, by default, calculate snapping for "free" objects only.

Another step of this idea would be LDCad understanding the term "connected parts" - basics of mechanics in LDCad, similar to what it was in SR3D.

To end with something really about GUI only: the reason why the problem above is even worse experience is that LDCad makes the selected part "jumping" somewhere at the beginning of mouse dragging. So it doesn't help to move such submodel to a close position without snapping (no performance problems). Because when starting the next drag movement by mouse, the part (submodel) jumps. Please turn this jump function off

I agree that the jumping can be a bit annoying, but I found that once I understood the reason for it, I could deal with it much better. The jump is to position the submodel/part/selection with the origin of the submodel/part/first-selected-part at the mouse cursor, so that if you're looking at the grid or the info-box to position the submodel/part/selection, then the origin goes exactly where it appears to be, rather than having some arbitrary mouse offset (which might be tough to determine precisely given you have a 2D perspective onto a 3D model).

[Philippe Hurbain]

Also, the submodel snaps in many unwanted positions while dragged by mouse.

The workaround I use when attaching a big submodel to a big model: select the part(s) where the submodel attaches, select>invert, hide. Attach submodel then unhide. Added benefit, the image is visually less busy and makes attachment easier.

[Milan Vančura]

Thank you both for your tips and explanation, Owen and Philippe.
I understand the technical reason for that jump but I'm not a machine This is often a case in LDCad GUI: it tends to be too technical. This case about surprising jump is a perfect example, this is why I request LDCad being more intuitive here.

About placing big submodels: big thanks for the tip, Philippe! It looks like a useful workaround for now. And as I cannot absolutely estimate when we will see LDCad 2.0 (in a year? or more? it's a complex piece of SW...) it really a worth to have such workaround!

One request more: usually I know (in advance) where I want to place new part. It's unnecessary to fly with the new part at cursor, over all the model, letting all parts of the model "pull" the new part to their snap points. Especially when it's sometimes hard to point to the final place (try to put 40t gear on axle). It would be great to ave an alternative: mark the destination part on the model in advance so the new part will snap to this part ONLY - just cycle trough its snap points. Or even better, select the specific snap point in advance. More clever heuristics would even filter snap points of the new part so only those matching the selected one are active...

More generic: to be able to mark both snap points which I want to join (one on each part) and press "join".

[Philippe Hurbain]

try to put 40t gear on axle

Another workaround
Place a 8t instead, then while it is selected, double click on 40t gear in the bin... Done! Very useful too for a part that doesn't have connectivity yet but is similar to another one...

[Roland Melkert]

I found LDCad going extremely slow sometimes. Like updating the screen once per two seconds, nearly useless for any editing. I cannot trace real sources but it seems to be when I try to move a bigger submodel (50-100 bricks or bigger, approx.) with part snapping turned on. Also, the submodel snaps in many unwanted positions while dragged by mouse. My hypothesis is both problems are results of the same: LDCad calculates snapping for all snap objects of the moved submodel, including those "hidden" or "used" ones.
So this is my idea for LDCad 2.0: flag snap objects in the model when they are blocked and, by default, calculate snapping for "free" objects only.

This is a known limitation and the result of a less then perfect snapping engine. The system looks for matching snap info on all the dragged parts and the static ones in its 'POV' with larger models this pov is also larger so you get even more possibilities.
The official work around is to disable snapping when placing submodels (shift+p). Place them by using a logical submodel center and selecting a part in the target location before dropping.

Another step of this idea would be LDCad understanding the term "connected parts" - basics of mechanics in LDCad, similar to what it was in SR3D.

This is something I really want but there are some problems with it making loading of models very complicated and potentially slow (has to determine all the currently occupied snapping points). But it is very high on my 'why even do a 2.0' list as it requires deep code rewrites

To end with something really about GUI only: the reason why the problem above is even worse experience is that LDCad makes the selected part "jumping" somewhere at the beginning of mouse dragging. So it doesn't help to move such submodel to a close position without snapping (no performance problems). Because when starting the next drag movement by mouse, the part (submodel) jumps. Please turn this jump function off

Grid based moves don't have this problem. It is again a downside of the used snapping setup and also has to do with the pov of the moving selection. Once I get rendering sorted out in 2.0 I'll start thinking about the new snapping system.

I agree that the jumping can be a bit annoying, but I found that once I understood the reason for it, I could deal with it much better. The jump is to position the submodel/part/selection with the origin of the submodel/part/first-selected-part at the mouse cursor, so that if you're looking at the grid or the info-box to position the submodel/part/selection, then the origin goes exactly where it appears to be, rather than having some arbitrary mouse offset (which might be tough to determine precisely given you have a 2D perspective onto a 3D model).

This is indeed the problem in a nutshell.

One request more: usually I know (in advance) where I want to place new part. It's unnecessary to fly with the new part at cursor, over all the model, letting all parts of the model "pull" the new part to their snap points. Especially when it's sometimes hard to point to the final place (try to put 40t gear on axle).

That is a possible solution. Also the current snapping stuff isn't multi threaded the one in 2.0 will be so that should allow for some more breathing space too.

In 1.6 You can also disable snapping while moving the selection around and enable it again when you roughly at the place you want to be (shift+p)

It would be great to ave an alternative: mark the destination part on the model in advance so the new part will snap to this part ONLY - just cycle trough its snap points. Or even better, select the specific snap point in advance. More clever heuristics would even filter snap points of the new part so only those matching the selected one are active...

40t gear can be fun indeed the main trick is the angle you look upon the model. Early version of the engine was even more fun as the axle didn't 'stick' to a current hole making it jump holes all the time

And as I cannot absolutely estimate when we will see LDCad 2.0 (in a year? or more? it's a complex piece of SW...) it really a worth to have such workaround!

Work ion it s a bit slow currently as I'm behind on my real life work and have little time for LDCad (hence the delay in 1.6b).

Time should clear up in a couple of weeks though

Thanks for the input all

[Michael Horvath]

I think the LeoCAD GUI is very slick, though it is still a ways farther behind LDCad in terms of offering features. Once it catches up, I will probably be using it exclusively.

[Roland Melkert]

I think the LeoCAD GUI is very slick, though it is still a ways farther behind LDCad in terms of offering features. Once it catches up, I will probably be using it exclusively.

It has nice button icons but other then that it's basically mlcad imho.

The big problem I'm having is not being an artist so I'll automatically end up with very flat simple looking icons.

The LDCad 2 gui will be heavily depended on "Skin" images so in theory it could be just as slick if someone makes nicer images for it.

[Jaco van der Molen]

I think the LeoCAD GUI is very slick, though it is still a ways farther behind LDCad in terms of offering features. Once it catches up, I will probably be using it exclusively.

It has nice button icons but other then that it's basically mlcad imho.

The big problem I'm having is not being an artist so I'll automatically end up with very flat simple looking icons.

The LDCad 2 gui will be heavily depended on "Skin" images so in theory it could be just as slick if someone makes nicer images for it.

I believe the icons that LeoCAD uses are standard Windows icons that can be found in various DLL files in %systemroot%\system32\
Found at: https://www.digitalcitizen.life/where-fi...tive-icons
but this goes for all versions of Windows, I think.

Once LDCad 2 is out, I am more than willing to create icons and share them.
Most icons for standard actions like open, save, close, etc. can be easily used from standard Windows programs and be made as images the can be used.

For what the GUI of LDCad is now I am happy with it, like it is. But I can imagine some people will find it most confusing.
Though I must say LDCad is not aimed at your average Windows / LDraw user. I am wondering how many people who start with LDraw will and can understand working with it.
It took me a couple of months to get used to and since I was a die-hard MLCad user this took a lot of effort. I even gave up trying to learn and understand it at some point.
Now that I am comfortable with LDCad, I am very happy to learn and use it all the time as my basic LDraw editor, though I sometimes refer to MLCad, like mentioned.

[Leonardo Zide]

I believe the icons that LeoCAD uses are standard Windows icons that can be found in various DLL files in %systemroot%\system32\

They are custom icons made by a user.

[Jaco van der Molen]

I believe the icons that LeoCAD uses are standard Windows icons that can be found in various DLL files in %systemroot%\system32\

They are custom icons made by a user.

Oh, OK. They look pretty standard though ;-)

Anyway, I think I can make icons for LDCad if there's a need.

[Roland Melkert]

Anyway, I think I can make icons for LDCad if there's a need.

I've been playing with GIMP myself but it doesn't look promising to say the least, so any help would be very much appreciated

[Jaco van der Molen]

Anyway, I think I can make icons for LDCad if there's a need.

I've been playing with GIMP myself but it doesn't look promising to say the least, so any help would be very much appreciated

OK, I can give this some thought and try. What format (PNG?) and size should the icons be?

[Roland Melkert]

I've been playing with GIMP myself but it doesn't look promising to say the least, so any help would be very much appreciated

OK, I can give this some thought and try. What format (PNG?) and size should the icons be?

I will only support png (rgba), not sure on the icon sizes yet.

I've been working on basic skin 'wallpapers' only as they are used to draw the part bin etc.

Things can also change in a blink as it is all still very experimental. Once I've got it to a point I will need 'serious' images I'll probably start a new topic on the forum.

[Miguel Reizinho]

They are custom icons made by a user.

I was the one who did that icons for Leonardo and LeoCAD. 

I've also did another set of icons but for LDCad 1.6. I sent these to Roland:

[Philippe Hurbain]

Looks nice!

[Sorin Mihai Dobrescu]

Anyway, I think I can make icons for LDCad if there's a need.

I've been playing with GIMP myself but it doesn't look promising to say the least, so any help would be very much appreciated

I'd use Inkscape. It's scalable.

[Sorin Mihai Dobrescu]

Hi, I use LDCad from a year or so. To me it's a light UI that looks CAD-like rather than something else. I love it. I did not have much issues with it. I have worked with PTC and other professional CAD tools, mainly for modelling purposes. I have picked LDCad after trying many Lego tools.
The menus are really fine for me, I love they float and can be moved without closing (as native ones would do).
From my experience, a custom UI is better than standard ones. I've seen GTK apps that must compoly to Gnome standards, this spoiling my experience. For insatnce sticking to shortcuts and removing toolbars icons, like save, for instance, or selecting operations. This made my life hard.


Now, my experience with LDCad, I have faced some issues too:
- some number localization errors due to the "." vs ",". I have English as UI language, but Romania as region, under KDE. So comma is for decimal.
- I have needed several times to compare models, so I would like so much having few instances of LDCad at once, at least 2, not switching from one model to another. I use two displays too, would help me a lot to have one LDCad open on each. Also, I don't like the idea of working exclusively in fullscreen. Sometimes it is useful to consult some original manual during building virtually and I like to switch.
- sometimes snapping is hard, especially when needing angles (for instance 9398 chassy around the battery). I still can't find the right way, rotating after calcualting the angles is not real snapping.
- I'd like more palette views, I use more than 6 categories for technic. I also need to be careful to avoid paticular printed parts (like technic beam 3 with "40 1977 - 2017" text etc.). These should be somewhere else or be possible to filter them out.
- Setting submodels centers it's a mistery to me, I can't make it clearly, sometimes they remain with some center away from the submodel itself...
- I'd like to have a compatible parts list export for all the model or submodels, I use stud.io for that in a convoluted way (sending it to them, not publishing, adding it to the wishlist, making the parts list there etc..)
- a powerful feature would be a function to relate parts in a way that moves them when needed when a different part is chosen in place of some part of the model... but this is complicated even to define...

This is my list, if I have new ideas, I might add to it here...

Thank you for the great application!

[Roland Melkert]

Thanks for the positive feedback

- some number localization errors due to the "." vs ",". I have English as UI language, but Romania as region, under KDE. So comma is for decimal.

This could be a bug. All gui fields should accept both the "." and the ",". Files always use the ".". during writing, but (i think, need to confirm) will also accept "," during reading.

- I have needed several times to compare models, so I would like so much having few instances of LDCad at once, at least 2, not switching from one model to another. I use two displays too, would help me a lot to have one LDCad open on each. Also, I don't like the idea of working exclusively in fullscreen. Sometimes it is useful to consult some original manual during building virtually and I like to switch.

You can disable the instance protection by editing/creating LDCad.cfg
This file is located in /etc under linux if you ran setup.sh
Or create it in the same folder as the main executable if you use the archive version as is. But name it the same as the exe with .cfg appended to it.

To disable instances add

Code:

[options]
useSingleInstance=false

to it (make sure [options] is not already in there, if so place in the existing block.

- sometimes snapping is hard, especially when needing angles (for instance 9398 chassy around the battery). I still can't find the right way, rotating after calcualting the angles is not real snapping.

You can rotate the parts while dragging to get them closer to the needed angle using the arrow pgup/down keys. Hold down ctrl to use 45 deg stepping.
That said snapping is far from perfect I'm hoping to make some improvements in 2.0 though.

- I'd like more palette views, I use more than 6 categories for technic. I also need to be careful to avoid paticular printed parts (like technic beam 3 with "40 1977 - 2017" text etc.). These should be somewhere else or be possible to filter them out.

This is currently hardcoded but it will highly likely be variable in 2.0. The initial though about 6 was the fact most humans can remember about 6 or 7 things items in short term memory, or so have I been told

- Setting submodels centers it's a mistery to me, I can't make it clearly, sometimes they remain with some center away from the submodel itself...

Whatever is at 0,0,0 is the center of the model. The easiest way yo change it is to select a part (in non nested mode) you think should be the center then use ctrl+a en shift+c

- I'd like to have a compatible parts list export for all the model or submodels, I use stud.io for that in a convoluted way (sending it to them, not publishing, adding it to the wishlist, making the parts list there etc..)

1.6c will have a very simple tab separated values export for part bin group content, but you would probably need to convert it after.

- a powerful feature would be a function to relate parts in a way that moves them when needed when a different part is chosen in place of some part of the model... but this is complicated even to define...

Do you mean automatic animation or grouping? The later is already available even in nested mode.

[Philippe Hurbain]

- sometimes snapping is hard, especially when needing angles (for instance 9398 chassy around the battery). I still can't find the right way, rotating after calcualting the angles is not real snapping.

You can rotate the parts while dragging to get them closer to the needed angle using the arrow pgup/down keys. Hold down ctrl to use 45 deg stepping.
That said snapping is far from perfect I'm hoping to make some improvements in 2.0 though.

Yes, attaching a big submodel can be tricky. Two tips that can help:
- Often when the submodel needs to be placed at an angle, there is already a part with the right orientation in the model. Select that part (if needed go to nested mode before) and press "o" to make that part orientation define the new relative grid axis. After that, when you add the submodel, it will be easier to orient it correctly.
- To avoid false snapping, select a key part in the model to wich the submodel must snap, then select-> invert then hide all. This way, only that part will trigger snapping.

- I'd like more palette views, I use more than 6 categories for technic.

This is currently hardcoded but it will highly likely be variable in 2.0. The initial though about 6 was the fact most humans can remember about 6 or 7 things items in short term memory, or so have I been told

You can also use more than one parts bin (view -> new parts bin window)

I also need to be careful to avoid paticular printed parts (like technic beam 3 with "40 1977 - 2017" text etc.). These should be somewhere else or be possible to filter them out.

I'd also like to have a "hide/show patterned" checkbox in part bin, possibly in each category.

[Milan Vančura]

Yes. Rotational snap and connection solver are two big features I'd really like in LDCAD 2.0. For this, we need the generic GUI concept of being able to mark snap point(s). And if having this, it'd awesome to be able to use such information in LDCAD scripts as well. (an example below)

Motivation videos:

My summary video about these features:
video

And some videos of old SR3D builder features. Although LDCAD is superior to SR3D Builder in many, many ways, some features are still missing. I do not ask for full mechanics simulation in SR3D way (because I want LDCAD 2.0 being ready in less than 5 years ) but the feature of snap point selection and connection solving would be really handy:  

connection solver 1:
(see marking a snap point #1, snap point #2 and clicking on "solve" then)
video

more about connection solving:
 1. "find and copy the angle" - so the universal joint aligns with liftarms
 2. align parts: rotate parts so their holes (or other snap points) match
video

using snap points as rotation centers:
video

using marking of snap points in a script:
video

[Roland Melkert]

I do not ask for full mechanics simulation in SR3D way (because I want LDCAD 2.0 being ready in less than 5 years ) but the feature of snap point selection and connection solving would be really handy:

The auto animation features of SR3DBuilder are extremely cool indeed. I hope to get it working in LDCad 2 to some degree, at some point, through scripted plugins.

[Milan Vančura]

The auto animation features of SR3DBuilder are extremely cool indeed. I hope to get it working in LDCad 2 to some degree, at some point, through scripted plugins.

Yes, this is/was really handy feature. For example for a check of the model: only properly placed (and "connected") parts work(ed) in such animation.

For model building, it wasn't important so much because (IIRC) it didn't work together with snapping so the extra function "connection solver" was more useful.

For LDCAD, I believe the list of depending features would be:

1. GUI for snap point(s) selection, usable in different situations (as rotation centers, as input data for a script, an interactive hose creation - using other parts snap points as its path points, a brick placement/move (so this workaround will not be needed, or the 40tooth gear placement stops being a pain...) etc.)
2. rotation snap - as shown in my video
3. GUI for two independent selections - at least for connection solver, to be able to select each part/submodel and their rotation centers
4. connection solver itself (should be a relatively easy script using features above)
5. "solid connection simulation" - automatic selection of a submodel "solidly" connected with the selected part (i.e. a hinge or a brick with a hole, around the axle)
6. "snap/connection types" (two gears teeth, different hinge types etc.) and the mechanical properties of each (rotation possible yes/no etc.)

It's a question if I'm correct, of course. But if yes, I say that 1-4 would be such great improvement of LDCAD in my eyes that I'm happy with postponing 5-6 to the version 2.5

[Roland Melkert]

It's a question if I'm correct, of course. But if yes, I say that 1-4 would be such great improvement of LDCAD in my eyes that I'm happy with postponing 5-6 to the version 2.5

I would be happy if I get 2.0 'out of the door' this year as I haven't spend as much time working on it as would like.

My lack of time is something I'm hoping to compensate by making 2.0 sort of a thin client where the higher level features are all done trough (lua) scripting. That way people can add stuff they are missing them selves.

[Milan Vančura]

My lack of time is something I'm hoping to compensate by making 2.0 sort of a thin client where the higher level features are all done trough (lua) scripting. That way people can add stuff they are missing them selves.

I understand. You have already mentioned this idea so I already counted on that while making the list of features above: #4 is a pretty candidate for a script, for example. #1 (GUI for snap points selection) is #1 because it is a base stone for the other features and I doubt it can be made in LUA script, it's what core LDCAD must provide as an interface for both the user (GUI) and scripts (access to such data).

I'm not sure about #2 (rotational snap) because of the performance.

[Johann Eisner]

Hi all,

Any thoughts/ideas/feedback is welcome.

LDCad 2.0 teaser

Hi Roland

I Draw now the first model in LDCad.
I have to admit, I did not read that wish list because I was too lazy.
Maybe the wish already exists.
I do not like it, if I want to change a brick later, then the selection menu contains only the part number. From MLCad I am used to the part number and the description is displayed.
Maybe there is a other way to edit the part proberties.

For example:
MLCad

  MLCad_prob.PNG (Size: 11.22 KB / Downloads: 96)

LDCad

  LDCad_prob.PNG (Size: 11.52 KB / Downloads: 95)


Johann

[Philippe Hurbain]

Using properties is not the best way to replace a part with another... to do that, select the part you want to change, then in the parts bin, double click on the replacement part.

[Johann Eisner]

Using properties is not the best way to replace a part with another... to do that, select the part you want to change, then in the parts bin, double click on the replacement part.

Hi Philo

And here is the other way. 
Thanks a lot.

Johann