LDraw.org Discussion Forums

Full Version: 7475 BOM done with LDRAW tool support
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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
Looks good. Please recall for me the OBI extensions.
Indeed, quite good! Dark red seems washed out, but then it matches the faded tone used by LEGO...
[Image: 4209500.jpg][Image: 4243840.jpg]
Michael Heidemann Wrote: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
Philippe Hurbain Wrote:Indeed, quite good! Dark red seems washed out, but then it matches the faded tone used by LEGO...
[Image: 4209500.jpg][Image: 4243840.jpg]

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

[Image: 4209500.gif][Image: 4243840.gif]

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
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.
Travis Cobbs Wrote: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.
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?
Steffen Wrote: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.

Steffen Wrote: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.

Steffen Wrote:are other primitives than just stud.dat involved?

Quite a few. Not just studs, but tubes.
Joshua Wrote: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.

Joshua Wrote: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.
Pages: 1 2