[LDCad] Part Snapping missing/errors

[Philippe Hurbain]

Relatively recent yes, when I created the animal "segment" patterns (such as https://www.ldraw.org/parts/official-par...d=31111p02). There was already a patterned version, but it was not subparted (https://www.ldraw.org/parts/official-par...d=31111p01)

[Roland Melkert]

I've processed up to message #48

And I also added a new bunch of files by Alex Taylor (incl some unofficial ones)

As always the latest (test) shadow is at:
http://www.melkert.net/action/download/shadow.sf

[N. W. Perry]

The venerable Fabuland shovel (4330) need snaps on its handle and shaft. (And is the actual part really that long??!)

[N. W. Perry]

I've processed up to message #48

And I also added a new bunch of files by Alex Taylor (incl some unofficial ones)

As always the latest (test) shadow is at:
http://www.melkert.net/action/download/shadow.sf

I'm a little unclear how the shadow.sf file in the seeds directory relates to the shadow libraries in Application Data. How do the newly added parts get into the official library, and what if I'm using a custom library, containing all the official content but also whatever new files I've added?

Just want to be sure I'm not updating the hard way. :-)

[Roland Melkert]

I'm a little unclear how the shadow.sf file in the seeds directory relates to the shadow libraries in Application Data. How do the newly added parts get into the official library, and what if I'm using a custom library, containing all the official content but also whatever new files I've added?

The contents of .sf (plain zip) files are synchronized with the per user location at program start.

This way each user can setup their own bins and options etc, while still having defaults out of the box.

It will only update existing files and remove obsolete ones, if you got additional custom content that will not change.

If you are using an unpacked shadow it shouldn't affect you at all, unless you unpack the updated shadow (.csl) in the user location again.

[N. W. Perry]

The contents of .sf (plain zip) files are synchronized with the per user location at program start.

This way each user can setup their own bins and options etc, while still having defaults out of the box.

It will only update existing files and remove obsolete ones, if you got additional custom content that will not change.

If you are using an unpacked shadow it shouldn't affect you at all, unless you unpack the updated shadow (.csl) in the user location again.

What I've been doing is copy the offLib.csl to my own custLib.csl, then I unpack that and use it as my shadow library so I can save corrections and new shadow files.


So if I understand correctly, my process should be:

• -Before installing the new .sf, I should re-pack my custom library to custLib.csl
  
• -Set custLib.csl as my library so that it will synchronize
  
• -Install the new .sf and re-launch LDCad
  
• -Re-unpack custLib and switch to that directory when I want to make more changes
  

I should now have all updated files, plus whatever new ones I'd made (unless they were corrections to existing files, which are now replaced with your updates). Right?

[Orion Pobursky]

What I've been doing is copy the offLib.csl to my own custLib.csl, then I unpack that and use it as my shadow library so I can save corrections and new shadow files.


So if I understand correctly, my process should be:

• -Before installing the new .sf, I should re-pack my custom library to custLib.csl
  
• -Set custLib.csl as my library so that it will synchronize
  
• -Install the new .sf and re-launch LDCad
  
• -Re-unpack custLib and switch to that directory when I want to make more changes
  

I should now have all updated files, plus whatever new ones I'd made (unless they were corrections to existing files, which are now replaced with your updates). Right?

No. You'll destroy your customizations if you do that. You have have more that one shadow library. Better to have a separate shadow library that only contains your altered/added files much like is done with unofficlal parts. Then your custom lib will override the "official" Roland supplied one.

[N. W. Perry]

No. You'll destroy your customizations if you do that. You have have more that one shadow library. Better to have a separate shadow library that only contains your altered/added files much like is done with unofficlal parts. Then your custom lib will override the "official" Roland supplied one.

But I actually want the Roland-file to override mine, that's OK. I only want to keep any of my additional files that haven't made it into the "official" package yet. It sounded like those wouldn't get overwritten.

For unofficial parts it's no problem; the shadow info can even be baked into the main file. For official parts, you can only choose one shadow library per search path, but I suppose I can duplicate the official search path (same main folder, but different shadow libs). Keep the offLib as a zipped library, and use an unpacked one for saving my own additions/corrections. Would that work?

[Roland Melkert]

But I actually want the Roland-file to override mine, that's OK. I only want to keep any of my additional files that haven't made it into the "official" package yet. It sounded like those wouldn't get overwritten.

For unofficial parts it's no problem; the shadow info can even be baked into the main file. For official parts, you can only choose one shadow library per search path, but I suppose I can duplicate the official search path (same main folder, but different shadow libs). Keep the offLib as a zipped library, and use an unpacked one for saving my own additions/corrections. Would that work?

The .sf will sync offLibShadow.csl as a whole.

So you'll need to unpack it (again) yourself. I sugest first renaming the original unpacked folder so you can visualize changes with e.g. winmerge.

Each search location has only one shadow as the content will be appended to the pure part files before parsing start.

[N. W. Perry]

The .sf will sync offLibShadow.csl as a whole.

So you'll need to unpack it (again) yourself. I sugest first renaming the original unpacked folder so you can visualize changes with e.g. winmerge.

Each search location has only one shadow as the content will be appended to the pure part files before parsing start.

Got it. So I'm already doing it correctly (re-naming and re-unpacking the synced official library). The difficulty is just that MacOS doesn't have a convenient way to merge folders if they contain sub-folders, so I have to do that part manually.

[Jaco van der Molen]

Part 39794 Technic Beam 11x7 with Open Center 9x5 is missing snap info for the pinholes on the sides.

[Magnus Forsberg]

Part 39794 Technic Beam 11x7 with Open Center 9x5 is missing snap info for the pinholes on the sides.

The same info is missing on the bigger frame 13 x 9, 39790

[N. W. Perry]

Gate 42448 needs cyl snaps on at least the shortest of the verticals, where you'd normally clip it.

[N. W. Perry]

The big plastic wheels need cylinder snaps:

6118.dat

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 16   R 8 42] [pos=0 0 8] [ori=1 0 0 0 0 -1 0 1 0]

2593.dat

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 16   R 8 4] [pos=0 0 -2] [ori=1 0 0 0 0 -1 0 1 0]

2515a.dat and 2515b.dat

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 16   R 8 6] [pos=0 0 -2] [ori=1 0 0 0 0 -1 0 1 0]

[Jaco van der Molen]

Plate  1 x  1 Round with  3 Leaves 32607 needs snapping info at the bottom stud.
It only snaps at the top stud now.

[Stefan Frenz]

Door 1x5x8.5 (87601) does not snap into Brick 1x1x3 with Two Clips (60583b)

[Stefan Frenz]

Staircase Spiral Axle (40244) does not snap into Tile 2x2 with Pin (2460) nor into Plate 2x2 with Pin (2476a)

[N. W. Perry]

Bug-eye 30208.dat needs a grid of studs and a big 40R cylinder:

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=R 6 4] [grid=C 4 C 4 20 20]
0 !LDCAD SNAP_CYL [gender=M] [caps=one] [secs=R 40 4] [pos=0 -4 0] [ori=1 0 0 0 -1 0 0 0 -1]
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=R 38 4] [pos=0 -4 0] [ori=1 0 0 0 -1 0 0 0 -1]

[Jaco van der Molen]

Can 96910 (Tile 1 x 2 Chamfered with 2 Top Indentations) also get a snap in the center?

[Stefan Frenz]

The bottom of Plate 1x1 Round with 3 Leaves (32607) does not snap into anything, I think it should snap into standard stud.

[Jaco van der Molen]

Wheel spoked 4489b needs to snap to 4488 (plate 2x2 with pin) for example.

I believe this will do the trick
0 !LDCAD SNAP_CYL [group=wpAxHole] [gender=F] [caps=one] [secs=A 4 10 R 5 2] [pos=0 0 8] [ori=1 0 0 0 0 -1 0 1 0]

[Jaco van der Molen]

Plate 1x2 with thick C-clip 63868 only snaps to the left and right side bar pieces of 2540 Plate 1x2 handle.
Should also snap to the center bar.

[Jaco van der Molen]

Minifig Flame/Plume triple 64647 should also snap at the small bar piece to snap to parts with clips (like 60475b Brick 1x1 with clip vertical Thick C-clip)

0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 4 6] [center=true] [slide=true] [pos=0 -3 0]

[Jaco van der Molen]

Brick 1x2x5 without inner ridges (46212a) does not have snap info at the bottom, only the studs on top.

0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=S 6 20] [pos=0 120 0] [grid=C 2 1 20 0]

[Jaco van der Molen]

Part 4739 Treasure Chest Lid should have snap info for the studs too.

0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=30 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=10 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=-10 0 0]
0 !LDCAD SNAP_CYL [ID=studC] [gender=M] [caps=one] [secs=R 6 4] [pos=-30 0 0]

[Jaco van der Molen]

Plate 1x2 with thick C-clip 63868 only snaps to the left and right side bar pieces of 2540 Plate 1x2 handle.
Should also snap to the center bar.

This seems to be fixed, although it can be a little tough to fit it to the middle bar since the outer parts seem to win it from the middle snap info.

[Roland Melkert]

I've processed all up to msg #75

I also added lots of info for the 20-01 library (I'm behind 3 libraries now )

As always the latest (test) shadow is at:

http://www.melkert.net/action/download/shadow.sf

Minifig Flame/Plume triple 64647 should also snap at the small bar piece to snap to parts with clips (like 60475b Brick 1x1 with clip vertical Thick C-clip)

I fixed the snap info but due to a bug in the snapping solver it won't snap correct, this will be fixed in 1.7 Alpha 1.

[Jaco van der Molen]

I've processed all up to msg #75

I also added lots of info for the 20-01 library (I'm behind 3 libraries now )

As always the latest (test) shadow is at:

http://www.melkert.net/action/download/shadow.sf


I fixed the snap info but due to a bug in the snapping solver it won't snap correct, this will be fixed in 1.7 Alpha 1.

Great! Looking forward to 1.7 Alpha 1 ;-)

[Jaco van der Molen]

Part 28192 Slope Brick 45  2 x  1 with Cutout and without Stud is missing snap info.

should be something like this?

0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=S 6 4] [pos=0 8 0]
0 !LDCAD SNAP_CYL [gender=M] [caps=one] [secs=R 6 4] [pos=0 24 -20]

[Roland Melkert]

should be something like this?

Almost,

I woud add this to s\28192s01.dat :

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=S 6 4] [pos=0 8 0]
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=S 6 4] [pos=0 24 -20]

[Jaco van der Molen]

Almost,

I woud add this to s\28192s01.dat :

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=S 6 4] [pos=0 8 0]
0 !LDCAD SNAP_CYL [gender=F] [caps=one] [secs=S 6 4] [pos=0 24 -20]

[Jaco van der Molen]

Dish 2x2 both 2654a.dat and 2654b.dat have no snap info.

[Jaco van der Molen]

Slope brick 45 2x1 inverted 3665a.dat has no snap info at the bottom.

[Stefan Frenz]

Wheel 2.8x34 [] for Wheel Holding Pin (4489a.dat) does not snap into Plate 2x2 with Wheel Pin (4488.dat).

[Jaco van der Molen]

Brick  2 x  2 with Ball Socket Type X and Axlehole

57910 and 92013 (type 1 and 3) are both missing the snap info for the ball in the socket.
62712 (type 2) does have this.

I think you can copy the info from 62712 to both 57910 and 92013?

[Roland Melkert]

I think you can copy the info from 62712 to both 57910 and 92013?

I added:

Code:

0 !LDCAD SNAP_CLEAR [ID=axle]
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 8  A 6 16] [pos=0 24 0]
0 !LDCAD MIRROR_INFO [baseFlip=Z] [counterPart=self]

to all three, and variations of:

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 5] [pos=40 10 11.5] [ori=1 0 0 0 0 1 0 -1 0]
0 !LDCAD SNAP_GEN [group=techBallJnt] [gender=F] [bounding=sph 12.7] [match=size] [placement=free] [pos=40 10 0] [mirror=none]

The half socket subparts.

[Jaco van der Molen]

I added:

Code:

0 !LDCAD SNAP_CLEAR [ID=axle]
0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 8  A 6 16] [pos=0 24 0]
0 !LDCAD MIRROR_INFO [baseFlip=Z] [counterPart=self]

to all three, and variations of:

Code:

0 !LDCAD SNAP_CYL [gender=F] [caps=none] [secs=R 6 5] [pos=40 10 11.5] [ori=1 0 0 0 0 1 0 -1 0]
0 !LDCAD SNAP_GEN [group=techBallJnt] [gender=F] [bounding=sph 12.7] [match=size] [placement=free] [pos=40 10 0] [mirror=none]

The half socket subparts.

Thanks!
Is the shadow updated?
http://www.melkert.net/action/download/shadow.sf

[Jaco van der Molen]

41682 Bracket 2 x 2 with 1 x 2 Vertical Studs does not snap at the bottom of the 1x2 plate.

[N. W. Perry]

Wheel rim 2998 does not snap correctly to wheel hub 2999. It ends up rotated 90° from where it should be.

[Roland Melkert]

Wheel rim 2998 does not snap correctly to wheel hub 2999. It ends up rotated 90° from where it should be.

This is one of those parts I haven't seen in real life (didn't even realize the pairing), so I took a guess on it.

How should 2999 be positioned with a 2998 at 0,0,0?

edit, I think this should work:

2999a.dat

Code:

0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 32] [pos=0 0 9] [ori=0 -0 -1 1 -0 0 -0 -1 0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 32] [pos=0 0 -9] [ori=-0 -0 1 1 -0 0 0 1 0]

2998.dat

Code:

0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 23 3  R 20 4  R 18 56  _L 19 2] [slide=true] [pos=0 -31 0] [ori=0 0 1 0 -1 0 1 0 -0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=M] [bounding=cyl 17 32] [pos=0 1 0]

[N. W. Perry]

The numbers are mixed up…but this is what works for me:

2998a.dat

Code:

0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 23] [ori=0 0 -1 1 0 0 0 -1 0]

Position should stay at 0 0 0, and there doesn't seem to be a need for the second snap. This wheel only seems to fit one way.

2999.dat

Code:

0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 23 3   R 20 4   R 18 56   _L 19 2] [slide=true] [pos=0 -31 0] [ori=0 0 1 0 -1 0 1 0 0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=M] [bounding=cyl 17 23] [pos=0 11 0]

This is fine with the pos adjusted to 0 11 0. (The original was 0 12 0 and was off by 1 LDU.)

[Max Martin Richter]

The numbers are mixed up…but this is what works for me:

2998a.dat

Code:

0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 23] [ori=0 0 -1 1 0 0 0 -1 0]

Position should stay at 0 0 0, and there doesn't seem to be a need for the second snap. This wheel only seems to fit one way.

2999.dat

Code:

0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 23 3   R 20 4   R 18 56   _L 19 2] [slide=true] [pos=0 -31 0] [ori=0 0 1 0 -1 0 1 0 0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=M] [bounding=cyl 17 23] [pos=0 11 0]

This is fine with the pos adjusted to 0 11 0. (The original was 0 12 0 and was off by 1 LDU.)

The hub is free movable in the arm without the wheel. But it should snap to its final position in LDCad, I think.
The wheel can be connected in one way only. It's not possible to connect it with the backside turned to the outside.

[Magnus Forsberg]

Is it possible, and maybe even wanted, to have 2907 snap to the inside of the hub 2999 ?

[N. W. Perry]

The hub is free movable in the arm without the wheel. But it should snap to its final position in LDCad, I think.
The wheel can be connected in one way only. It's not possible to connect it with the backside turned to the outside.

The arm is 6540a/b, by the way. I did check the fit of all three parts, and with the 0 11 0 position on the wheel rim, everything lines up snugly.

[N. W. Perry]

Is it possible, and maybe even wanted, to have 2907 snap to the inside of the hub 2999 ?

Good question…I am not fortunate enough to have owned the set these parts came in (but can you guess what I've been building?). But while 2907 is meant to rotate on XZ along with 2999, it is also meant to pivot independently on XY. So perhaps snapping is not recommended?

[Philippe Hurbain]

Good question…I am not fortunate enough to have owned the set these parts came in (but can you guess what I've been building?). But while 2907 is meant to rotate on XZ along with 2999, it is also meant to pivot independently on XY. So perhaps snapping is not recommended?

I think it can snap: this is the same kind of joint type as 32494/92906.

[Roland Melkert]

Good question…I am not fortunate enough to have owned the set these parts came in (but can you guess what I've been building?). But while 2907 is meant to rotate on XZ along with 2999, it is also meant to pivot independently on XY. So perhaps snapping is not recommended?

Seems logical, acting like a compact universal joint like in real cars.

   

[N. W. Perry]

Seems logical, acting like a compact universal joint like in real cars.

Hey, they more possibilities, the better!

Will the snapping data depend on the orientation of the grooves (as was recently corrected in the PT)?

[Roland Melkert]

Will the snapping data depend on the orientation of the grooves (as was recently corrected in the PT)?

It could if it uses a generic sphere meta using absolute placement.

That would get it in a good starting position, so the user can slide it inside and rotate/bend the attached axle later on.

Like so (including the corrections reported above)

2999.dat

Code:

0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=R 23 3  R 20 4  R 18 56  _L 19 2] [slide=true] [pos=0 -31 0] [ori=0 0 1 0 -1 0 1 0 0]
0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=M] [bounding=cyl 17 32] [pos=0 2 0]

2907.dat

Code:

0 !LDCAD SNAP_GEN [gender=M] [bounding=sph 15] [ori=0.92388 0 0.382683 0 1 0 -0.382683 0 0.92388]

2998a.dat

Code:

0 !LDCAD SNAP_GEN [group=techWhlCon1] [gender=F] [bounding=cyl 17 32] [pos=0 0 9] [ori=0 0 -1 1 0 0 0 -1 0]

optimally it would need a new snap connection (sphere in a tube), but I'm not sure it would really be that more helpful.

[N. W. Perry]

optimally it would need a new snap connection (sphere in a tube), but I'm not sure it would really be that more helpful.

I was thinking of something like the SLIDE property, where it snaps in one place but can then freely rotate.