LDCad META commands.

[Orion Pobursky]

I'd like to make your connection spec official  We can still have the separate connection library and the bar for making it official can be lower and easier to update but I'd really like the connection data to be part of the official library.

I'm also leaning towards making you flexible connection METAs official as well.

I think these 2 areas are the 2 biggest areas where the official library falls down.

Thoughts?

[Roland Melkert]

I'd like to make your connection spec official  We can still have the separate connection library and the bar for making it official can be lower and easier to update but I'd really like the connection data to be part of the official library.

I'm also leaning towards making you flexible connection METAs official as well.

I would be honored

But to be honest some parts of the current snap implementation might be a bit over engineered.

So slimming down things might be a first step in any adoption process.

I'm planning on refining things in 2.0 and also try to take into account things like "occupation" exclusion etc.

So if we are really adventures we might consider designing the 2.0 version as a group.


As for the flexible meta's, those are very much to my own liking

The only missing part might be the possibility to generate things that branch out (e.g the power functions lights).

Haven't had any real thoughts on extending this for 2.0 though.

[Milan Vančura]

I'd like to make your connection spec official  We can still have the separate connection library and the bar for making it official can be lower and easier to update but I'd really like the connection data to be part of the official library.

I'm also leaning towards making you flexible connection METAs official as well.

I think these 2 areas are the 2 biggest areas where the official library falls down.

Thoughts?

From the user point of view: that would be great, snapping in LDCad works. The only what we need to keep is a way to improve it in future - I always wonder when somebody wants to cut something in an official stone

For example: I hoped LDCad 2.0 improves snapping:
* rotation snapping (a part snaps while you rotate it - I described it in some older LDCad thread)
* multisnap - while moving a bigger submodel, it snaps so all bricks snap. Including the (slight) model rotation.

And more...

So defining the standard in a way the current LDCad uses, plus allowing future improvements - that's the ideal from my POV.

[Roland Melkert]

From the user point of view: that would be great, snapping in LDCad works. The only what we need to keep is a way to improve it in future - I always wonder when somebody wants to cut something in an official stone

It would help to get snap info from the get go during part modeling.

* rotation snapping (a part snaps while you rotate it - I described it in some older LDCad thread)
* multisnap - while moving a bigger submodel, it snaps so all bricks snap. Including the (slight) model rotation.

This is what i called "occupation exclusion" above, technically it doesn't need any extra information it could be done using the current information but it would be extremely cpu intensive. So I'm looking into extra info which could help it speed up ether at the part level or by some sort of caching in the model it self.

[Lasse Deleuran]

I'd like to make your connection spec official  We can still have the separate connection library and the bar for making it official can be lower and easier to update but I'd really like the connection data to be part of the official library.

I'm also leaning towards making you flexible connection METAs official as well.

I think these 2 areas are the 2 biggest areas where the official library falls down.

Thoughts?

This would also be a huge help in auto-generating building g instructions, which is my current project.

[Lutz Gehlen]

Hi all,

disclaimer: I am a total novice to digital lego modelling, so please don't be too harsh if the following does not make sense/is obvious etc.

Could you clarify a couple of things?
1) Which LDCAD meta commands are you talking about exactly? Is it all PATH_* and SNAP_* commands? Also SPRING_*? Anything else?
2) What exactly does "making them official mean"? I suppose they will still be meta commands, won't they? Will they still start with !LDCAD or what will the syntax be?

More importantly, what does "making them official" mean for other editors/viewers? Does it mean for example that an editor that decides to implement snapping should do it this way instead of inventing its own meta commands? For that maybe an "official recommendation" would be sufficient instead of making it part of the standard. Or does it mean that every standard-compliant editor has to support these commands?

It is clear that Roland has put _a lot_ of work into these features. Requiring the authors of every other software who want to be compliant with the standard to do the same would be a substantial obstacle. I think it is a great advantage of the ldraw file format that it is so simple to implement and most advanced features are realized via optional meta commands. These issues could be mitigated if the official standard would come with an official reference implementation, i.e. an open source and platform-independent library for PATH_* and SNAP_* commands. Only Roland can tell how much work it would be to extract this functionality into such a library and whether he would be willing to do so.

Another question would be what this change means for parts authors. Will they be required to provide snapping information? My knowledge of parts definition and snapping information is so limited that I have no idea what that would entail.

These are my (somewhat spontaneous) thoughts on the subject. I hope you don't consider this as trespassing into an area which a ldraw novice should stay clear of.
Best wishes,
Lutz

[Roland Melkert]

Which LDCAD meta commands are you talking about exactly? Is it all PATH_* and SNAP_* commands? Also SPRING_*? Anything else?

Snapping mostly.

What exactly does "making them official mean"? I suppose they will still be meta commands, won't they? Will they still start with !LDCAD or what will the syntax be?

It would mainly give the part authors the option to include them (snapping info) into the official library.
If the meta becomes official the !LDCAD will be dropped. The exact format might also differ from the ones used now in LDCad. I'm open to any changes for the better

More importantly, what does "making them official" mean for other editors/viewers? Does it mean for example that an editor that decides to implement snapping should do it this way instead of inventing its own meta commands? For that maybe an "official recommendation" would be sufficient instead of making it part of the standard. Or does it mean that every standard-compliant editor has to support these commands?

Other editor could use the information knowing it won't change suddenly in the future.
You can still invent your own meta/snapping format but it would mean defining or converting all that information yourself.

[Orion Pobursky]

More importantly, what does "making them official" mean for other editors/viewers? Does it mean for example that an editor that decides to implement snapping should do it this way instead of inventing its own meta commands? For that maybe an "official recommendation" would be sufficient instead of making it part of the standard. Or does it mean that every standard-compliant editor has to support these commands?

It is clear that Roland has put _a lot_ of work into these features. Requiring the authors of every other software who want to be compliant with the standard to do the same would be a substantial obstacle. I think it is a great advantage of the ldraw file format that it is so simple to implement and most advanced features are realized via optional meta commands. These issues could be mitigated if the official standard would come with an official reference implementation, i.e. an open source and platform-independent library for PATH_* and SNAP_* commands. Only Roland can tell how much work it would be to extract this functionality into such a library and whether he would be willing to do so.

Part snapping support would be optional. It doesn't make since for every editor to have to support it (LDView is a prime example). The goal is to standardize how snapping information is encoded. SR3DBuilder had part snapping as well and when the author of that program passed away, his method also died. Roland has the benefit of having a robust and currently in use method to build off of. The META's are just information, how a future editor developer chooses use that information to implement the snapping is up to them.

Flexible part META would also be optional since the generated code will be included in the part. Once again, the goal is to standardize how we encode the information.

Another question would be what this change means for parts authors. Will they be required to provide snapping information? My knowledge of parts definition and snapping information is so limited that I have no idea what that would entail.

My opinion and desire is that snapping info be in a parallel library with less stringent review requirements. This allow someone more proficient to add the snapping info and doesn't force a part onto the PT for a snapping info update. Due to primitive use, much of this info can be added simply by updating primitives. If a part author chooses to supply it with a new part, great. However, if someone updates an official part that affects the geometry (rare) then they would also have to update the correspond snapping info.

Again, all of this is my desire/opinion, not an official position on implementation.