LDCad 2.0 GUI Thoughts

[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