LDraw.org Discussion Forums

Full Version: JBrickBuilder connection model
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6
Ben Supnik Wrote:I'm afraid I don't follow. Are you saying that we:.....
I meant any connection info format which hopes to become part of the LDraw spec should be formatted into meta lines on a per .dat basis. (imho)

Nothing wrong with Mario's storage method but you indicated you would love to see this become a standard.
Ciao Roland and Ben.

I 'm wonder if embedding connection information in .dat is the best strategy.

As I say in other message, there are at least three class of information related to connections:
- snapping/joint information (connection points, orientation, ...)
- geometric/structural (bounding boxes, collision volumes, degree of freedom, ...)
- physical and mechanical (weight, frictions, rigidity, center of mass, ...)

My model cover only first class and, with some assumptions, can help to define degree of freedom. Trying to extend it to cover mechanical and physical property is anything but trivial (... and far, far beyond my programming/math/physics skills Big Grin ).
Some examples:
- a "click-hinge": it is relatively easy to define a connection that accepts only multiples of 22.5 degree (it is a prismatic connection), but to limit angle excursion (normally 180 degree, but without any other part interferes in rotation), define the weight that a hinge can support before slide down, requires lot more data and math.
- a gearbox, or a group of gears: my model can help on how to connect gears and align teeth, but to define how rotation, speed and torque is transferred require lot more information. And... what if you place three gears in triangle?

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.

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! Big Grin

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.

Mario
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.

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! Big Grin

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
This is a tricky issue.

I think the main question to ask to decide whether supplementary information (e.g. connectivity metadata) is stored within the part file is 'How often would a correction to the part geometry affect the connectivity metadata?'. If 'hardly ever', then I favour a separate file structure for connectivity info.

That way connectivity information does not have to be repeated in patterned versions of parts with identical geometry.

I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best. That's not to say that the conectivity library (or indeed the parts library) couldn't be distributed as a consolidated, optimised file, effectively a complied version of the library. So long as the tools understand how to deal with that.
Chris Dee Wrote:That way connectivity information does not have to be repeated in patterned versions of parts with identical geometry.
In such a case the snap info should be added to the e.g. 'without front face' subpart.

Chris Dee Wrote:I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best.
I think it's the power of LDraw, just look at how fast Philio sometimes prepares some unofficial part after a request. That wouldn't be possible if you had to repack the whole library every time. Also the per dat solution gives authors the chance to add info from the get go which probably results in less errors as they know the shape etc in and out.

The loose files also still gives us the option to generate a higher HQ library (basically a cache file) as we discussed a while back. So we could also add the connection info to that package but personally I would prefer it in the .dat's as diskspace isn't a real issue these days and it's also easy enough to use the library from it's zip without unpacking it if needed.
Hi Chris,

First, I second everything Roalnd said. :-)

Second, since we don't actually have a clear definition of what the connectivity data contains, this discussion may be premature.

With that in mind:

Chris Dee Wrote:I think the main question to ask to decide whether supplementary information (e.g. connectivity metadata) is stored within the part file is 'How often would a correction to the part geometry affect the connectivity metadata?'. If 'hardly ever', then I favour a separate file structure for connectivity info.

That seems like a slightly higher bar than other aspects of the library. For example, we don't put meta data on a part in a separate file because changing the part geometry is unlikely to change the part name or category.

My argument is that the connectivity is a -kind of- part geometry. In this case I'm definitely only arguing for including -connection location data- in the parts, and I'm not entirely sure what other kinds of data we will even ahve.

Quote:I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best.

I think this is a strong argument -in favor- of connectivity in the part. If connectivity was in a single consolidated file, how would we manage multiple authors editing connectivity data on separate parts. That's not an impossible problem (in fact, it's just source control) but we already have -existing- infrastructure based on one part one file that works well.

cheers
Ben
Ciao Ben.

Probably I'm excessively worried at this phase, when we are still talking of how to start Smile

Mario
When I wrote 'a separate file structure' I wasn't advocating a single consolidated file, rather a parallel file structure containing the connection info in a separate 'one file one part' hierarchy.

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). 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).
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
Hi Mario,

This may not help your worrying much:

http://forums.ldraw.org/showthread.php?tid=15486

I wanted to separate out the discussion of travel limits - one possible answer is "for my program, I do not care!" - if you do not need such data then the problem you have at hand is quite a bit simpler. :-)

cheers
Ben
Pages: 1 2 3 4 5 6