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

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.

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

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:
[Image: 389521.gif]
(Modern) TLG:
[Image: 389521.jpg]

-- joshua
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.
Steffen Wrote: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).
(2013-12-07, 19:57)Joshua Delahunty Wrote: [ -> ]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:
[Image: 389521.gif]
(Modern) TLG:
[Image: 389521.jpg]

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