Ben Supnik Wrote:- In your system, it's all geometry, and the matches are strictly geometric. In other words, ALL cylinders of the same radius are going to fit equally well into a hole of the same radius.
Is that correct?
Yes in a perfect world this is what I really want. But I've had to make some compensations for the time being. Like anti studs, I would really like them to snap into large rectangles when such a shape would enclose them, but I decided to keep it one on one for the time being by defining them as a grid of radius 6 F-cylinders.
Ben Supnik Wrote:And if I understand: every geometric type that we find in the LDraw world will have to be supported by some geometry primitive that is built into the spec. In other words, the fact that your example is part cylinder, part axle works because both cylinders and axles are native to your code. If we ever have a part with a new, different cross section (where the axle's cross section is not a + shape) we'll possibly need a new geometry primitive and spec extensions.
Yes, at the moment the CYL meta supports round, axle, square and 'lock' (see below). I'll add more if I find parts needing it. Only hard coded about these shapes at the moment is a bool matrix that determines what shape fits another when using the same radius, I could move that to some config / include file if it must be user extendable.
Ben Supnik Wrote:Also, how would you handle pins? A pin is a cylinder with a wide rim - it only fits into the technic brick hole (a cylinder hole with a wider hole at the edge) because it can be compressed. It effectively provides one degree of rotational freedom once it is snapped in, although it has longitudinal movement freedom (and a lot of friction) while it is being inserted into the hole.
This is a single pin half definition (e.g. connect3.dat):
0 !LDCAD SNAP_CYL [ gender=M ] [ caps=one ] [ secs=R 8 2 R 6 16 _L 6.25 2 ] [ pos=0 0 0 ] [ ori=1 0 0 0 1 0 0 0 1 ]
It will fit in any cylindrical hole that matches the radius's pattern, the _L part indicates the 6.25 radius can be ignored while fitting (it uses the preceding radius for the core tests instead, hence the '_' in front). When something fits based on those conditions, things are reexamined to see if the '_L' portion still fits while using it's true radius.
This works in the current build. only downside is a full pin will inherit two definitions and therefore snaps depending on your view on the scene (you can see that in the clip). I've solved this recently by redefining the shape as a whole inside 3673.dat (no code changes just the def), like so:
0 !LDCAD SNAP_RESET
0 !LDCAD SNAP_CYL [ gender=M ] [ caps=none ] [ secs=L_ 6.25 2 R 6 16 R 8 4 R 6 16 _L 6.25 2 ] [ center=true ] [ ori=0 -1 0 1 0 0 0 0 1 ]
0 !LDCAD SNAP_CYL [ gender=F ] [ caps=none ] [ secs=R 4 40 ] [ center=true ] [ ori=0 -1 0 1 0 0 0 0 1 ]
In this case reset drops all inherited stuff, but the meta supports dropping only a certain (user named) group.
For example the axle4.dat has info, which is fine for stacks of parts. But some parts use that primitive as part of a larger cylindrical shape, you can then drop that specific info meta inside that parts definition to redefine a more precise (round/axle mixed) shape. But the 'simple' one will do just fine for the parts not having full information yet.
I've created about 180 definition files up to now, and I must say overall I'm very pleased by it's behavior, there are some issues I have to figure out some more but that's nothing new when trying to set up a new feature.