7475 BOM done with LDRAW tool support

[Joshua Delahunty]

As part of some work I'm going verifying inventories for 2005, I had reason to create a BOM (bill of materials) for 7475 Fire Hammer vs. Mutant Lizards [note: 2005 was the first year TLG started to experiment with BOMs in their building instructions -- it was limited in scope, and none of the Dino BI had this feature].

My BOM generation uses LDVIEW as its renderer, and makes extensive use of the OBI syntax extension.

Alas, I'm not using any TEXMAP parts here. I do have other BOMs that have benefited from that extension, though.

http://www.brickoracle.com/Billund/Dino/7475-BOM.pdf

[Michael Heidemann]

Looks good. Please recall for me the OBI extensions.

[Philippe Hurbain]

Indeed, quite good! Dark red seems washed out, but then it matches the faded tone used by LEGO...

[Joshua Delahunty]

Looks good. Please recall for me the OBI extensions.

It's how you hard-code a color on a part, despite the color-16 being used. It's used to do the "original" or "old" building instructions format. With OBI, an area would normally be color-16, but with OBI enabled, it changes to whatever color is specified in the code (I've always used a special black, but we designed the syntax to be as flexible as possible, as we did with TEXMAP). All the black stud sides are done with this.

Here are a couple more BOMs, these use OBI and TEXMAP (they also have a bit more attention to layout and design -- I posted the 7475 slightly impulsively). The upper parts and heads are TEXMAP'd, the horses and shields are traditional LDRAW design-via-architecture from the library.

http://www.brickoracle.com/Billund/Slot/...screen.pdf
http://www.brickoracle.com/Billund/Slot/...screen.pdf

[Joshua Delahunty]

Indeed, quite good! Dark red seems washed out, but then it matches the faded tone used by LEGO...

This is deliberate. I use the "official" RGBs from TLG for the various colors. It is usually a close match for their printed product.



This is a better way to explain what the result of OBI is too. I think it's hard to miss the difference here ;-)

-- joshua

[Travis Cobbs]

A number of years ago, Joshua and I collaborated on LDView's support for his proposed OBI LDraw extension. However, to the best of my knowledge, it was never proposed to the standards committee, and LDView disables support for it by default. If you want to use it, you need to set LDView's OBI hidden setting to TRUE (either by -OBI=1 on the command line, or via the registry; see LDView's help file for general information about setting settings). And in order to actually see any OBI rendering, you of course need OBI-supporting parts and primitives (which Joshua created for his personal use, but as far as I know haven't been published anywhere).

I'd give you more details, but the while the OBI syntax was designed (by Joshua) to be as simple as possible, it still isn't trivial, and I don't remember it off-hand. I could in theory reverse engineer it by looking at LDView's source code, but it would take a lot of effort, and I'd probably miss something anyway.

[Joshua Delahunty]

A number of years ago, Joshua and I collaborated on LDView's support for his proposed OBI LDraw extension. However, to the best of my knowledge, it was never proposed to the standards committee, and LDView disables support for it by default. If you want to use it, you need to set LDView's OBI hidden setting to TRUE (either by -OBI=1 on the command line, or via the registry; see LDView's help file for general information about setting settings). And in order to actually see any OBI rendering, you of course need OBI-supporting parts and primitives (which Joshua created for his personal use, but as far as I know haven't been published anywhere).

I'd give you more details, but the while the OBI syntax was designed (by Joshua) to be as simple as possible, it still isn't trivial, and I don't remember it off-hand. I could in theory reverse engineer it by looking at LDView's source code, but it would take a lot of effort, and I'd probably miss something anyway.

OBI was originally designed and built in Foundry, a part-editing application built by a non-ALE friend (who also worked on the design of TEXMAP) [side note: Foundry was also instrumental in working with the LDD format and was part of the tool chain that got us the last shipments of LDD parts through LU]. I started to try to port OBI support to LDView myself, but the graphics cache was unfamiliar enough to me that I enlisted Travis's help. Travis helped us to add some nice features to OBI (features that, when implemented in TEXMAP caused some consternation from other LCAD implementers, if memory serves).

OBI is really quite simple. The most basic syntax is:

0 !OBI NEXT OBI_BLACK

which will color the next non-comment, non-blank LDRAW line (the entire file, if the next line is a type-1) in color "OBI_BLACK" when OBI is turned on in LDView. (OBI_BLACK would be a color name from LDCONFIG.LDR)

There are also
0 !OBI START OBI_BLACK
and
0 !OBI END
for wrapping a series of lines to be colored

There exists other support for setting named flags and only colored conditionally based on how they're set, but that's pretty advanced usage, mainly for primitives that are meant to be used in a general way (sometimes you need it black, sometimes you need the primitive without the black support).

We weren't sure there would be wide-spread enough interest in the syntax, plus I had an ex-committee member recommend against certification, so we never really pursued it.

[Steffen]

can't the same effect simply be achieved by using a specialized customized stud primitive
which has its cylinder colored black?

why all the effort of introducing a new keyword?

are other primitives than just stud.dat involved?

[Joshua Delahunty]

can't the same effect simply be achieved by using a specialized customized stud primitive
which has its cylinder colored black?

no.

Studs are used in various contexts. Forcing black will ruin some of those contexts, and of course you're now forcing everyone to use the look, whether they like it or not.

why all the effort of introducing a new keyword?

- Makes it optional
- doesn't force the use on anyone (even if using the files with OBI, viewers can turn the support off)
- enables the feature for anyone who is interested in it, to use it easily
- maintains complete backwards and forwards compatibility with all viewers.

in short, it's an exemplary use of a ! keyword.

Besides, it was done and tested years ago, with a modicum of effort. Now I might have to add 1 to 4 lines of "code" to some new primitive as I discover it.

are other primitives than just stud.dat involved?

Quite a few. Not just studs, but tubes.

[Steffen]

and of course you're now forcing everyone to use the look, whether they like it or not.

Uhm, no, I was thinking of an alternative stud file, functioning the same way like the "(Fast-Draw)" primitives.
I.e., both versions of the studs are available,
and an application can offer the user a choice which one to use.

Quite a few. Not just studs, but tubes.

Could you please be so kind and grep through your files to pass on a list of those here?
I'm not asking for this to further insist on my suggestion, just to better understand the scenario here.

[Joshua Delahunty]

and of course you're now forcing everyone to use the look, whether they like it or not.

Uhm, no, I was thinking of an alternative stud file, functioning the same way like the "(Fast-Draw)" primitives.
I.e., both versions of the studs are available,
and an application can offer the user a choice which one to use.

I didn't mean this to sound as harsh as it does when quoted. Please take this as "and of course I would want to avoid forcing everyone to use the look whether they like it or not".

I think I like !OBI support for applications better, since it changes how the files are parsed, rather than where the files are accessed, information isn't duplicated, and as primitives mature, the !OBI syntax stays in place and "inherits" that growth.

Quite a few. Not just studs, but tubes.

Could you please be so kind and grep through your files to pass on a list of those here?
I'm not asking for this to further insist on my suggestion, just to better understand the scenario here.

It's a lot worse than I thought it might be, possibly because when OBI was written, the use of primitives was less standardized.
There are 350 files with !OBI references between parts/ and parts/s in my LDRAWDIR.

In addition to those, the totals look like this:
./axlehol6.dat:2
./beamhole.dat:1
./confric.dat:7
./confric2.dat:9
./connect.dat:7
./connect2.dat:7
./connect4.dat:6
./connhole.dat:1
./peghole.dat:1
./steerend.dat:1
./stud.dat:1
./stud10.dat:3
./stud2.dat:2
./stud2a.dat:2
./stud4.dat:1
./stud4a.dat:1
./stud7.dat:2
./stud15.dat:3

My local 3895.dat has 11 uses (direct, not counting uses by primitives) of !OBI in it. I have no idea whether it's the very latest. Those 11 would be the bearing holes.

LCAD:

(Modern) TLG:


-- joshua

[Steffen]

I also sometimes would like to be able to create the "old building instructions" look.
So the general idea of making our library useable for that case is of course a good one.
However, I see the following points of the current solution which make me doubt
and which - to me - appear to require re-thinking it over:

It seems that tons of individual parts have to be edited to achieve the look.
I would much better like that just some primitives are swapped, and Bam!, you have the new look.

For example in the bar pictures you posted above, instead of 11 times patching an official file, just patching 1 time the affected primitive should be enough.

Offering an alternative set of primitives which give you that look would also avoid the necessity of having to introduce a syntax extension like 0 !OBI.

[Joshua Delahunty]

I also sometimes would like to be able to create the "old building instructions" look.
So the general idea of making our library useable for that case is of course a good one.
However, I see the following points of the current solution which make me doubt
and which - to me - appear to require re-thinking it over:

It seems that tons of individual parts have to be edited to achieve the look.
I would much better like that just some primitives are swapped, and Bam!, you have the new look.

For example in the bar pictures you posted above, instead of 11 times patching an official file, just patching 1 time the affected primitive should be enough.
Offering an alternative set of primitives which give you that look would also avoid the necessity of having to introduce a syntax extension like 0 !OBI.

You bring up some great points.  We did about 2 or 3 trial runs at different approaches before we concluded what the minimum necessary work would be to realize proper implementation.

Our greatest challenge (which probably doubled the work on implementation, and made implementation with LDVIEW non-trivial) was allowing OBI on opaque parts, while preventing it on transparent*.  At one point, we toyed with the idea of separate primitive sets for those two classes of parts.

We even attempted different parsing tools that would blanket-convert the .DAT library over to these kinds of targets.

In the end, not messing with the library as issued and allowing innocuous comments added to existing code was deemed the best approach (and, as I mentioned, the point of a 0 ! syntax extension).

I really appreciate your vigor, Steffan, but in the end I am not advocating that this (optional) syntax be adopted by the standards committee.  As I said earlier in the thread, I was advised by an ex-committee member to not even bother.  

If you wanted to continue to visit this, beware that the 11 commands in 3895.dat apply to uses of 4-4cyli.dat.  Weigh in your mind how -- on the one hand  -- shading 4-4cyli.dat might affect the family of parts in general, versus -- on the other -- how re-authoring all "TECHNIC bricks" to use a primitive in order to support this feature might work.

We put a lot of design time in to make it work. I guess you can only trust me when I tell you that we did our due diligence.

   -- joshua

* one could point out that in modern BI, the shading is applied equally to studs on both opaque and transparent parts, but this was not always true, and we strove for the most flexible approach to allow one to render at one whatever time period was desired (within the limits of practicality).

[Joshua Delahunty]

My local 3895.dat has 11 uses (direct, not counting uses by primitives) of !OBI in it.  I have no idea whether it's the very latest.  Those 11 would be the bearing holes.

LCAD:

(Modern) TLG:

For what it's worth, there WAS a newer version of 3895.dat, and it contained all the 4-4cyli references in a group, meaning the OBI commands necessary for this part were reduced from 11 uses of !OBI NEXT down to an !OBI START and !OBI END pair.

Also (since I can't post to the admin thread on this issue), I'd like to clarify that OBI_BLACK is *not* part of the OBI syntax.  It's the color name I chose to use to color all my black shading.  Calling the color OBI_BLACK makes it clear that I'm only using it in my library for OBI purposes, and to change it would mean a rather global change (also, that it should not be used as a convenient "hey I need a black, I'll pick this one" color for use).  Any OBI command can use any named color in LDCONFIG.LDR.  Mine just happens to contain a "pure black" color called OBI_BLACK that I use for all my OBI invocations.