LDCad Part Snapping Guidelines

[Jason McReynolds]

So in working on adding some part snapping info I've got some questions about guidelines. Maybe it's the perfectionist in me and I'm over thinking this, but I'm not sure about the "correct" way to add snapping meta to a couple parts I've run across. I'm also pretty new to all this, so maybe it's spelled out somewhere else and I just haven't run across it yet. Anyway, two examples below with questions about how to "correctly" add the snap meta.

First Example:

   

Above is Part 60849, Minifig Hose Nozzle with Side String Hole Simplified. For this piece, it would make sense to stop a piece from sliding past the trigger on the nozzle and the handle, highlighted in green in the picture on the left. However, if you configure it this way and as you can see in the middle picture, the red area has no snap meta and parts will not snap to that area. Clips should, however, be able to snap to the red area. If I modify the part to allow clips to snap to the red area, then that allows parts to slide past the handle and end up in an "illegal" (overlapping) position, as in the picture on the right.

Second Example:

   

Same as the first example, but with part 3959, Minifig Torch. If you want to prevent pieces from sliding past the handle, as in the top set of pics, you'll end up with an area (see red square on second row) where there's no snap meta and pieces (clips) will not snap to that location. However, clips should be able to snap to the red area.

Also, as you can see in the bottom set of pictures, depending on the piece, one could end up colliding with the nozzle and end up in an overlap position.

So, my questions...

It would seem that in order to get clips to snap in the red area you would also have to allow pieces to end up in positions where they overlap. Same goes for allowing all parts to travel the full distance of the handle in the second example. Is this how it should be done (i.e. allow overlap)? Or, is there a way to add meta to allow all of these combinations without allowing overlap? Are there any guidelines I should be following in situations like this? Am I over thinking this?

[Roland Melkert]

It would seem that in order to get clips to snap in the red area you would also have to allow pieces to end up in positions where they overlap. Same goes for allowing all parts to travel the full distance of the handle in the second example. Is this how it should be done (i.e. allow overlap)? Or, is there a way to add meta to allow all of these combinations without allowing overlap? Are there any guidelines I should be following in situations like this? Am I over thinking this?

Yes currently if you want clips to go at the red area you need to extend the meta to cover it, at the cost of normal holes to go there too. Or just move the clip using the editing pin move control after initial placement (might need a relative grid).

I encountered this problem myself while working on part 60849, the reason the hand pin extends into the red area as I thought it would be used the most by minifig hands.

A better solution would be to add new snap properties to SNAP_CYL to indicate a section can only be used combined with clips. This is something I'm considering. But as the current snapping feature is meant to be a guide and not full multi point / occupied / collision detection etc, I'm wondering if it is really needed. Such an option would also require all clip metas to be correctly orientated gap wise, but I think most of them already are (through dumb luck .

In the meantime try to optimize info for use in the most likely scenarios, or at least in a way which will not hamper normal usage.

[Jason McReynolds]

It would seem that in order to get clips to snap in the red area you would also have to allow pieces to end up in positions where they overlap. Same goes for allowing all parts to travel the full distance of the handle in the second example. Is this how it should be done (i.e. allow overlap)? Or, is there a way to add meta to allow all of these combinations without allowing overlap? Are there any guidelines I should be following in situations like this? Am I over thinking this?

Yes currently if you want clips to go at the red area you need to extend the meta to cover it, at the cost of normal holes to go there too. Or just move the clip using the editing pin move control after initial placement (might need a relative grid).

I encountered this problem myself while working on part 60849, the reason the hand pin extends into the red area as I thought it would be used the most by minifig hands.

A better solution would be to add new snap properties to SNAP_CYL to indicate a section can only be used combined with clips. This is something I'm considering. But as the current snapping feature is meant to be a guide and not full multi point / occupied / collision detection etc, I'm wondering if it is really needed. Such an option would also require all clip metas to be correctly orientated gap wise, but I think most of them already are (through dumb luck .

In the meantime try to optimize info for use in the most likely scenarios, or at least in a way which will not hamper normal usage.

Thanks, sounds like I was worrying about it too much at this point. I had thought about the addition of additional properties as well (like an additional secs property "C" for clips), but figured that, at this point in time, you had other things at the top of your list you were working on. Things work pretty well now anyway for quick and easy assembly, the perfectionist in me was taking over.

Keep up the great work!

[Owen Dive]

I think that a guiding principle should be that it's better to allow things that couldn't happen in real bricks than to disallow things that could. (I'm pretty sure I've paraphrased that from reading it somewhere else on this forum, possibly written by Philo).

[Philippe Hurbain]

Quite possible, since I completely agree with this

[Willy Tschager]

As much as I love seeing people join in to work on a project I'd like to remind you that, as it currently stands, we do NOT have a standard for a connection database yet.

The LSB 2015/2016 has been set up to harmonize the four models we currently have:

LDCad
JBrickBuilder
Bricksmith
SR3D

Cementing one of these models by the sheer number of working parts is not fair towards the other programmers. Once more I beg the LSB to start working on the issue.

w.

[Milan Vančura]

Hello Willy.

I must say I'm really looking forward to time when snap data is standardized. I hoped for that in times of my contributions to SR3DB, already. However, there is no such standard yet, even not started (as far as I know). And my job is to make (real) models for exhibitions which are organized now - and so I need a help of a good editor with good snap data now. It's the only way how I can make my models in time. Every help is welcome and snap data is such a (big!) help.

The result is that I have to accept the risk that my work for any specific editor may be lost or isolated out of standard in future. I know about that risk and I even knew about much higher risk with SR3DB I helped with in past - because it was a private, closed-source project which could become inaccessible at any moment. And that happened, most of my work there is lost, as far as I know. But I have no other option than to accept this risk - that's why I contribute to all these editors and I continue to do so.

And the last note: the only work on SR3DB I made and it persists over the project death is my snap data contribution - as it is the public part of SR3DB, including at least the basics of the format specification. And the format specification/description was published by Sergio only because he saw so big interest of other people to contribute snap data. Otherwise you would have nothing to discuss for future standard about SR3DB now. So I believe it makes sense to contribute snap data to editors even before the standard is settled up - with all risks mentioned above.

[Philippe Hurbain]

Yes it may be unfair, but I tend to think that a working scheme, especially if it is well documented (as it is the case here) is a very good base for a "de facto" standard...

[Willy Tschager]

I tend to think that a working scheme, especially if it is well documented (as it is the case also here) is a very good base for a "de facto" standard.

w.

PS. Every time I think back when we adopted a "de facto" standard for the last time a cold shiver runs down my back.

[Jason McReynolds]

As much as I love seeing people join in to work on a project I'd like to remind you that, as it currently stands, we do NOT have a standard for a connection database yet.

The LSB 2015/2016 has been set up to harmonize the four models we currently have:

LDCad
JBrickBuilder
Bricksmith
SR3D

Cementing one of these models by the sheer number of working parts is not fair towards the other programmers. Once more I beg the LSB to start working on the issue.

w.

Wow, didn't mean to stir things up with this post and had no idea I would! I'm just new to the community and excited about this feature, even though there isn't a formal standard around it yet.

I'm just getting started with LDraw and have gravitated to LDCad because I personally prefer it over the others. Finding out that LDCad now allows me to edit snap data (although experimental and potentially invalid once a standard is created) was a huge bonus, in my opinion, because I don't have to wait for "whatever" to get updated before I can use that feature for parts that are missing that data. It allows me to build things much faster and spend less time fussing with part placement. Who doesn't want that?

I don't think anyone here is trying to gang up on anyone and I don't think they are trying to be unfair to the other developers either. If someone makes a great product that offers great features that people want, people will use it, even if there are risks involved. That's not the fault of the creator of the product.

With that said, I realize that I'm kind of an outsider here but it appears to me that something like this could take a very long time to standardize and be available to the general public. I got excited when I ran across a post about the LCD, but then also found this. Almost a year later and not much appears to have been done, and I have no idea when that was initially proposed. Please don't get me wrong, I'm not pointing the finger at anyone, I'm just trying to point out that part snapping appears to be something that people have wanted for a while now. This is somewhat evidenced by the 4 applications you list, which have taken it upon themselves to create their own part snapping info because that info was/is not readily available and doesn't appear to be any time soon.

With that said, I would tend to view interest in this feature for LDCad more as a positive thing, and would hope that the interest it is generating would fuel the creation and acceptance of a new standard so that everyone could collaborate and enjoy this great feature.

[Roland Melkert]

As much as I love seeing people join in to work on a project I'd like to remind you that, as it currently stands, we do NOT have a standard for a connection database yet.

I'm all for setting up a standard but how do we prevent those discussions to fade out some time later as they always seem to do up to now.

Cementing one of these models by the sheer number of working parts is not fair towards the other programmers. Once more I beg the LSB to start working on the issue.

I agree with this but I must admit even when an official standard is available I might still keep going with my own and use the official one as a starting point / import. This because having full control over the data while tweaking the snapping behavior etc is a very big freedom to loose.

We might also be able to convert some of the existing info from multiple existing formats to a new format as the core data (positions and rotations) will be shared by any format as they result from the part shapes.

Also I'm not sure it is even possible to invent a format which will be ok to use for everyone as the info needed greatly depends on what the programmer want to do with it. So in the end we might need to limit the standard to some kind of hint system upon which the using software can add its own requirements.

[Willy Tschager]

Wow, didn't mean to stir things up with this post and had no idea I would! I'm just new to the community and excited about this feature, even though there isn't a formal standard around it yet.

Don't worry, you're doing fine. It's just the fact that we struggle with this connection database for TEN YEARS now. First we had none for a long long time. Now we have 4 different standards and I cannot the see the light at the end of the tunnel.

w.

[Willy Tschager]

As much as I love seeing people join in to work on a project I'd like to remind you that, as it currently stands, we do NOT have a standard for a connection database yet.

I'm all for setting up a standard but how do we prevent those discussions to fade out some time later as they always seem to do up to now.

You mean the high definition library, the lower case library, the !BOM meta, ...? Since I really want to have a connection database before the fancy rest let me be the watch dog of the LSB and I promise to bring it to a good end, will you?

w.

[Milan Vančura]

Hello Willy:

as I do not have right to reply in "Connection database" thread, I put the link here:

SR3D Builder connection data format is described at

http://sr3dbuilder.altervista.org/TechnicalIssues.html

You can put it at placeholder place

I remember there was also a short discussion at some forum (ldraw, eurobricks, sr3d forum...) but I cannot find it now, unfortunately. Sergio described the algorithm using this data - at least basics. Maybe Philippe remembers that? He also made some connection files for SR3DB.

BTW, it's not friendly of this forum it does not allow me to contact you via personal message Now I have to hope you read this thread, still.

[Philippe Hurbain]

I remember there was also a short discussion at some forum (ldraw, eurobricks, sr3d forum...) but I cannot find it now, unfortunately. Sergio described the algorithm using this data - at least basics. Maybe Philippe remembers that? He also made some connection files for SR3DB.

It's here: http://forums.ldraw.org/showthread.php?t...84#pid8184 AFAIK the most complete documentation - I sent a mail to Willy about this 20 min. ago...

[Willy Tschager]

BTW, it's not friendly of this forum it does not allow me to contact you via personal message Now I have to hope you read this thread, still.

Hi Milan,

this has been discussed before:

http://forums.ldraw.org/showthread.php?t...63#pid5963

but I'll forward your request to the SteerCo - maybe minds have changed in the meantime. Feel free to contact the webmasters at webmaster[AT]ldraw[DOT]org if you're looking for an email address.

w.