New header meta proposal: 0 !BOM

[Philippe Hurbain]

This meta would be followed by a short string (max length to be defined, 6 chars is probably OK) containing the length of the element (or any other string that would help distinguish a part from another). That string would be displayed next to the part image in BOMs and in editors parts bin. Counting holes or studs in tiny thumbnails of a part is tedious at best, distinguishing a 9L axle from a 10L one is next to impossible...
Possible extension:
0 !BOM V string
where V would be a "verbose level", the editor or BOM generator would only display text below some user defined level. It would be the responsability of part author to set this level at a sensible value, 1 beeing "most useful to be displayed", 2 "useful", 3 "if you insist you may display this"...

[Gerald Lasser]

I think this is definitely worth to think about it!

Currently (source edits form Jan 2014) LPUB does looks for the last section of the title for on certain parts "Technic Beam", "Technic Axle", "Technic Axle Flexible", some RCX cables and VEX beams, to find its annotations.

There are indeed more parts that need annotations, especially later in the instructions as well, like the Technic Panels.

Do you want to use this meta command also for instructions and propose a default handling in the meta, like axles usually display them in a circle, panels, beams in a square? May be too much and leave it up to the instruction mining program.

[Roland Melkert]

Seems like a useful meta indeed.

How would you handle the level parameter though?

It might become very messy if at some point a new level is introduced while loads of parts are using e.g. 1, 2, 3. Causing the the new one to be e.g. sort of 2.5.

So we probably should use 'enum' strings for the level, that way a new level can be inserted by updating the spec.

Also !BOM made me think you wanted to list a models material list or something until I read 'part files'. I like Gerald's annotation term better so maybe !ANNOTATION ?

I'm I right to understand this is usually length related information, if so it might be useful to split the info into a value and a unit so software can convert the value to whatever they need (mm, inch, etc)

Just my 2 LSB cents

[Philippe Hurbain]

Good points as usual! I agree that !ANNOTATION is better, and a separate units field is an excellent idea.

[Roland Melkert]

Is this still alive / wanted ?

How about, for e..g an axle 6

0 !ANNOTATION high L 6

or for e.g. a wire:

0 !ANNOTATION high mm 250

Making the format something like:

0 !ANNOTATION <low|high> <mm|L|ldu|pcs|mm2|mm3> VALUE

where value must be a number or do we need an optional (short) string encapsulated with " "?

Although I must admit I'm not certain the 'level' is really needed, what was your initial goal for that information Philo ?

Anybody more ideas on this?
What to the other LSB members think?

edit: forgot pcs could be used in generated chains etc

[Gerald Lasser]

Seen from an instruction point of view there are currently two different ways to display the annotation:
- Number in a Circle: Axle Length
- Number in a Square: Beam Length and Type of Technic Panel.

In this case the unit for the length is what you call "L", for the Panels may be nothing, may be "TYPE"

Seen from digital building, the annotation for the Axles might be the most interesting in the context Philo mentioned. The Technic Panels would be pretty visible in the icon which they represent, however if shown it is not bad in my opinion.

Parts that may be difficult to distinguish might also be Tires...

so I would (at least) like

0 !ANNOTATION <mm|cm|L|ldu|pcs|mm2|mm3|TYPE> VALUE

e.g. for a panel:
0 !ANNOTATION TYPE 22

[Steffen]

may I suggest
0 !INSTRUCTIONTEXT
or
0 !INSTRUCTION TEXT
or
0 !CAPTION
or
0 !TEXT
or
0 !TXT
just for consideration?

[Philippe Hurbain]

Although I must admit I'm not certain the 'level' is really needed, what was your initial goal for that information Philo?

The idea was to set some usefulness degree, and let the user choose verbosity level of instructions. Axle annotation is almost mandatory, beams annotation is almost useless for shortest ones, useful for medium length, very useful for long ones. Problem is that I foresee endless discussions according to reviewers sensibility...

Seen from an instruction point of view there are currently two different ways to display the annotation:
- Number in a Circle: Axle Length
- Number in a Square: Beam Length and Type of Technic Panel.

So, should we also have a style parameter + enum (plain, circled, boxed)?

[Merlijn Wissink]

Seen from an instruction point of view there are currently two different ways to display the annotation:
- Number in a Circle: Axle Length
- Number in a Square: Beam Length and Type of Technic Panel.

So, should we also have a style parameter + enum (plain, circled, boxed)?

I think that it would be best to not include any style information.
Style is something that can and will be changed to whatever the editor and/or user wants, so it would be useless to include style information.

[Philippe Hurbain]

Agreed, style depends on personal preference. But this somehow defeats one of the purpose of the "Annotation" metacommand: avoid the need to parse the description to figure out what to display. I have trouble figuring out a coherent sheme between what is encoded in part, what is BI author personal preference and what remains BI software configuration realm...

[Roland Melkert]

We should indeed separate information from style, this is why I'm wondering if the level isn't subject to it too.

The software could setup an internal guide on when to display something or not e.g. based on the unit and value. For example the 'L' unit is used to describe axle lengths so a program could decide for it self at which length it want to display it.

So if short beams are 'low level' maybe all we need to do is assign them a suiting unit like 'holes', then the program can do e.g:

Code:

if (unit==auHoles && value>3) renderAnno();

[Gerald Lasser]

I think the 'unit' and 'length' information should be sufficient. Having this information the way of displaying this information can be derived. "Axle" && "Length" == Round, "Beam" && "Lenght" == Square, "Type" == Square.

[Philippe Hurbain]

Good point, unit and length probably does the trick, both for "level" and for style.

[Gerald Lasser]

Another thought.

This information should somehow be instantly available. now for LDCad, are you using the "part.lst" file r do you scan the library on your own? LPUB is loading the part.lst file to determine if this part is a known part.

It would then be a consequence that the part.lst file would contain the extracted annotation or at least an information that there is something to gather from the .dat file. Otherwise the you need to scan each part in the application itself to look for annotations being present.

What do you think?

[Philippe Hurbain]

Very good (and annoying) point. LDCad doesn't use parts.lst (just add parts in one of your parts folder and they are immediately available when you restart LDCad).

[Roland Melkert]

parts.lst only holds the dat name and description, I maintain my own cache file (parts.inv) with LDCad which also hold category, keywords, location information and some attributes (e.g. shortcut) and it does this for all registered libraries combined.

I don't know what LPub uses but I don't think it would need much change to use the annotation meta if it becomes official.

On that matter I'm still waiting on the thoughts of the other LSB members about this meta, or should I start a topic in the LSB forum ?

[Travis Cobbs]

As a new member of the LSB, I'm going to jump in here and say that it seems reasonable to me to create such a meta, and to make it legal in part headers. Having said that, while I don't personally have a whole lot of input right now, I feel that all values should be in some pre-defined unit.

In other words, I think we need to pick one single allowed unit to use for length (I would vote for LDU), and set in stone that that is the only allowed unit to be used in the meta. Software paying attention to the value can give the user the option of what units to display the information in (studs, LDU, mm, cm, etc., where studs would probably be the default length unit), but I don't think the meta-command itself should support more than one of each supported type of unit (length, area, volume, etc.).

Please note that I don't feel strongly about my point above. It just seems that the information would be more useful if it had a concrete meaning, as opposed to just being a string. But maybe I've just spent too much time thinking about BIM in my day job.

[Roland Melkert]

I agree on minimizing the unit strings but I think it should be possible to use different ones for the same thing e.g.

Axles use 'L' in instructions. (number of studs)
Rope and hoses use mm in instructions.

How would a program know what the default unit to use if everything is always given in LDU?

[Philippe Hurbain]

I think indeed we need a unit field to get some display flexibility.

[Lasse Deleuran]

This topic has unfortunately not been updated since 2015. What was the general consensus back then? Or was there even a consensus?

I think adding multiple levels of detail, type information and computed lengths is good in theory.
However. In practice I see very little need other than a simple 'annotation/text/help/pli' line for the parts where this is of interest. You can then add your own annotation to 'built' or generated parts, such as bent flex hose. This will also be my suggestion should there be interest for adding this to the standard.

In the past couple of days I have added PLI annotations to my website. I have pasted a couple of snippets below. These are currently saved in the database on a per-part level with just a simple text string, such as "#5", "12L", etc.



It will be very easy to automatically add these annotations to .DAT files in whichever format we agree on, thus automating most of the update process to enrich the library with PLI annotations.


PS. Shout out to Philo for adding this amazing model to the OMR repository. It is great for debugging - especially TEXMAP!

[Jaco van der Molen]

This topic has unfortunately not been updated since 2015. What was the general consensus back then? Or was there even a consensus?

I think adding multiple levels of detail, type information and computed lengths is good in theory.
However. In practice I see very little need other than a simple 'annotation/text/help/pli' line for the parts where this is of interest. You can then add your own annotation to 'built' or generated parts, such as bent flex hose. This will also be my suggestion should there be interest for adding this to the standard.

In the past couple of days I have added PLI annotations to my website. I have pasted a couple of snippets below. These are currently saved in the database on a per-part level with just a simple text string, such as "#5", "12L", etc.



It will be very easy to automatically add these annotations to .DAT files in whichever format we agree on, thus automating most of the update process to enrich the library with PLI annotations.


PS. Shout out to Philo for adding this amazing model to the OMR repository. It is great for debugging - especially TEXMAP!

Interesting thread.
Working with LPub3D you can use annotation too, but not as nice as Lasse's.
Are those images?

[Lasse Deleuran]

This topic has unfortunately not been updated since 2015. What was the general consensus back then? Or was there even a consensus?

I think adding multiple levels of detail, type information and computed lengths is good in theory.
However. In practice I see very little need other than a simple 'annotation/text/help/pli' line for the parts where this is of interest. You can then add your own annotation to 'built' or generated parts, such as bent flex hose. This will also be my suggestion should there be interest for adding this to the standard.

In the past couple of days I have added PLI annotations to my website. I have pasted a couple of snippets below. These are currently saved in the database on a per-part level with just a simple text string, such as "#5", "12L", etc.



It will be very easy to automatically add these annotations to .DAT files in whichever format we agree on, thus automating most of the update process to enrich the library with PLI annotations.


PS. Shout out to Philo for adding this amazing model to the OMR repository. It is great for debugging - especially TEXMAP!

Interesting thread.
Working with LPub3D you can use annotation too, but not as nice as Lasse's.
Are those images?

Those are actually generated on the fly. I am currently working on making the algorithm behind them even faster. it is already quicker than my previous instructions generator that uses still images. 


Ideally it should end up being near instantaneous for all but the largest of models. There is still a lot to work on.

[Jaco van der Molen]

Interesting thread.
Working with LPub3D you can use annotation too, but not as nice as Lasse's.
Are those images?

Those are actually generated on the fly. I am currently working on making the algorithm behind them even faster. it is already quicker than my previous instructions generator that uses still images. 


Ideally it should end up being near instantaneous for all but the largest of models. There is still a lot to work on.

Nice.
I know Trevor (Sandy) is innovating this in LPub3D too.