Texture Mapping extension

[Joshua Delahunty]

…but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

I have been meaning to look at implementing this syntax for several years, but when Travis brought it up again, I was finally stimulated to get started. While writing a parser for this texture syntax, several questions have arisen. I would appreciate it if you could answer them:

1. You have mentioned your intention to extend this syntax. Where are such extensions going to happen? How are they going to be backwards-compatible with a parser which does not implement them?

We intend to implement CYLINDRICAL and GLOSSMAP fairly soon, SPHERICAL may or may not follow (mostly for completeness, but CYLINDRICAL was in some folk's eyes not needed until very recently).

There was talk for some time of a BUMPMAP extension, so that rubber textures could be done.

For the former, they are in the spec now, a program that didn't want to support them should implement the keywords in the parser, and issue an error (which I believe LDView does currently, though I may be wrong) unless and until it does support them.

For the latter, BUMPMAP may be at the same level as TEXMAP, so it would technically be a comment to any parser that didn't understand the keyword.

2. Suppose I have an image file named

Code:

"Evil" grin.png

What does the TEXMAP START line look like to reference that file?

0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 "\"Evil\" grin.png"

3. What is the result of the following code snippets?
(Please ignore any actual numbers; they are for demonstration purposes only.)
(Please treat each snippet as if it were contained in a separate file)

Code:

0 // Snippet 1
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
3 4 0 0 0 80 0 0 40 -40 0

First let me say that the "texture stack" was partially left over from our OBI work, where it was important to keep track of whether OBI was on or off repeatedly. In some ways, it "wasn't my area." But I'll proceed based on my understanding of the intended operation. I'd say that nesting these guys would just lead to confusion in most cases, and -- as you mentioned -- it's mostly about how these might work if you left something "open" as you went into a sub-file.

In this case, the quad would have image2.png applied, and the tri would have image.png applied (following the spec).

Code:

0 // Snippet 2
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 // comment
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0

The comment is ignored, the quad gets image.png applied.

Code:

0 // Snippet 3
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

quad -> image2.png
tri -> image.png

Code:

0 // Snippet 4
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0

quad -> image.png
tri -> image2.png

I'm going to guess that this MAY not work in the current impl of LDView.

Code:

0 // Snippet 5
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !TEXMAP END
0 !: 3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

According to the spec, this should result in a syntax error on the '4 !: ...' line.

Only 0 !: is an acceptable meta.

Code:

0 // Snippet 6
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 !: 0 4 4 0 -100 0 80 -100 0 80 -180 0 0 -180 0
0 !: 0 !: 0 !TEXMAP END
0 !: 0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

You'd have a syntax error here as well. Further, the nesting of :! is not supported in the spec. The point of :! is to allow legal geometry to be parsed by a TEXMAP-compliant parser while that same geometry is ignored by older parsers.

something like

Code:

0 !TEXMAP START PLANAR  1 1 1  2 2 2  3 3 3  image.png
0 !TEXMAP_GEOMETRY 4 16 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP_GEOMETRY 3 16 0 0 0 80 0 0  80 -80 0
0 !TEXMAP FALLBACK
4 16  0 0 0  80 0 0  80 -80 0  0 -80 0 0 80 0
3 16  0 0 0  80 0 0  80 -80 0  0 -80 0
0 !TEXMAP END

was determined to be too unwieldy, so we reduced those lines to a constant (and thin) vertical border to make them more readable:

Code:

0 !TEXMAP START PLANAR  1 1 1  2 2 2  3 3 3  image.png
0 !: 4 16 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 3 16 0 0 0 80 0 0  80 -80 0
0 !TEXMAP FALLBACK
4 16  0 0 0  80 0 0  80 -80 0  0 -80 0 0 80 0
3 16  0 0 0  80 0 0  80 -80 0  0 -80 0
0 !TEXMAP END

To a non-TEXMAP application, the above would still apply the existing design (made of quads and tris and so on).

Code:

0 // Snippet 7
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 STEP
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END

Good question. My guess, by spec, would be to act as if the 0 STEP was before the 0 !TEXMAP, and the quad would have image.png applied. The intent of the current spec is that START..END and NEXT always apply to non-comment lines. I'm not sure what the corner cases are for other valid comment-commands or metas. Travis might be able to answer that one better than I.

-- joshua