LDraw.org Discussion Forums

Full Version: Texture Standard
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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.

Quote: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...
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.
Ok, I was waiting to see what other were thinking of this but, seems we are all doing that Smile

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.
Roland Melkert Wrote: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.
Willy Tschager Wrote: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
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.
Any progress on this?

w.
What is holding this up?
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.
Sorry about the delay. I've now updated the spec with the changes mentioned.
Pages: 1 2