Orion Pobursky Wrote:This is in reference to the LSC post
I would also like to discuss that post, though on a bit of a different tangent (Travis Cobbs suggested this was the right place to have some input on the subject).
BACKGROUND
Back in 2009, I worked with a friend who has a history of professional CAD/CAM development. He created a parser for the LDRAW format, using only the precise LDRAW specs as published on the site. He threw a quick-and-dirty GUI front end on it, and we named it "Foundry," the first step in what was to be (and still may be) a world-class part editor that would work with LDRAW compatible parts (there was some serious discussion of creating a higher-level curve-based or geometric-solids based language, and using the .DAT format as the tesselated output of "compiling" that language).
We then worked with Travis Cobbs to create the !OBI extension to LDRAW (which has yet to be submitted to the LSC). That extension allows for the "shading" of stud sides and tube hollows so that parts look as they did in Old Building Instructions (or Original Building Instructions, take your pick). Directives could be placed into code so that a compliant viewer can turn on or off the casting of defined surfaces to black to create this effect. We created a fairly feature-rich directive language, including START..END blocks, and single-line definition NEXT blocks. The effect would "dive into" sub-files as needed, and we had a method for setting and clearing macro values, so that the effect could be conditional inside a sub-file as defined "outside" that sub-file before the sub-file is "called" as if it were a sub-routine.
Foundry received the first OBI treatment, and then I patched in to LDView sources a fairly rich attempt to replicate that success. I had some issues identifying and conditionally disabling the feature with transparent parts* with his sources, so in the end Travis re-wrote the support from scratch and made it comform fully to that spec.
DESIGN BY ARCHITECTURE
Later, I wrote my first two design parts, the Exxon and trucker torsos. I found the "design by architecture" approach to be extrememely slow-going and error prone, and the fact that any design created could not be increased in resolution without a full re-design convinced me that it was time to make something happen with LDRAW texture mapping.
Our first attempt was to write an application that took a bitmap and tesselated it into triangles matching the image. Despite best efforts, and some interesting success, the numbers of triangles seemed prohibitive (source files would grow larger than bitmaps holding texture map textures would be, and they would ALWAYS load into the graphics pipeline, no shutting them off), plus we were still stuck without the ability to do gradients, which more and more decorated parts were featuring. We eventually abandoned this approach.
!TEXMAP DEVELOPMENT
So we developed the !TEXMAP syntax. I wrote the syntax, and my friend coded it into Foundry. We took an approach that would fit the existing LDRAW syntax, be more understandable to the typical layman than UV coordinate definitions, and felt we were off and running. Our first approach was to simply scan the image, slap it on a part, and call it a day. It was nearly INSTANTANEOUS designs on parts.
I asked Travis about running this work in front of the LSC, and also asked if he would add this feature to LDView as yet another unreleased standard. As I recall, it was proof that gradients did exactly what you'd expect that got him working to put the feature into LDView. On the former issue, though, he was reticent. He felt that non-support by MLCAD would be a huge blocker. In fact, nearly every one to a person asked me, upon seeing the results, "when can we get that in MLCAD?!"
The next step we took was to make sure that the FALLBACK syntax was designed and integrated, so that all existing work would continue to live on, and MLCAD compatible files could continue to be developed by those who did not want to upgrade.
I wrote texmap.txt, and furnished that to my friend. He turned it into texmap.doc, added the diagram of how planar mapping works, and added the end section on the Foundry Implementation (so Travis could base his approach on that of Foundry's).
So I had the overwhelming opinion of "that's tremendously cool, but it will never pass with most of the LDRAW population using MLCAD". Additionally I had another LDRAW author strongly advise me NOT to seek LSC approval, because it always resulted in delays. Much better to create something powerful and have people just use it. It was at this point that I dropped the idea of making !TEXMAP into an LSC standard, and set about changing people's minds one at a time...
A LIVING, DEVELOPED STANDARD
I've spent the next two years explaining how it works:
http://www.facebook.com/media/set/?set=a...4199f78c01
and expanding further and further the proof that it's worth the switch from MLCAD
http://www.facebook.com/media/set/?set=a...e2f35c7d88
(this was just the latest, I have a lot more)
Basically, this has been a de facto standard, living and in use, for the past two years. It has lived through many many "what if" and "how do we" scenarios to arrive at the syntax and workflow that were developed in that time.
so when Roland opines "you mean we can't change anything it's all or nothing?"
I have to say that
a) *I* did not submit this standard for consideration by the LSC, and
b) the standard has been developed and is operational, with two years of effort behind it
To take a standard that someone else developed, and then insist that the LSC should ratify that standard, but with certain features removed or modified because they don't "sound right" is, in the nicest terms possible, unfair and improper (and I don't mean this personally, Roland, I have great respect for your work, AND your view on software patents).
SUMMARY
On this topic, my position now is the same as it has been since the standard was written: it's out there to use. It's not official LDRAW syntax, and I have no desire to make it so. Support it if you like, or don't, but be aware that there are incompatibilities with official syntax (file names require quotes if you use spaces in them, for instance).
There are two viewers that support the syntax as designed now. Both fall just short of full compliance with the standard:
- LDView doesn't support quotation marks around the pngfile parameter and based on what he told me, GLOSSMAP would be supported as a texture file name if someone tried
- Neither actually supports GLOSSMAP operations (Travis didn't implement this at all, we were working on implementing lights in Foundry when we got bogged down with the weight of Yet Another Extension), and I'm pretty sure LDView doesn't treat it as a reserved word (see above)
- Neither supports CYLINDRICAL or SPHERICAL mapping (my friend told me it was a trivial addition, when the requirement would arise, for Foundry). LDView only treats CYLINDRICAL as a reserved word, not SPHERICAL (as I understand it)
I'd be most pleased to see expanded support of the standard. Yesterday, I ran into a need for CYLINDRICAL (else I'd probably have to match up two separate PLANAR mappings onto a curved surface -- NOT FUN), and my artist friend who has been working on textures for me has repeatedly asked for GLOSSMAP for all the shiny paints that appear on the minifigure series torsos now (see second link above for image of Kimono Girl, which SHOULD have shiny gold paint). He and I have also discussed the still-theoretical BUMPMAP support so we can do rubber in a pitted way like TLG does in their animations. CYLINDRICAL and GLOSSMAP are probably not very far off in the Foundry implementation, to be sure.
-- joshua
* a feature later found to be un-official, TLG *will* shade such parts. Oh, well.
EDIT: added footnote