LDraw.org Discussion Forums

Full Version: Experimental part snapping in LDCad 1.3
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
Hello all,

I've been working on part snapping for my LDCad editor. It's progressing nicely but I would love some feedback / opinions from people in order to fine tune things.

The current version works quite nicely with low connection point parts. The problem arises when you use parts with multiple valid snap points (e.g. the holes in 1xn tech beams). Currently it snaps based on z sorting, but there is room for improvement there.

I've uploaded short clip of the feature in action.

The used scene contains most of the parts with full snap information. Snapping is done 100% trough meta information on the existing part files. This is done using a shadow library, which acts like an auto include location. Content of identical named files in the shadow location are added to the official ones from the LDraw lib during loading. Information can also be inherited as a result all minifig torso/leg/hip/hand/arm parts have information by just creating 6 shadow files.

edit: second version, see below post.

Second version demo clip


All suggestions are welcome
Could you make it an optional feature? These calculations would bring LDCad to its knees when trying to load Datsville. I never was able to get Datsville to load successfully in SR 3D Builder for instance.

Also, it's too bad there is no official library of connection data. That way software makers could pool their efforts.
It's already an option, it will even be disabled by default.

My goal is/was never to go full snapping. I'm seeing it more as an aid for placing the awkward parts.
> Also, it's too bad there is no official library of connection data

in the hinterlands of our minds there is the idea of adding this information to the library itself,
the same way as currently just the geometry.

in a way, it already is contained there implicitly, for example, stud.dat not only means
that there is something LOOKING like a stud but also SNAPPING like a stud.
and so on.

the only question is how to put this info into the library.

I strongly favor _not_ putting this into a special "connection table" as a separate file,
but instead use a per-part, i.e., de-central approach.

the connectivity information would be reviewed the same way as currently the geometry of a part.

to me, the ideal way to model that would simply be using primitives for that:

we already have stud.dat.
we can invent a new primitive which carries the meaning "fits onto a stud".

it will contain no visible geometry at all, just carry the information where a stud could snap.

a part file would place this wherever needed, for example, a 2x4 brick will have
2x4 usages of this suggested primitive on its underside.
we could even create stugs of it Smile,
so filesize is not really an issue.
and renderers would not be affected, as these files would not bring in _visible_ geometry.

however, for debugging/visualization purposes, they could.
a user then could _see_ where the snapping places are.

the same mechanism could be used not only for stud.dat, but also for others.
example: c-clip. it can snap for example on a long cylinder. so if a part has such a region,
it would place a "c clip snapper" primitive there, scaled properly to fully extend over the cylinder's length.

software then easily can detect that there a c-clip can snap.

the only information we need to store somewhere is which
2 primitive pairs match for snapping, e.g.
stud.dat snaps to snap-stud.dat.
c-clip.dat snaps to snap-c-clip.dat.
axle.dat snaps to axlehol.dat.
and so on.

i feel that our library is already very near to this. its logic and structure already BEG for a feature like this.



EDIT: I just found the old thread discussing ideas like this: http://forums.ldraw.org/showthread.php?t...97#pid8797
Maybe we can use the connection information as Sergio did in his awesome SR3D-Builder.

We could use a meta command and add these connectivity information where it belongs to, so that we don't need extra files...


/Max
Quote:Maybe we can use the connection information as Sergio did in his awesome SR3D-Builder.
I totally agree! hopefully he should get an unification of connectivity information - and clearly Sergio does have the lead here... (*)
Quote:We could use a meta command and add these connectivity information where it belongs to, so that we don't need extra files...
...but here I dont agree that much. I think that keeping connectivity outside main files has much more chances to happen than making a major overhaul of the library - afterall it already happened! Lets be pragmatic...

(*editSmile... but there is room for improvement. Eg. there is no automatic orientation of axles placed into axleholes.
Results look pretty good already! I guess that you didn't yet address the rotation of parts around connexions?
Not yet but most parts have a logical center, so setting the grid to the parts orientation make rotating e.g. a minifig's arm relatively easy after the initial placement.
Also the needed information can differ a lot depending on what you want to do with it. In my approach I've choosen to describe shapes instead of connection types. So the software doesn't know anything about studs/pegs etc, it's only matching shapes against other shapes.

For example this is info I'm using for the 5.5 axle.

0 !LDCAD SNAP_CYL [gender=M] [caps=none] [secs=A 6 18 R 8 2 R 6 8 A 6 80] [center=true] [pos=-1 0 0] [ori=0 -1 0 1 0 0 0 0 1] [slide=true]

The engine will test this against other shapes, and if it fits it will snap to it along it's y axis. The above will go (partly) into a peghole because it's shape is simular (they share a radius 6 section, and the other sections are larger):

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


I've tried using as many primitive's possible for defining the info but I'm somewhat disappointed on that subject. It seems many primitives are 'misused' somewhat degrading their snap information on the higher level. For example the axle.dat primitive seems to be used for internals alot (Isn't is mend to be used open ended only?). Also some primitives are used mirrored (messing up orientation) although I managed to compensate for that somewhat. And finally there are a lot of parts that don't use primitives where they should, for example most tehcnic beams are missing the last peghole if only inherited info is used.
Interesting approach. The good point is that it could allow some non-standard assemblies, but it seems a daunting task (for software and for defining connectivity)...
Quote:axle.dat primitive seems to be used for internals alot (Isn't is mend to be used open ended only?)
Purpose of primitives was originally to simplify parts authoring, and had nothing to do with connectivity. Axles and axleholes have the same shape, so share the same primitive! Maybe you could discriminate with bfc invertnext prefix...???
Quote:most tehcnic beams are missing the last peghole if only inherited info is used.
??? afaik all holes of beam use either beamhole or connhole or peghole primitive...
Pages: 1 2 3 4