Hi Mario,
I would say that information that is specific to -one- part should be in the part's file. We have the cost of a larger part file and information some people may not care about, but we have the benefit that an author looking at the part file will see the entire part file. There is no risk of an edit to the graphical shape of the part getting out of sync with connectivity.
We also need information about sets of parts, and I am not sure that that belongs in part files. For example, defining types of connections from families, or defining relationships between families might better be in a separate file.
This is true -if- we "expand" all connectivity into the part. But the 2x4 brick already has 8 studs, each of which has 16 triangles, 16 quads, 16 optional lines, and 16 real lines...that's 528 floats not counting the extra goo for optional lines!
LDraw gets around this by describing the 2x4 brick as a series of primitives that factor common shapes. We can leverage this by putting a stud connector onto the stud primitive directly (once) and thus it is copied by file inclusion.
In fact, I would argue that a strong reason to have the "spatial" aspect of connections on the parts themselves is so that they can be placed on a primitive and the natural structuring of the library helps spread connectivity to a lot of parts without a lot of hand editing.
There is a question of how much physics data ends up in the library, and whose model it follows. But without a clear model for how interactions are described, I think it's too soon to worry about that; there are still some fairly tricky open issues.
For example, consider the 1x2 hinge brick and its mail/female hinge connectors. The male half of these hinges are also used in a series of plates that can be jammed into the 1x2 brick base. But the range of legal motion is a function of which -pair- of parts was used. Where does this data go, and how is it described?
Right - you have gone the route that SR3D (and probably other) apps have gone, and as long as connectivity is not a public standard, it's really the only sane way to start connectivity; a side table so that you can get work done without having to hack up your library. And for an initial app where you need to make a lot of edits or describe a lot of connectivity, one big file is a win.
I think in the short term even for a public standard we need some side file format for data that will -someday- be in the .dat files so we can develop prototype software.
In the long term, however, I think that -if- the Ldraw community accepts connectivity as a native part of the format, then we really need the connectivity data to be visible to all part authors.
And if the community accepts connectivity in the library, it also sends a message to app authors that "yes, connectivity is here for you to use" and encourages app developers to leverage the data instead of rolling their own.
Cheers
Ben
I would say that information that is specific to -one- part should be in the part's file. We have the cost of a larger part file and information some people may not care about, but we have the benefit that an author looking at the part file will see the entire part file. There is no risk of an edit to the graphical shape of the part getting out of sync with connectivity.
We also need information about sets of parts, and I am not sure that that belongs in part files. For example, defining types of connections from families, or defining relationships between families might better be in a separate file.
Mario Pascucci Wrote:Adding all these information to a .dat can easily result in a file size explosion. Take a plain 2x4 brick: it has 19 connection points (8 studs, 11 underside stud receiver, counting three tube center), that requires (with my present connection model) 38 coordinates as x,y,z floats, 19 "type" definitions: if "type" can be represented as a single integer, we have a total of 114 floats and 19 integers.
This is true -if- we "expand" all connectivity into the part. But the 2x4 brick already has 8 studs, each of which has 16 triangles, 16 quads, 16 optional lines, and 16 real lines...that's 528 floats not counting the extra goo for optional lines!
LDraw gets around this by describing the 2x4 brick as a series of primitives that factor common shapes. We can leverage this by putting a stud connector onto the stud primitive directly (once) and thus it is copied by file inclusion.
In fact, I would argue that a strong reason to have the "spatial" aspect of connections on the parts themselves is so that they can be placed on a primitive and the natural structuring of the library helps spread connectivity to a lot of parts without a lot of hand editing.
Quote:If someone isn't interested in connectivity, including it in .dat lead to more complexity in parsing and greater library size.
If you include other mechanical and physical data, it could be worse, it could be rain!
There is a question of how much physics data ends up in the library, and whose model it follows. But without a clear model for how interactions are described, I think it's too soon to worry about that; there are still some fairly tricky open issues.
For example, consider the 1x2 hinge brick and its mail/female hinge connectors. The male half of these hinges are also used in a series of plates that can be jammed into the 1x2 brick base. But the range of legal motion is a function of which -pair- of parts was used. Where does this data go, and how is it described?
Quote:Not counting a lot of work needed to maintain library as a whole. Keep data in different places can helps to distribute the work and effort needed. File format can be same of .dat. I chose XML for my personal preferences and the universality of use in Java classes and libraries, but I can do a converter to transform in any other choice format.
Right - you have gone the route that SR3D (and probably other) apps have gone, and as long as connectivity is not a public standard, it's really the only sane way to start connectivity; a side table so that you can get work done without having to hack up your library. And for an initial app where you need to make a lot of edits or describe a lot of connectivity, one big file is a win.
I think in the short term even for a public standard we need some side file format for data that will -someday- be in the .dat files so we can develop prototype software.
In the long term, however, I think that -if- the Ldraw community accepts connectivity as a native part of the format, then we really need the connectivity data to be visible to all part authors.
And if the community accepts connectivity in the library, it also sends a message to app authors that "yes, connectivity is here for you to use" and encourages app developers to leverage the data instead of rolling their own.
Cheers
Ben