Chris Dee Wrote:However, I do prefer putting the connectivity metadata in the existing part file, so long as that is expected to percolate up from the primitives and subparts (which I hadn't grapsed from the previous discussion).
That's exactly what I had in mind. I think there are two ways this can go:
1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.
2. Building new specific primitives designed to create "connection combinations" that are common.
As an example of the second, under Mario's scheme, a technic connector hole that is standard to the 1xN beams has a pile of connection information for:
- Jamming studs into either end or
- Putting pins through the hole with rotation or
- Putting axles through the hole with rotation or
- Putting friction pins through the hole as a rigid (but not directionally limited) connection.
There are other ways to model connections that would recycle some of this data, but in the end we're almost guaranteed to need more than one connector annotation. (As an example of why, consider that the technic axle brick can take only an axle, while the regular technic brick can take an axle or studs in the ends.)
So someone could make a primitive that wraps up all of that "technic hole" info into one .dat file - sort of a molecule out of atoms.
The two techniques aren't incompatible.
Quote:I would like to see a meta-statement in the header section to indicate that connectivity is included (in a similar way that BFC CERTIFY implies winding info is included).
That seems pretty sane...my plan for this was:
1. Keep poking at Mario's spec until the open issues for the "design" of connectivity are sorted out.
2. Go code an actual working prototype and see how it works. I think this is pretty important for "proving" the data design in practice.
3. Come back and create a more detailed spec proposal that can then get ironed out for issues like how files are meta tagged in the library, compatibility, syntax, etc.
4. Further revise my own code to match the final spec.
(I am very willing to rewrite my own code if the spec needs to get modded. I don't know what happened with the texture extensions, but comments on the forums imply that it was delivered to the LSC "take it or leave it". I don't think that's particularly fair to the community, and it doesn't help get the best ideas into practice.)
Mind you this is a bit of a hijack or Mario's work! But it's sort of luck that he posted something that was complete and readable right as I was starting to dig into this again....
chers
Ben