Texture Standard

[Orion Pobursky]

LSC,

The SteerCo has voted to allow the Texture Standard to become official. While the SteerCo has the authority to approve this outright we feel that, since you guys are the caretakers of the file format, we would like you to formally approve it. Here is a proposed motion for you to discuss, modify, and approve.

Proposal:

The current Texture Mapping extension is hereby adopted as a standard with the following extra rules:

* The standard will be adopted in its current version. Future changes to the standard will be reviewed and approved by the LDraw Standards Committee (LSC) before the changes become official.
* The LSC will formulate how this standard is implemented in the Official LDraw Library. Possible implementation issues to be considered include allowed graphics file format, resolution, storage, naming conventions, fallback detail, etc...

[Travis Cobbs]

I put the corrected full spec here. Barring errors that I missed, this is the spec that Joshua and I used during LDView's and Foundry's implementation for the PLANAR projection method, along with the syntax and parameters that will be needed for CYLINDRICAL and SPHERICAL projection methods.

[Roland Melkert]

Ok, I was waiting to see what other were thinking of this but, seems we are all doing that

I'm, ok with the above text, but personally I would have preferred keeping the Texture standard out the official one cause of the (sort of) proprietary nature of it.

Instead (like I noted somewhere before) I would have liked it to be a 'information only' support on LDraw.org. this would still (imho) make it possible to use it in the official library (using above mentioned additional formatting rules which we can mandate).

This because I don't see the benefits of adding a standard we can't change.

Don't get me wrong I'm ok with a standard which is managed outside the LSC, but I just don't see the need to make it look like it's managed by LDraw.org. Providing info alone would indicate it's supported by LDraw. You could see it as a third party managed plugin or something.

Just my thoughts.

[Willy Tschager]

Instead (like I noted somewhere before) I would have liked it to be a 'information only' support on LDraw.org. this would still (imho) make it possible to use it in the official library (using above mentioned additional formatting rules which we can mandate).

This has been discussed in the SteerCo. The point is, we cannot allow specs in official parts we do not OWN in some way. It's a bit like BFC and the other de facto standards we have adopted in the past. The only difference here is that there is currently no part in at the PT using this. To make this happen we went for adoption rather than endorsement.

As for the "standard managed outside the LSC" I think we made it very clear that future changes to this proposal have to be approved by the LSC, as well as all restrictions for official parts.

As it stands now the only think to do is adding the images for CYLINDRICAL and SPHERICAL projection methods and copy'n'paste the whole thing to the specs.

w.

[Allen Smith]

As it stands now the only think to do is adding the images for CYLINDRICAL and SPHERICAL projection methods and copy'n'paste the whole thing to the specs.

I wish that were the case, but I do not belive that it is.

There are substantial problems with the current definition of TEXMAP NEXT. Please refer to the list of code snippets here and Joshua's response here.

All of those snippets were derived from contradictory information in the specification which must be rectified in order to produce a parser. Unfortunately, the "correct" behavior Joshua specified makes the situation even murkier. Metas are ignored in some cases but not in others. NEXT can even capture geometry outside the scope of an enclosing texture, meaning nested NEXTs do not necessarily nest in their behavior (that is, they need not form a stack). This is very bad.

Also, textures absolutely should not be able to cross a STEP. Attempting to rearrange the location of the STEP as Joshua suggested is also not viable. The scoping needs to be clarified that textures automatically end at STEP, FILE, or NOFILE.

Regretfully, it is simply not possible for me to implement the specified promiscuous behavior of NEXT without throwing away my entire parser and UI. The good news is that my issues with NEXT are very much edge cases. The bad news is that defining a viable NEXT is quite difficult. Imagine a future meta command:
0 !MULTI-LINE-META-THAT-DRAWS-STUFF
0 // <drawing commands>
0 !MULTI-LINE-META-THAT-DRAWS-STUFF END

(not really all that weird, since we're in the midst of discussing one exactly like that.)

Suppose you now want to put a MULTI-LINE-META-THAT-DRAWS-STUFF into a TEXMAP NEXT. How many lines of scope does the NEXT have?

Alas, you can't answer the question in the same way across a parser which is aware of MULTI-LINE-META-THAT-DRAWS-STUFF and one that isn't.

Travis has suggested solving this problem by making it an error (or a no-op) for any NEXT to be followed by a linetype 0. This would solve the problem, but strikes me as being rather inelegant. I personally think it would be better to completely discard NEXT. It saves a whopping one line of LDraw code, but trades it for a complicated definition and implementation.

* * * *

On a much more minor note:

The fact that nesting !: is illegal must be clarified, as nesting is a logical consequence of the wording of the current specification.

The fact that filenames containing double quotes must be escaped with a backslash needs to be added to the spec. The corollary that \ as a path separator must be escaped as \\ also needs to be added.

* * * *

Hopefully these issues can be addressed, as I am very excited about the prospect of finally getting a texture standard formalized and implemented.

Allen

[Travis Cobbs]

Joshua agreed to the following restriction (not in the spec) for !TEXMAP NEXT (summarized by Allen):

!TEXMAP NEXT is intended purely as a shortcut. As such, it does not need to be a general-purpose command able to handle all possible situations. Consequently, it can be restricted to only be valid when the very next non-blank line is either a geometry line or a 0 !: line wrapper for a geometry line. (Geometry line means line type 1-5.) Anything else is an error, and must use START/END.

I agree that this isn't the best, but I don't find it as bad as Allen does.

I agree that we need to add the other two items to the spec that Allen mentioned. Since I'm currently hosting the file, I can do that, or someone else can copy the HTML code into the LSC Scratch Pad page on ldraw.org and do it.

[Willy Tschager]

Any progress on this?

w.

[Chris Dee]

What is holding this up?

[Travis Cobbs]

Sorry, my bad. I'll update the spec with the changes mentioned above and then post back here. I'll try to get this done either tonight or some time this weekend.

[Travis Cobbs]

Sorry about the delay. I've now updated the spec with the changes mentioned.

[Willy Tschager]

Guys, have your say. What's about the missing pics?

w.

[Roland Melkert]

I'm confused..

If the texture spec isn't maintained by the lsc, why do we need to discuss changes for it?

Wouldn't that be better off in a public thread so everybody can participate. In the end we only need to vote about taking the whole thing into the official spec or not (although the steerco already decided on that).

imho I consider this spec as 'non' LSC at the moment (Respecting Joshua's whishes).

[Willy Tschager]

If the texture spec isn't maintained by the lsc, why do we need to discuss changes for it?

Cos' apparently there were severe concerns about some flaws which had to be ironed out first.

Wouldn't that be better off in a public thread so everybody can participate. In the end we only need to vote about taking the whole thing into the official spec or not (although the steerco already decided on that).

No. We just do some cosmetics (the missing pics.) before moving the whole thing to the specs.

imho I consider this spec as 'non' LSC at the moment (Respecting Joshua's whishes).

Please read: http://forums.ldraw.org/showthread.php?t...86#pid5086

Believe me I'm really unhappy how the whole thing has to be handled. Point is, if we want textures in LDraw parts without starting from scratch there is this way or the highway. Feel free to come up with your own proposal for texture - with the cavit that we have the freedom to turn it up-side-down ;-)

w.

[Willy Tschager]

Added:

Language Extension for Texture Mapping

and updated:

LDraw.org Standards Committee Summary

w.