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:1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.
This is nothing new, both SR3DBuidler as my own LDCad use this approach.

Ben Supnik Wrote:2. Building new specific primitives designed to create "connection combinations" that are common.
I think it's already in the making as the discussion of an anti stud primitive came by awhile back.

Ben Supnik Wrote: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.
I still think describing shapes is the better approach for these kinds of things Wink

Ben Supnik Wrote: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.
There's connhole.dat, that's the one I use in LDCad, but that file doesn't cover all technic hole occurrences e.g. the last hole in beams etc.

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).
I agree, even if there is no additional info in the file given such an indication would be usefull as it shows it has none. This could be thre result of all the info being inherited (e.g. new minifig torsos).

Ben Supnik Wrote:(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.)
I'm not to happy with how iit went with the texture spec as it basically was take it as a whole or leave it. I'm also a bit disappointed in the fact it's still not really used.

Ben Supnik Wrote: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....
No offense to Mario, but his method is nothing new. If anyone should be credited for setting up the basics of connection handling it should be Sergio.

We started talking about official connection models before on the forum, but for some reason it went nowhere every time. The main reason for that (i think) was people where afraid it would not be adopted by the tools. Even Sergio indicated he would never use it even if it became official. Something I did not really understand at the time. But now I also have my own format i kinda do, you own system just leaves more room to operate. On the other hand it would be very useful to use the default official info as the fallback or basis for snapping at least.

Anyhow I just wanted to get the above of my chest as it was kinda eating at me.
Roland Melkert Wrote:
Ben Supnik Wrote:1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.
This is nothing new, both SR3DBuidler as my own LDCad use this approach.

Good! I would love to see a connectivity spec built entirely out of already-proven ideas!

Quote:I still think describing shapes is the better approach for these kinds of things Wink

Should we have a serious discussion of this?

Quote:
Ben Supnik Wrote: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....
No offense to Mario, but his method is nothing new. If anyone should be credited for setting up the basics of connection handling it should be Sergio.
I'm not trying to claim that Mario was the first to design a connection model of this type. I am saying that I am hijacking his work in that he designed something, wrote a spec, posted it for feedback, and then I came along and started discussing it (1) in a bigger scope (e.g. for all of LDraw and not just his app) and (2) with additional functionality (supporting at least some physical operations and not just snapping).

Quote:We started talking about official connection models before on the forum, but for some reason it went nowhere every time. The main reason for that (i think) was people where afraid it would not be adopted by the tools. Even Sergio indicated he would never use it even if it became official. Something I did not really understand at the time. But now I also have my own format i kinda do, you own system just leaves more room to operate. On the other hand it would be very useful to use the default official info as the fallback or basis for snapping at least.

I think you are referring to the previous discussion where I was looking to build "related parts" (something we shipped in Bricksmith) and was shopping it around to see if anyone else was interested. At the time I wasn't pushing for connectivity because I didn't have time to get it done in Bricksmith - related parts is a much smaller, simpler feature (simpler than snapping by a lot).

Sergio was very generous in offering some kind of extract of SR3D connectivity data as a way to "seed" community data; his not wanting to redo his work was pretty understandable too!

At this point we are rapidly approaching at least four implementations of this feature (Sergios, yours, Henri's and Mario's). I always have the option to do a fifth with Bricksmith.

My thinking is that if I have to do the design work no matter what, if I can have the discussion with the community and incorporate other people's work, then it will be more likely that the end result will be something useful to multiple programs and not just Bricksmith-specific.

Cheers
Ben
Ben Supnik Wrote:
Quote:
Ben Supnik Wrote: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....
No offense to Mario, but his method is nothing new. If anyone should be credited for setting up the basics of connection handling it should be Sergio.
I'm not trying to claim that Mario was the first to design a connection model of this type. I am saying that I am hijacking his work in that he designed something, wrote a spec, posted it for feedback, and then I came along and started discussing it (1) in a bigger scope (e.g. for all of LDraw and not just his app) and (2) with additional functionality (supporting at least some physical operations and not just snapping).

For what is worth the basics have been laid out a long, long time ago, in a galaxy ...

http://www.ldraw.org/OLD/reference/specs/lcd/


Quote:We started talking about official connection models before on the forum, but for some reason it went nowhere every time. The main reason for that (i think) was people where afraid it would not be adopted by the tools.

Guys it's in your hand. If you come up with something we just have to adopt I guess we will do just as we did with the texture thing - well, it would be nice if the community or the LSC could also throw in their 2 cents once you have presented it.

w.
Hi Ben.

Ben Wrote:1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.

This is not always true, and I need a "visual check" for every part I add in connectivity library. At the moment, I found some parts designed using primitives as mere geometric shortcut, but ignoring the semantic meaning. Some examples:
- parts 59426.dat and 32209.dat (axle 5.5 with stop): parts are axles, but uses axlehol8.dat as primitive for axle. If you use "axlehol8.dat" (defined as "Axle hole perimeter") to detect a "female" connection for axle these two parts will becomes axle holes 5.5 unit long for connection logic.
- part 4727.dat uses a "peghole.dat" as a base. I don't know, but should be better use a stud4.dat, I think. If you use this part with autodetect, a "peghole" connection is placed in a totally wrong position
- part 3680.dat: an inverted peghole.dat to obtain central hub.
- 32556.dat: an inverted peghole.dat to obtain the flange.
just to say some.
I don't say that LDraw library is wrong, absolutely NO. But, until now, it was used as a geometric shape definition library, with defined primitives used as shape shortcut, sometime regardless the primitive meaning and defined purposes.

So, including connectivity to primitives is surely a good starting point, but at the present state of library it can lead to unwanted/weird connectivity issues: you need to delete some connections derived by primitives in final part. This is a major issue in autodetect strategy. In my connection library some parts are inserted only to avoid autodetection, that includes unwanted and wrong connection points.

This is why I take so long to add new parts in connection library: I must check every single part connection in connection editor before add to list of "correctly autodetected" or add a ".cxml" file to library.

Mario
I would go so far as to say that using the specialized, non-generic primitive for something other than their intended use is wrong and were I review such a part on the Parts Tracker I'd would probably give it a Hold vote. Scaled studs at another example of what I would consider primitive misuse.
Mario Pascucci Wrote:
Ben Wrote:1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.

This is not always true, and I need a "visual check" for every part I add in connectivity library. At the moment, I found some parts designed using primitives as mere geometric shortcut, but ignoring the semantic meaning. Some examples:
- parts 59426.dat and 32209.dat (axle 5.5 with stop): parts are axles, but uses axlehol8.dat as primitive for axle. If you use "axlehol8.dat" (defined as "Axle hole perimeter") to detect a "female" connection for axle these two parts will becomes axle holes 5.5 unit long for connection logic.

Right - this is a risk with "primitive"-based connectivity - when a primitive's semantic meaning is abused for its geometric shape, we introduce a connectivity problem.

I agree with Orion: in my opinion the best long term option for the library is:
- Primitives have "semantic" meaning. Use stud.dat when you mean a lego stud, not just when you have a cylinder.
- Parts that have wrong connectivity due to "abuse" of primitives should be fixed by changing which primitive is used.

This is a fundamental change to the library, so the community (or LSC or SteerCo or??) would have to agree to this change in library policy as part of an implementation plan. It's not a trivial change.

But my view is that in the long term it's better to fix "abused" primitives than to have to build all connectivity data separately and check it. The power of LDraw is in the leverage the primitive system gives us*; I think the alternative is a much slower, longer process for building connectivity meta-data.

cheers
Ben

* If we are not going to leverage having primitives, we might as well just create each part out of a triangle soup and model them in a 3-d modeler. :-): -)
Mario Pascucci Wrote:So, including connectivity to primitives is surely a good starting point, but at the present state of library it can lead to unwanted/weird connectivity issues: you need to delete some connections derived by primitives in final part. This is a major issue in autodetect strategy. In my connection library some parts are inserted only to avoid autodetection, that includes unwanted and wrong connection points.

Exactly, this is why I use the SNAP_CLEAR meta in LDCad in order to drop (some) of the inherited information in certain files in order to redo it in the local file.

Another problem might be the continuation of e.g. a hole present in a primitive (e.g. stud with hole) into a higher part. The stud with hole primitive might have the hole defined as it's used manytimes as is (so not it's only 4ldu deep). But in some parts it continues into the higher structure (e.g. a 1x1 round brick) and has to be dropped / redone.

But in the end the inheritance system is mostly very positive, you just need to 'certify' all bricks just like with BFC mechanism.
Ben Supnik Wrote:But my view is that in the long term it's better to fix "abused" primitives than to have to build all connectivity data separately and check it. The power of LDraw is in the leverage the primitive system gives us*; I think the alternative is a much slower, longer process for building connectivity meta-data.

Not necessary If inheritance problems are corrected on in the higher parts followed by 'certifying' the part it self it won't matter. Although new parts should just prevent it of course.
Willy Tschager Wrote:Guys it's in your hand. If you come up with something we just have to adopt I guess we will do just as we did with the texture thing - well, it would be nice if the community or the LSC could also throw in their 2 cents once you have presented it.

I would prefer a group effort from the start, but I do realize that would take ages Smile But I certainly would not like it to go the way as it did with the texture extension. Proof of this is in it's (non) usage imho.
Roland Melkert Wrote:
Willy Tschager Wrote:Guys it's in your hand. If you come up with something we just have to adopt I guess we will do just as we did with the texture thing - well, it would be nice if the community or the LSC could also throw in their 2 cents once you have presented it.

I would prefer a group effort from the start, but I do realize that would take ages Smile But I certainly would not like it to go the way as it did with the texture extension. Proof of this is in it's (non) usage imho.

Hi Roland,

I think this -is- a group effort. There are already multiple people involved in the discussion; some day, some time later, we will somehow come up with a draft, and at that point a more formal process can take place (e.g. an elected committee will make a final decision or request mandatory changes).

What steps should we take this early on to make sure that anyone who wants to be included is included?

cheers
Ben
Pages: 1 2 3 4 5 6