Possible bug: added or moved parts always snap to the geometric center of another part when dragged over it?

[Agetian]

I'm not sure if this is an actual bug or a feature, but I can't find anything related to it in the manual or in the video tutorials I was able to find, and I don't seem to find any way to alter this somewhat clunky-feeling behavior, so I thought I'd report just in case.

If I add a part to the model, for example, a base plate, and then drag out another part on top of it (e.g. a 1x2 brick) trying to connect it to the base plate, the newly added brick will automatically snap straight to the geometric center of the base plate (which happens to be in between studs), and then I need to drop it and manually move it around separately to whatever location I need on the baseplate. I'm assuming/hoping that there's a way to snap to the actual studs, or at least to disable this functionality that auto-snaps to the center of the piece, but I can't seem to be able to do it, which makes designing the model sort of unwieldy. This works exactly the same with other parts I tried (e.g. trying to add a 1x1 brick on top of a 1x4 brick).

If it matters, I'm running the current (as of this writing) AppImage on Linux Mint 20 (LeoCAD-Linux-d1991b9-x86_64.AppImage).

Here's a picture demonstrating where the new part is always auto-snapped when I either add a new item by dragging it out or when I try to move the piece over another piece by holding the mouse and moving the part around:

[nathaneltitane]

Check the snap settings for snapping grid intervals and on/off toggle.

You can find it either in the menus or in the toolbars.

[Agetian]

This happens regardless of the settings for the snap, even if it's set to off. Here's a short video demonstrating the issue with different snap options:

https://user-images.githubusercontent.com/24357441/102740071-ece02a00-435f-11eb-9c71-cce25b370678.mp4

In case it matters, I'm using the latest set of complete.zip from the LDraw website, but I also tried it with the LeoCAD-provided internal parts, and the behavior is exactly the same - that is, as if there's some kind of a super powerful magnet right in the middle of all parts that instantly force-snaps the newly moved bricks to it.

[Agetian]

Hmm, I think the workflow kind of starts to make sense - it looks like just dragging the object over another object places it in the middle of that object, and then dragging the object using the axis arrows and stuff allows you to precisely position the object where you want, so I guess this is a feature after all and not a bug, even if it's a little counter-intuitive and maybe not very transparently documented (at least in the Basic tutorial that I checked out), I guess maybe making it a little bit more explicit in the documentation would help clarify it for someone not familiar with the LeoCAD workflow, otherwise it's fine once you get used to it :)

[leozide]

I see the confusion that this is causing, the snap settings don't affect free dragging, they only affect when you drag using the arrows.

When you drag without clicking on the arrows the app tries to find a good location to place the selected piece so it just puts it on top of whatever is under the mouse. It would be nice to detect studs and try to match them but this is a big task.

I'll update the tutorial to make this clear.

[Agetian]

Yeah, makes perfect sense, thanks for clarifying this! :) And yes, once you understand what's going on and adapt accordingly, it actually becomes really easy to place the bricks.

[j6t]

This is another case of "intelligent placement", which I think is way too difficult to implement. It would require a database of how pieces fit together. Who would maintain it?

Can we close this issue? Or if you want to keep it open, @leozide, should we have a label "documentation" or something?

[leozide]

This is probably the most requested feature, it's just a ton of work to maintain a database of connections.

[trevorsandy]

How about this to minimize the connection database:

• Following the camera's line of sight and covering parts in the viewing frustum
• If the part being dragged overlaps another part and left mouse button is depressed
• If the overlapped part's unoccluded surface is connectable (i.e. has studs, pin holes, gear mesh, vice versa) and the dragged parts facing surface is also connectable (i.e. studs, pins, gear mesh, vice versa)
• Capture the dragged and overlapping part's surface and highlight (i.e. propose to connect) the connectable items (i.e. pin, stud, vice versa) closest aligned to the line of sight if exists.
• When left mouse button is released, connect the parts via the proposed connection center point

Cheers,

[j6t]

That is the fun part.

If the overlapped part's unoccluded surface is connectable...

A human would easily be able to answer this question, but how would the stupid machine answer it? That is where we would need a database.

The boring part is to let the stupid machine know which parts can be connected to which ones in which ways. The database would have to be kept up-to-date as new pieces are invented.

[trevorsandy]

but how would the stupid machine answer it? That is where we would need a database.

Indeed, and you already have one. Leverage PieceInfo creation and/or mesh loading to capture/define, and cache, a part's connection info.

which parts can be connected to which ones in which ways

This can be dynamically resolved, 64bit multi-core processors are the norm versus the exception today.

Cheers,

[rsbx]

I'd be interesting to know how Stud.IO handles that problem and what it doesn't handle.

On 4/10/21 2:36 PM, Leonardo Zide wrote:

This is probably the most requested feature, it's just a ton of work to maintain a database of connections.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/leozide/leocad/issues/563#issuecomment-817184787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAECJNHPHCBMQUXMQW6V6W3TICLBZANCNFSM4VDLK42Q.

[nathaneltitane]

I'd be interesting to know how Stud.IO handles that problem and what it doesn't handle. … On 4/10/21 2:36 PM, Leonardo Zide wrote: This is probably the most requested feature, it's just a ton of work to maintain a database of connections. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#563 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAECJNHPHCBMQUXMQW6V6W3TICLBZANCNFSM4VDLK42Q.

can technic pin holes, pins locations (center) and studs be marked for some kind of anchoring mechanism?

[rsbx]

Doing it even semi-well, there are a lot of ways to connect LEGO parts, would require a database of connection types, orientations, engage to seat distance, shared/exclusive, etc. Much of that can be related to primitives which will give good part coverage but there's likely to be a large number of special cases and exceptions. And those 2 databases will be a major, on-going maintenance task.

[nathaneltitane]

Doing it even semi-well, there are a lot of ways to connect LEGO parts, would require a database of connection types, orientations, engage to seat distance, shared/exclusive, etc. Much of that can be related to primitives which will give good part coverage but there's likely to be a large number of special cases and exceptions. And those 2 databases will be a major, on-going maintenance task.

Well, this is purely considering 'legal' connections obviously... I was thinking about more in the likes of when the part is loaded or drawn: isn't there something in an ldr file that can help leocad pinpoint said location and draw it out like a normal hair or something?

[rsbx]

There's nothing in the LDR file specification that will help with this but the standard primitives can be leveraged to identify many of the locations and the final normals of triangles & quads can be used to infer some of the necessary information...

[j6t]

There's nothing in the LDR file specification that will help with this but the standard primitives can be leveraged to identify many of the locations and the final normals of triangles & quads can be used to infer some of the necessary information...

Correct. But that's about it.

Even a simple brick is problematic: even though it would be easy to know "here is a stud" of the brick, there is nothing that would tell "a stud can go here" in the brick.

[nathaneltitane]

There's nothing in the LDR file specification that will help with this but the standard primitives can be leveraged to identify many of the locations and the final normals of triangles & quads can be used to infer some of the necessary information...

Correct. But that's about it.

Even a simple brick is problematic: even though it would be easy to know "here is a stud" of the brick, there is nothing that would tell "a stud can go here" in the brick.

isn't the base of any brick or plate identified at a primitive level? you could flag that. could function as a magnet with poles: north=stud south=base

how does leocad currently manage positioning parts relative to one another when the previously inserted part is pre-selected (blue)?

[rsbx]

The short answer is NO. There is a surprisingly large number of stud accepting geometries in the "bottom" of LEGO pieces.

On 4/16/21 7:20 PM, Nathanel Titane wrote:

    There's nothing in the LDR file specification that will help
    with this *but* the /standard/ primitives can be leveraged to
    identify many of the locations *and* the /final/ normals of
    triangles & quads can be used to infer /some/ of the necessary
    information...

Correct. But that's about it.

Even a simple brick is problematic: even though it would be easy to
know "here is a stud" of the brick, there is nothing that would tell
"a stud can go here" in the brick.

isn't the base of any brick or plate identified at a primitive level? you could flag that. could function as a magnet with poles: north=stud south=base

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/leozide/leocad/issues/563#issuecomment-821719838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAECJNAB6CIOBE7WR6RLHMTTJDA4TANCNFSM4VDLK42Q.

[Tynach]

@leozide, personally I wouldn't expect 'smart placement' to be able to perfectly keep track of all possible ways for pieces to connect to each other. I would only expect the program to know the following:

1. The orientation of a piece.

2. The 'center' of the piece, and assume that center is either on the surface, or at a stud position.

3. The bounding box of the non-stud portion of a piece (such as the flat top surface of a 'Tile', or the portion of a brick/plate that is level with the bottom of the studs on top).

   From what I can tell, most pieces place the 'center' of the piece at the 'top', but below the studs. Using this, I presume it'd be 'good enough' to just assume that the bounding box of the non-stud portion of a piece is just the normal bounding box, but truncated to the position of the piece's 'center' at the top.

4. Know the above for pieces that are in submodels (recursively).

The basic workflow I expect is this: when dragging a piece around with the mouse, and the mouse hovers over another piece that's already placed, it will flip the dragged piece around to match orientations (no changes there) and change snapping positions based on the following criteria:

• If the mouse is hovering over a portion of the bounding box that is on the 'top' or 'bottom' of the model (based purely on the orientation and non-stud bounding box), use the same code as when dragging on an empty grid and snap to theoretical snap positions that are calculated as an offset to the center of the piece.

  For the case where it's the bottom of the bounding box, just do the same thing but have it offset where it considers the 'centers' of both objects to be so that the center (instead of the bottom beneath the center) of the new piece now snaps to theoretical and assumed stud positions based on offsets from the bottom beneath the center (instead of the center itself) of the already placed piece.

• Otherwise (when hovering over the side of bounding box to the already placed piece), use the current logic of snapping the bottom of the new piece to the actual center of the already placed piece.

One other detail about this, is that perhaps instead of exactly using the same placing code as when dragging on an empty grid, we should instead snap to whatever theoretical stud position (or half stud, or whatever is currently being used as the user's preference for XY grid snapping) is closest to where the mouse cursor is pointing on the non-stud bounding box.

Or heck, make that an option for even the blank grid dragging; it kinda annoys me that it tries to center the piece's model on the cursor, instead of trying to place the piece to the location on the grid that I'm trying to point at. The current behavior also makes it fiddly or impossible to place bricks right next to each other if they're a bit tall and you want one in front of an already placed one, which this proposed behavior would fix.

As an asside, number 4 would be a fairly big help to me, personally. I like keeping my models organized, and I do that by having submodels containing submodels containing submodels. However, when I get done with one submodel and go up one level to the submodel that will contain it, it can be very difficult to place correctly - especially if it has to attach to pieces that were rotated.

---

Of course, this doesn't cover all possible use cases, and is extremely imperfect... But as long as it's a toggleable behavior, I think it would be a massive improvement to what we currently have to do, and would not require any sort of 'stud placement database'.

It would produce sensible output in the majority of situations, and is at worst just as bad as the current behavior without being worse. It would also mimic existing behavior when dragging on an empty grid, so shouldn't appear out of place or unexpected.

[leozide]

I've made some changes that will improve positioning when dragging over a submodel and when placing to the sides or bottom of an existing piece.

[Tynach]

I've made some changes that will improve positioning when dragging over a submodel and when placing to the sides or bottom of an existing piece.

@leozide that's great news! What's the new behavior going to be like?

[ChaoticPumpkin]

Any updates on this?