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
Hi Ben.

Violation of primitive semantic meaning is one aspect. One other is how to "detect" as more connection points as possible without complex/extended math/geometric computation.

Some examples:
- stud4.dat/stud4a.dat (underside tube): I chose to assign five connection points to this primitive: one stud receiver for center hole and four stud receiver at top left/right and bottom left/right. Parts like 3062b, 4073, 15279, 2569, 3957b gets right connection points, but when a plate 6x6 is analyzed by connection detector, it gets 125 underside stud receiver, because every stud4.dat gets 5 connections, but some are duplicated: two adiacent stud4a have two coincident connection, so I use a trivial duplicate check to avoid connection duplication.
- stud3.dat (underside pin/stud): used in 1xn bricks, plates and tiles, I chose to assign three connections: two stud receiver on sides and a pin-to-open-stud connection on pin base. In a 1x4 brick there are three stud3.dat, so there are two duplicated connection on adiacent pins, that duplicate checker detects and removes, but still connection placement is wrong in lots of parts because I chose to put connections on left and and right sides (along X-axis), when in some part pin is rotated or part is designed along Z-axis, so connection are wrong placed. No easy correction is available, so I need to do a visual check and manual editing.
- 1x1 bricks, plates and tiles: no primitives can be used to place a connection, because all of them uses basic shapes, like box5.dat.

At the present status of library I didn't find a simpler and safe way to detect connections from primitives, this is why I made a connection editor and a connection library.
Surely it is a my limit, and a limit in my coding/math/geometric skills. I don't even think to propose my model as a standard for LDraw library. I released specifications, code and sample only in hope that it was useful to anyone. Nothing more.

Mario
Ben Supnik Wrote:I think this -is- a group effort.
Yes, but the texture extension wasn't. Something I really want to prevent in a possible connection / snapping spec.

Ben Supnik Wrote:What steps should we take this early on to make sure that anyone who wants to be included is included

I think the main thing is to get (more) part authors involved, to see what they are thinking / want.

And, less important, move the discussion to the standards forum so it's clear we are talking about a general official connection model candidate.
There has been talk about adding a 'anti stud' primitive which would basically be an empty primitive. If this comes through new parts using that primitive would no longer need corrections.

But like most improvements in the library it's unlikely old parts will be updated unless other defects are discovered in them. So your manual work won't be for nothing.
I agree that these parts should be fixed. We already cleaned a lot of parts that used stud primitives for capped cylinders, but a few old parts still use similar (bad) tricks.

Mario Pascucci Wrote:- 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.
Clearly we need to define an inside-out version of axlehol8.dat to fix these parts.
Quote:- 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.
All these parts are easy to fix, but these situations are not easy to detect visually. I think we should create a special thread to report these abuses.

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.
That's why SR3D and LDCad (http://forums.ldraw.org/showthread.php?t...0#pid15510) offer a mechanism to clear auto-detected connectivity. But I much prefer some wrong additional connection to missing ones Wink

Quote:Scaled studs at another example of what I would consider primitive misuse.
I don't think this is an issue connectivity wise... Or is it ?
Hi all.

I released two more files:
- connection editor as a "portable" package
- connection editor source code

I didn't have time to write a manual for editor, but user interaction and functions are identical to model editor.

Program is sketchy and misses lots of design helpers, but "it works™"

(Added above link to main message in this thread, too)

Mario
Philippe Hurbain Wrote:
Quote:Scaled studs at another example of what I would consider primitive misuse.
I don't think this is an issue connectivity wise... Or is it ?

It depends on the type of connection and / or the origin of the primitive. But in general scaling (and even mirroring) should not be a real problem while inheriting information into higher parts as long you multiply the information's matrix (and optionally dimensions) too.

Also as mirroring and scaling can be detected you could decide to drop the info.

In Mario's model for example a scaled stud is no longer a stud and should be dropped, an axis on the other side should just apply the scale as long it's only the Y axis which is changing.

In LDCad it will matter even less as I'm describing shapes so a stud.dat will still work when scaled it just won't snap to 'normal' anti studs anymore but only equally scaled ones.
Thanks for confirming my feeling Wink
Philippe Hurbain Wrote:That's why SR3D and LDCad (http://forums.ldraw.org/showthread.php?t...0#pid15510) offer a mechanism to clear auto-detected connectivity. But I much prefer some wrong additional connection to missing ones Wink

My pipe dream is that if we fix "abused" primitives there will be no need for a parent part to -delete- the connectivity of its child primitives. (For any app that uses the library "as-is" this kind of work-around is necessary because the app can't fix the problems at the library level.)

Does anyone have examples where this is necessary even if primitives are only used for their canonical purposes?

cheers
Ben
Are you allready fixing these, Philo?
If not let me know, and I'll start correcting them.
I can find about 10-12 parts using peghole.dat incorrectly.

3957a
s\777s02
4083
6140
4873
2486
4360
32556 (yes, 'Technic Pin Long' is using a peghole.dat incorrectly. Funny.)
3680

4727 is allready fixed and uploaded at PT

Is 57518 correct or also wrong?
Ben Supnik Wrote:Does anyone have examples where this is necessary even if primitives are only used for their canonical purposes?
It's needed with things like the axlehole primitive if you keep track of 'slide' limits. The primitive it self is open ended but it might be used in e.g. a motor drive axle which is not (e.g. 71427c01).

Also I sometimes just flush all inherited info in certain (more complicated) parts in order to redo it in a more organized / readable way. For example 43123.dat which also uses a complete pin part in a 'static' way meaning those pins should no longer connect on one side.

See attached snap info for those two parts.
Pages: 1 2 3 4 5 6