New stud primitive (underside)

[Christian Neumann]

The recently uploaded Mini Snake brought the idea about preventing (auto-)connectivity issues of LDraw related software. The part contains an simple underside stud, but none of the existing stud primitives can be used without a lot of tweaking of the original part shape (see comment about stud4o.dat).
The basic idea is to "convert" the 4-4cylc to a new stud primitive, and then use it instead of the cylc. This step is not forced by the LDraw Standard, but the more i think about it, the more i'm convinced that this last step is worth to be done. If it becomes official, i doubt it will ever be done.
I attached the prototype of that new underside stud. As i have no idea how to name and describe it, help me please to complete it.

[Max Martin Richter]

I think the origin should be moved4 LDU in Y-direction to match with stud23.dat.

Code:

1 16 0 4 0 6 0 0 0 -4 0 0 0 6 4-4cylc.dat

And I would suggest: 'stud24.dat' because it doesn't match any other stud prims.
Description could be something like: 'Round underside stud hole'.

Maybe we can update stud4o.dat with this prim later?!

/Max

[Michael Horvath]

The BFC seems messed up in LDView. Is it supposed to be this way?

[Christian Neumann]

I think it is because it's an underside stud. If the BFC INVERTNEXT is removed from the primitive, it has to appear before every usage.
The origin has to be moved indeed.

A corrected file version is attached, name still not clear.

[Philippe Hurbain]

Looks good. As for file name, stud25? (stud24 is already taken)

[Michael Heidemann]

I like the idea, but I dislike your suggestion.
_IF_ we are going to introduce such new primitive it should be in a kind that it can be used at many places.

This can only be used if there is a round hole with a closed stop at the end. I can not think of any more specific. But we need something general here.

If I think this line nearly to it's end (it is not the end), then the only really necessary information is how deep a stud will go into this part. For this purpose we need only a 4-4edge maybe named "studdepth" and that needs to be placed at the coordinates that the stud can reach at maximum inside a hole.

As I told before, this is still not the end.
What about all the parts that do have square underside studs - we need a new primitive.
What about all the parts with round stud connection hold from the side - we need a new primitive.
What about ...... (there are many more).

Again, I like the idea in global and just forcing a scheme for the towball (or whatever name we agree on) connections.
But that is an easy task.
The stud is one of the most global usable connections and therefore needs a very good plan for introducing.

Until today we do not have connectivity rules and I think that is a good point. The connectivity can be done outside of the parts. With all benefits and disadvantages. See for this SR3D and I was told that it works great. Why not simply use that?

If this part comes to the pt i will for sure not certify. As i know there are other opionion than mine i will also not hold it. But I have strong doubts that this file will do the job for what it is designed.

[Philippe Hurbain]

If I think this line nearly to it's end (it is not the end), then the only really necessary information is how deep a stud will go into this part. For this purpose we need only a 4-4edge maybe named "studdepth" and that needs to be placed at the coordinates that the stud can reach at maximum inside a hole.

Here you have a point. A simple 4-4edge would be indeed much more universal. Actually I like this idea a lot.
(Edit) But a single edge doesn't determine clearly stud insertion direction...

What about all the parts that do have square underside studs - we need a new primitive.

I'm afraid I've already commited this one... (stud23)!

See for this SR3D and I was told that it works great. Why not simply use that?

Precisely, SR3D uses primitives as much as possible to reduce the burden of external connectivity files.

[Michael Heidemann]

Here you have a point. A simple 4-4edge would be indeed much more universal. Actually I like this idea a lot.

After more thoughts about this, we need additional information about the orientation.
Also we can not use in any case a 4-4edge because there might be no edge.

The more i think about this i came to the conclusion that we are too limited with our current linetypes as they are all designed to draw something. The connectivity we are talking about is not a visible detail.

Some guys may argue to use the meta commands, but i do not like this.

I propose a new linetype 6 - Connectivity.
Currently i am thinking of this like a linetype 1 but with a 6 in front.
Just for the stud problem the line will just reference to the stud primitive, but is meant as counterpart.
With this approach we can use all current applications (hopefully they will ignore linetype 6) and only need to add such lines where other connectivity is not possible by primitives that are visible.

I just did a test with linetype 6
MLCad - deletes that lines - don't know if it will ever be changed.
LDView - generates an error - should be possible to quickly be fixed
DATHeader - like to treat this as a comment line - can quickly be fixed

So maybe my idea is not ideal.

[Tim Gould]

If you are reproducing part 1 - why not introduce an invisible part?

e.g.

1 16 0 0 0 1 0 0 0 1 0 0 0 1 virtualstud.dat

[Michael Heidemann]

And what is the content of virtualstud.dat?

that are also visible lines and quads!

[Tim Gould]

3 16 0.0001 0 0 0 0.0001 0 0 0 0.0001

[Max Martin Richter]

What's about an empty "virtaulstud.dat" ?
The software use it's base and that's it...

/Max

[Michael Heidemann]

By using only a dummy no information about orientation is given. That does not solve our problem. But thanks for the idea.

[Michael Heidemann]

By using something like this no information about orientation is given. That does not solve our problem. But thanks for the idea.

[Michael Heidemann]

The idea is really not bad, but wrong linetype

If we use in these special connection part only one line like

studfemale.dat (i named it better this way)
5 16 0 0 0 0 0 0 0 0 0 0 4 0

we have the following information.
1) this file give errors due to identical vertices - but we do not need to check this file
2) the position where the third vertex is, is the entry point for the middle of the stud.
3) the position where the fourth vertex is, is the max. point that the stud should be able to reach.

By having this simple file an application can have all the information it needs for stud usage. IMHO.

[Tim Gould]

What do you mean no orientation information is given? 9 points + BFC are all you need to definte a plane and its normal. Indeed with that part it is simple since the three points will automatically give you the axis.

Tim

[Philippe Hurbain]

I like the idea, but would have preferred if it had been possible to "see" the condline if needed. Unfortunately, I have not found a way to properly hide the condline in MLCad for a non zero length.

[Steffen]

that's not correct.
an orientation -is- given by the matrix of the parent file.
we just have to state in a comment in the empty file that the stud placeholder's "up" direction as usual is pointing upwards the y axis.
an empty file here clearly can be used for the purpuse of supplying connectivity info.
it even could be scaled to indicate the stud depth/height.
AND
we could introduce many different such files for the many different kinds of connections we have.
we could even put some optional visible contents into them to make them more easily placeable.
we could use the technique of lsynth for that, ie, special meta commands which enclose that file's portion.

[Roland Melkert]

I like this idea, but you'll need to supply the depth of the hole though scaling.

And when doing so rules must be set (e.g. base y size of the empty file), so parsers can unambiguously extract the depth etc from the type 1 line.

Also not all antistuds are just simple cylinders, some are square (plates) some are part of larger rectangles (brick/plate without understud) etc etc.