TEXMAP extension thoughts and findings.

TEXMAP extension thoughts and findings. - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: TEXMAP extension thoughts and findings. (/thread-13633.html)

TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-07

I've been working on the cylindrical implementation and I noticed some minor confusing things about the current TEXMAP spec.

The planar projection uses top/left orientation while the cylindrical one uses center bottom. This isn't a real big problem but the text states the v coordinate should be based on the distance to the base plane. This will cause the picture to be up side down.

So unless I misunderstood something (else) I think it should be the distance to the cylinder top plane.

Using that correction this:

Code:
Cyl texmap test minifig head

UNOFFICIAL PART

BFC CERTIFY CCW

16 0 0 0 1 0 0 0 1 0 0 0 1 s\3626bs02.dat

16 0 4 0 13 0 0 0 13 0 0 0 -13 1-8cyli.dat

16 0 4 0 -13 0 0 0 13 0 0 0 -13 1-8cyli.dat

16 0 4 0 13 0 0 0 13 0 0 0 13 2-4cyli.dat

16 0 4 0 0 0 8 0 -6.4 0 8 0 0 t04o6250.dat

16 0 4 0 -8 0 0 0 -6.4 0 0 0 8 t04o6250.dat

16 0 17 0 0 0 -8 0 6.4 0 8 0 0 t04o6250.dat

16 0 17 0 8 0 0 0 6.4 0 0 0 8 t04o6250.dat

16 0 4 0 0 0 -8 0 -6.4 0 -8 0 0 t04o6250.dat

16 0 4 0 8 0 0 0 -6.4 0 0 0 -8 t04o6250.dat

16 0 17 0 0 0 8 0 6.4 0 -8 0 0 t04o6250.dat

16 0 17 0 -8 0 0 0 6.4 0 0 0 -8 t04o6250.dat

!TEXMAP START CYLINDRICAL 0 17 0  0 4 0   0 17 -13 90 smile.png

!: 1 16 0 17 0  13 0 0  0 -13 0  0 0 -13  s\minifighead-hlp.dat

!TEXMAP FALLBACK

16 0 17 0  13 0 0  0 -13 0  0 0 -13  s\minifighead-hlp.dat

!TEXMAP END

will render like:

If people agree, we need to correct the spec text.

Second the spec doesn't mention what to do with over scan and or fully enclosed objects.

For example (using Nils' checker png Smile

Code:
!TEXMAP START CYLINDRICAL 0 0 0  0 -200 0   0 0 -200   180 checker.png

!: 1 15  0 -200 0  200 0 0  0 200 0  0 0 -200 4-4cyli.dat

!TEXMAP FALLBACK

15  0 -200 0  200 0 0  0 200 0  0 0 -200 4-4cyli.dat

!TEXMAP END

gives (over scan):

and

Code:
!TEXMAP START CYLINDRICAL 0 0 0  0 -200 0   0 0 -200   360 checker.png

!: 1 15  0 -200 0  200 0 0  0 200 0  0 0 -200 4-4cyli.dat

!TEXMAP FALLBACK

15  0 -200 0  200 0 0  0 200 0  0 0 -200 4-4cyli.dat

!TEXMAP END

gives (enclosed)

Both having the -180 == 180 problem

But again i'm not claiming my implementation is currently 100% correct.

Thoughts?

Re: TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-08

I think I solved the -180==180 problem for 99.9% of the time.

I still think the spec should mention what's expected in that situation though.

I also implemented spherical projection:

It uses even more 'hacks' to get rid of the polar problem, although it's still not perfect I think.

Also IMHO these kind of projections are NOT possible when you apply the current spec to the letter. Because the way the spec describes calculating the uv values will result in very weird things when using angles of >=180 degrees.

Personally I think the vertical one should be limited to <=180 in order to prevent weird situations. And secondly the vertical plane as described in the spec should rotate along with the current horizontal angle when calculating v

Or maybe we need multiple kinds of spherical modes. Namely the literal spec one, and two more variations focusing on ether horizontal of vertical dominance my above implementation being the horizontal one.

Thoughts?

Re: TEXMAP extension thoughts and findings. - Benjamin Moody - 2014-08-11

You're right. The spec is indeed self-contradictory regarding the orientation of cylindrical textures. My intuition was the opposite of yours; it seems more parsimonious that the first control point should correspond to "V=0" for both planar and cylindrical. But either way would be fine, we just need to pick one and amend the spec to make it clear.

Furthermore, the spec doesn't say in which direction the arctangents are computed (i.e., does the image appear in its natural orientation as viewed from the outside of the cylinder, or from the inside?) The obvious answer, to me, is that if
- the combined transformation matrix for the file in which the TEXMAP statement occurs has positive determinant;
- the value of "a" is positive; and
- we are viewing the cylinder from the outside;
then the image should appear in its natural orientation. If zero or two of the above conditions are satisfied, the image should appear flipped. However, the spec doesn't say so.

The spec is even less clear about spherical textures, as it doesn't say whether the third control point corresponds to the "left" or the "right" side of the texture. In my implementation I've been (somewhat arbitrarily) assuming that it goes on the right.

Re: TEXMAP extension thoughts and findings. - Benjamin Moody - 2014-08-11

Regarding "overscan", by which I guess you mean what happens to polygons, or parts of polygons, that fall outside the boundaries of the texture: You're right, although I didn't realize it, that the spec doesn't say what to do about that either.

It seemed obvious to me that the texture should be treated as having an infinitely large border with an alpha value of zero (i.e, areas outside the image bounds should simply show the normal part color.) This could be implemented in OpenGL, for example, using GL_CLAMP_TO_BORDER mode (by setting the border color to the part color); or using GL_CLAMP_TO_EDGE (by adding an extra row and column of pixels on each side); or using the old yucky GL_CLAMP (by doing both).

But you're right, the spec doesn't say that.

I do see that, if the texture is expected to fully cover all of the polygons between TEXMAP START and TEXMAP END, that there would be some practical advantages to extending the perimeter of the image indefinitely (i.e., something like GL_CLAMP_TO_EDGE *without* any padding, which is what it looks like you're doing.)

Note that trying to correctly implement any of these, with the exception of GL_CLAMP_TO_BORDER, makes mipmap generation a real pain. (Imagine a large part with a tiny sticker on it. The areas outside the sticker must be completely unaffected by the colors of the texture interior, regardless of which mipmap is used.)

On the subject of the TEXMAP spec, another serious issue is the definition of gloss maps: "It should be a single channel image where the value indicates the amount of specularity to add at the part of the texture map (RG and B are currently ignored – but reserved – in gloss maps, and the A (alpha) channel determines the amount of gloss at a given texel)."

The first part implies that it should be a type 0 PNG file (grayscale with no alpha channel) and that the significant channel is, well, the only one ("value", i.e. luminance.) The second part contradicts that - technically speaking, there is no such thing as a single-channel PNG with an alpha channel! - and frankly, it makes less sense (why require the image file to include 1 or 3 useless extra channels?) Not to mention that it doesn't do any good to say those channels are "reserved" if you don't tell part authors what value to put there.

Re: TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-11

Benjamin Moody Wrote:Regarding "overscan", by which I guess you mean what happens to polygons, or parts of polygons, that fall outside the boundaries of the texture

Yes, although I admit overscan probably isn't the best name for it. Travis wrote in the big LDPartEditor thread part authors should prevent (or minimize) the effect by just not supplying geometry inside a texmap block that shouldn't be texture mapped. So in my above example the cylinder should be divided in two one part inside the texmap block and one outside it.

I agree that's that the best way to go but again it should be mentioned. I also like your GL_CLAMP_TO_BORDER suggestion, such behavior would be nice for the outer triangles of the mapped geometry. But then again the part author could easily force the same behavior by adding some alpha 0 padding to the texture when isolating/splitting the geometry is a problem. I'm using GL_CLAMP by the way Smile

but I also limit uv to 0..1 so it basically repeats the outer pixels for the out of bound region.

This brings me to another point having the hard 0..1 cut of (as suggested in the spec) robs us from using repeating pasterns, something that could be very useful when scaling/deforming texture mapped primitives (e.g. a texture mapped rope)

Benjamin Moody Wrote:On the subject of the TEXMAP spec, another serious issue is the definition of gloss maps

I currently chose to ignore the gloss map option as I was unsure of it's use thinking material properties should be handled by the color number exclusively unless it act's like a mask (which I suspect it is intended to do).

Re: TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-11

Benjamin Moody Wrote:Furthermore, the spec doesn't say in which direction the arctangents are computed (i.e., does the image appear in its natural orientation as viewed from the outside of the cylinder, or from the inside?)

I assumed, as the result of the LDraw orientation of up=-y, textures should use top/left orientation for uv at the level texmap is at.

Benjamin Moody Wrote:The spec is even less clear about spherical textures, as it doesn't say whether the third control point corresponds to the "left" or the "right" side of the texture. In my implementation I've been (somewhat arbitrarily) assuming that it goes on the right.

I too used right, thinking the p1,p2,p3 triangle is to be used CCW when calculating the sphere up vector.

Re: TEXMAP extension thoughts and findings. - Benjamin Moody - 2014-08-13

From my perspective, one of the great things about the TEXMAP extension is that it allows users - who may or may not be experienced part authors - to create custom stickers / printed parts without modifying the underlying part geometry. (Indeed, one of my current projects is creating a graphical interface for doing just that.) So, if we assume users can decide to stick any arbitrary PNG file to any arbitrary part, the results of doing so ought to be well-defined. Smile

Plus, it just makes sense that if you're only decorating a small area of a large polygon, you shouldn't have to create a gigantic, mostly-transparent PNG file in order to represent that small area with sufficient detail. And you shouldn't have to, say, replace a cylinder primitive with a bunch of quads solely because you want part of the cylinder to be textured and part untextured.

Your point about rope textures is an interesting one; in some cases it may be helpful to have textures that automatically repeat. But I feel like that is more of a "material" property that would be better expressed through COLOUR extensions, rather than a semantic property to be encoded as part of the part/model file.

As far as texture orientations go, maybe I wasn't clear. We have two possible definitions for the V coordinate, depending on whether we treat the first or the second control point as the origin. There are also two possible definitions for the U coordinate (if we are looking in the positive V direction, does increasing U correspond to clockwise or counterclockwise movement?) Probably it should be defined in a way that places the texture in its natural orientation on the cylinder exterior (meaning it'd be reversed on the cylinder interior), but the important thing is that it should be defined by the spec.

For the sake of a concrete example, here is a test model showing a few different cases for cylindrical texturing, and the resulting rendered image (not sure how to post an image inline, but I'll attach it as well.)

Re: TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-13

Your example sure uses some 'weird' situations, I'm not sure all of those are correct usage of the texmap meta though. but I see how you would want the results it gives in your overview png (except textures being up-side-down in relation to the LDraw orientation).

After some tweaks to my implementation this is how it looks for me:

.png

test.png (Size: 45.29 KB / Downloads: 181)

It suffers greatly from the 'wrap around problem', as I only solved that for polygons having only one point exactly on the seam thinking it should be up to the part authors to prevent those problems.

But I agree it would be nice to be able to just throw the projection against anything (although not whole parts), so I'll try to resolve that problem this weekend using GL_REPEAT for the U coordinates when the cyl angle is 360 degrees.

Second problem I'm having is with the skewed reference, it goes wrong because I do all normal/texture calculations on top level after the part is flattened. The skew however does not influence the transformations of the texmap parameters when they are converted to top level. But then I'm not even sure skewing is used at all in the part library.

Anyhow, thanks for your little test scenario. And there I thought my implementation was done Smile

Re: TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-14

Ok I managed to fix the wrap around problem.

But how did you get the cube back to render like that? It's using both the start and end of the map while being interrupted on a single polygon. As far I know that shouldn't be possible unless you are using custom (per pixel) shaders. Bus as I'm, at the moment, stuck with fixed pipeline I don't know of any way of doing that unless I'm missing something.

Remains the reference problem, although I'm wondering if it's worth the effort.

One thing is clear the spec (text) needs attention, any of the other LSC members reading this?

Re: TEXMAP extension thoughts and findings. - Magnus Forsberg - 2014-08-14

Is there something wrong with the file "testcyl.mpd"?
If I try to open it in LDView, it causes LDView to crash.

How should I save the files?

Re: TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-14

LDView doesn't support the cylindrical projection yet, it seems to crash as a result.

Re: TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-16

these are the final results of the LDCad implementation of the TEXMAP meta

There are still some limitations which should be addressed in ether the spec or part authoring rules I think, namely:

Cylindrical vertical orientation (text needs to ether make the top dominant or flip the v distance calculation).
Spherical p3 position (right seems logical though)
Spherical >180 degree problems. I fixed it by using the longitude and latitude approach, although this is not what the spec describes but without it usage will be fairly limited I think.
Spherical polar problems. Some can be fixed but there will still be some mesh/param combinations resulting in problems (e.g. the second bottom sphere). Solution seems to be to force the underlying mesh to have a point at each polar.
Skewing can potentially mess with transformations when only applied to the base p1..p3 data. (I decided to leave it be until some part needs it)

Again I really think we need to address these issues in combination with the spec before texture mapped parts find their way into the official library.

dat src:

Code:
FILE main.ldr

unofficial part

0 BFC CERTIFY CCW

4  0 0 0  25 0 0

2  0 0 0  0 25 0

1  0 0 0  0 0 25

!TEXMAP START SPHERICAL -15 -45 0  -15 -45 -10   -10 -45 -10  360 180 checker.png

!: 1 15  -15 -45 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP FALLBACK

15  -15 -45 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP END

!TEXMAP START SPHERICAL 15 -45 0  15 -45 -10   20 -45 -10  180 360 checker.png

!: 1 15  15 -45 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP FALLBACK

15  15 -45 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP END

!TEXMAP START SPHERICAL -15 -15 0  -15 -15 -10   -10 -15 -10  270 90 checker.png

!: 1 1  -15 -15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP FALLBACK

1  -15 -15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP END

!TEXMAP START SPHERICAL 15 -15 0  15 -15 -10   20 -20 -10  90 270 checker.png

!: 1 2  15 -15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP FALLBACK

2  15 -15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP END

!TEXMAP START SPHERICAL -15 15 0  -15 10 -5   -5 10 -5  120 60 ldTexTest.png

!: 1 3  -15 15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP FALLBACK

3  -15 15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP END

!TEXMAP START SPHERICAL 15 15 0  15 15 -10   20 10 -10  360 180 checker.png

!: 1 4  15 15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP FALLBACK

4  15 15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP END

!TEXMAP START SPHERICAL 45 -15 0  45 -15 -10   50 -15 -10  360 180 checker.png

!: 1 5  45 -15 0  0.5 0 0  0 0.5 0  0 0 0.5 4588.dat

!TEXMAP FALLBACK

5  45 -15 0  0.5 0 0  0 0.5 0  0 0 0.5 4588.dat

!TEXMAP END

!TEXMAP NEXT PLANAR 60 0 0  80 0 0   60 20 0  ldTexTest.png

16 60 -45 0  1 0 0  0 1 0  0 0 1 test1.ldr

FILE test1.ldr

unofficial part

0 BFC CERTIFY CCW

14  -10 30 5  30 30 5  30 70 5  -10 70 5

!TEXMAP START SPHERICAL 0 0 0  0 0 -10   10 0 -10  360 180 checker.png

!: 1 4  -20 0 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP NEXT Cylindrical 0 10 0  0 0 0   0 10 -5  120 smile.png

!: 1 4  0 0 0  10 0 0  0 10 0  0 0 10 box4.dat

!: 1 4  20 0 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP FALLBACK

4  -20 0 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

4  0 0 0  10 0 0  0 10 0  0 0 10 box4.dat

4  20 0 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

!TEXMAP END

Re: TEXMAP extension thoughts and findings. - Benjamin Moody - 2014-08-16

For |a| < 360 my implementation simply pads the texture out (with alpha = 0) to the equivalent of 360 degrees. For |a| < 180 this isn't necessary since you can just use clamping mode, but I haven't made that optimization yet. Wink

(Of course, as you note, a pixel shader would also work... or for that matter you could also make it work in GL 1.3 using multitexturing.)

The thing about matrices and coordinate spaces is, I think, an important point. Basically, the point is that a subfile inclusion matrix transforms the *entire* subfile - so it should transform textures too. Otherwise we end up in a situation where mirroring a part causes it to appear "correct" in texture-mapping renderers, but mirrored in renderers that use the fallback geometry. (Yes, of course people should try to avoid mirroring parts, but that's not to say it doesn't happen.) As for scaling/skewing, even if we ignore the possibility of users doing that deliberately, note that any nontrivial rotation also creates some slight scaling/skewing because the coordinates can't be expressed with perfect precision.

A cheap way to deal with it, correctly handling mirroring but not skewing, would be to check if the determinant is negative, and if so flip the "a" coordinates (for cylindrical) or the "b" coordinates (for spherical.)

Re: TEXMAP extension thoughts and findings. - Benjamin Moody - 2014-08-16

Longitude + latitude is not a good solution because I don't think there's any way to make the poles seamless while using linearly interpolated texture coordinates. You could try including a mirrored copy of the texture above the pole, but you'd then end up with two very different "shortest paths" between any two points near the pole.

I thought that the intention of the TEXMAP spec was to fix this by allowing normal mod-1 wrapping in both directions. However, now that I'm thinking about it I don't see how to define the projection past the 90-degree point without it becoming discontinuous.

One option, certainly, would be to use a cube map. But there's no intuitively obvious way to make a cube map out of a single PNG file, and those aren't as easy to implement or as universally supported as linear textures.

Re: TEXMAP extension thoughts and findings. - Benjamin Moody - 2014-08-17

As I've thought about this more I've realized that I'm being silly. There is no way to map a sphere to a single linear texture without some discontinuities. But a renderer that cares about getting it right can easily take the provided image, in whatever format it appears, and convert it into a cube map or whatever is convenient.

That said, it would be preferable to use a projection that allows for linear texturing with only *one* discontinuity - texture creators can then arrange to place that discontinuity somewhere that's unlikely to cause problems.

Re: TEXMAP extension thoughts and findings. - Steffen - 2014-08-20

http://en.wikipedia.org/wiki/Hairy_ball_theorem

Re: TEXMAP extension thoughts and findings. - Roland Melkert - 2014-08-21

I was kinda assuming part authors will prevent the 'weird' situations in official parts, so I'm not worried about that.

But it might be a problem when you want to use it for user level stickers like you wrote earlier.

Re: TEXMAP extension thoughts and findings. - Benjamin Moody - 2014-08-22

Quite. Only it's worse than that; ideally we would want a mapping that allows coordinates to be interpolated *linearly*, which is possible for at most half the sphere if your texture is infinitely large.

But if you're willing to live with a bit of distortion you could have a mapping that's at least continuous everywhere except at one point, which I can imagine being useful (and seems to have been the intention behind the current texmap spec.)

Another thought that occurs to me is that if the texture were initially represented as a cube map, it wouldn't be too difficult to convert that on the fly into 6 partially-overlapping planar textures that older rendering hardware / APIs could cope with (thus giving proper interpolation and nearly seamless results so long as the polygons are fairly small - you could even be smart and generate textures that are exactly as large as you need.) This would in fact be a lot easier than converting a cube map to or from some polar-coordinate-based projection. I can see, though, it'd be annoying to deal with the idiosyncracies of cube map coordinates (whichever way we chose to define them) and I can't think of any particularly elegant way to express a cube map in an LDraw extension.

Re: TEXMAP extension thoughts and findings. - Benjamin Moody - 2014-08-22

When designing a texture for an arbitrary part, what's more likely? That you'll find at least one point on the part where the texture will tolerate some distortion and discontinuity, or that you'll find two antipodal points like that?

And if your part does have two "poles", you may well be able to use a cylindrical texture instead. If spherical textures are to be a useful option, shouldn't they provide some functionality that isn't offered by the other types?

RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2014-08-07, 23:27)Roland Melkert Wrote: I've been working on the cylindrical implementation and I noticed some minor confusing things about the current TEXMAP spec.

The planar projection uses top/left orientation while the cylindrical one uses center bottom. This isn't a real big problem but the text states the v coordinate should be based on the distance to the base plane. This will cause the picture to be up side down.

So unless I misunderstood something (else) I think it should be the distance to the cylinder top plane.

Using that correction this:

Code:
0 Cyl texmap test minifig head 0 UNOFFICIAL PART 0 BFC CERTIFY CCW 1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\3626bs02.dat 1 16 0 4 0 13 0 0 0 13 0 0 0 -13 1-8cyli.dat 1 16 0 4 0 -13 0 0 0 13 0 0 0 -13 1-8cyli.dat 1 16 0 4 0 13 0 0 0 13 0 0 0 13 2-4cyli.dat 1 16 0 4 0 0 0 8 0 -6.4 0 8 0 0 t04o6250.dat 1 16 0 4 0 -8 0 0 0 -6.4 0 0 0 8 t04o6250.dat 1 16 0 17 0 0 0 -8 0 6.4 0 8 0 0 t04o6250.dat 1 16 0 17 0 8 0 0 0 6.4 0 0 0 8 t04o6250.dat 1 16 0 4 0 0 0 -8 0 -6.4 0 -8 0 0 t04o6250.dat 1 16 0 4 0 8 0 0 0 -6.4 0 0 0 -8 t04o6250.dat 1 16 0 17 0 0 0 8 0 6.4 0 -8 0 0 t04o6250.dat 1 16 0 17 0 -8 0 0 0 6.4 0 0 0 -8 t04o6250.dat 0 !TEXMAP START CYLINDRICAL 0 17 0 0 4 0 0 17 -13 90 smile.png 0 !: 1 16 0 17 0 13 0 0 0 -13 0 0 0 -13 s\minifighead-hlp.dat 0 !TEXMAP FALLBACK 1 16 0 17 0 13 0 0 0 -13 0 0 0 -13 s\minifighead-hlp.dat 0 !TEXMAP END

will render like:

If people agree, we need to correct the spec text.

If I'm understanding correctly, the spec would not change from a user perspective, only the technical discussion talking about how the u-v are calculated? The user specifies the base "center" of the wrapped texture around the cylinder, and the renderer will correct for the fact that this doesn't line up with expectations for PLANAR, or are you saying the user should specify P3 as the top middle point of the texture application?

--------

BTW, I think it's interesting the way you're using FALLBACK above. FALLBACK was intended to allow "dual-use" decorated parts. The existing geometric designs (we called this Design By Architecture) would go in the FALLBACK section, and the new, often-less-complicated geometry would appear in 0 !: lines. The intent being that TEXMAP parts could be issued in the wild that would not break existing implementations (such as MLCAD).
Following the spec, your last example should work just as well with the less-work-intensive:
...
0 !TEXMAP START CYLINDRICAL 0 17 0 0 4 0 0 17 -13 90 smile.png
1 16 0 17 0 13 0 0 0 -13 0 0 0 -13 s\minifighead-hlp.dat
0 !TEXMAP END

That would continue to work in older renderers, while the new ones would actually texture something there. There should be no requirement to specify the same geometry inside a FALLBACK section.

______

I'm also a HUGE fan of the fact that you double-space between triplets. We do this in all of our experiments, Foundry actually outputs LDR files in that format. It makes things SO much easier to follow. If I had my way (ha), it would be a required standard of LDRAW official files. Alas... Smile

-- joshua

RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2014-08-11, 18:48)Roland Melkert Wrote:
Benjamin Moody Wrote:On the subject of the TEXMAP spec, another serious issue is the definition of gloss maps

I currently chose to ignore the gloss map option as I was unsure of it's use thinking material properties should be handled by the color number exclusively unless it act's like a mask (which I suspect it is intended to do).

GLOSSMAP is there to allow for reflective ink to render as it does on the actual part.

Take for example this Rock Raiders Torso:

973pag.jpg

The torso has a combination of elements, some of which are opaque (all the black edge lines), some of which might be semi-transparent (not a lot on this torso, I don't think), some of which has a texture that is semi-reflective (most of his vest, though the photo doesn't show this really well), and some of which have a definite solid reflection (the silver ink on the wrench and undershirt). The GLOSSMAP would be used to indicate texels that should render with high reflectivity, so that the wrench and other aspects would "sparkle" or "shine" when changing the perspective of either the light source or the view point. If the alpha channel (transparency channel in modern Photoshop) were viewed, it would look like a solid wrench shape, solid undershirt shape, with random speckle over the surface of the vest, for the various points that light should reflect.

As to Benjamin's issue about the RGB being reserved, I believe those should all be set to 0, so the image would appear black in background color, but appear masked (when viewed, for example as a PNG with the alpha channel in effect) to just the alpha values that dictated the gloss. Had someone implemented them as all FF, we could have dealt with it (all white).

One bit of thinking was that one or more of those channels might later be used for a bump map definition or some other effect(s). But we were already attempting to build an extension bridge with the GLOSSMAP definition (unproven, just theoretical), so we didn't define those for use 5 years ago, we only reserved them. We didn't want those three "extra" channels to go to waste, and have to keep glomming on new PNGs with each new feature.

-- joshua

RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-12

(2018-01-12, 18:31)Joshua Delahunty Wrote: If I'm understanding correctly, the spec would not change from a user perspective, only the technical discussion talking about how the u-v are calculated? The user specifies the base "center" of the wrapped texture around the cylinder, and the renderer will correct for the fact that this doesn't line up with expectations for PLANAR, or are you saying the user should specify P3 as the top middle point of the texture application?

I'm ok ether way, just wanted to bring this oddity/ambiguity to light as support for cylindrical textured parts is still very limited so changing something now won't break much.

(2018-01-12, 18:31)Joshua Delahunty Wrote: BTW, I think it's interesting the way you're using FALLBACK above. FALLBACK was intended to allow "dual-use" decorated parts. The existing geometric designs (we called this Design By Architecture) would go in the FALLBACK section, and the new, often-less-complicated geometry would appear in 0 !: lines. The intent being that TEXMAP parts could be issued in the wild that would not break existing implementations (such as MLCAD).
Following the spec, your last example should work just as well with the less-work-intensive:

Makes sense, I'll have to check my implementation.

edit: seems to be ok in LDCad 1.6a

(2018-01-12, 18:31)Joshua Delahunty Wrote: I'm also a HUGE fan of the fact that you double-space between triplets. We do this in all of our experiments, Foundry actually outputs LDR files in that format. It makes things SO much easier to follow. If I had my way (ha), it would be a required standard of LDRAW official files.

Edit: forgot to response to this, I can go even 'weirder' if you like Smile

Code:
16   0 0  3.712    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-3-4.dat

16   0 0  1.237    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-1-4.dat

16   0 0  1.237   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-1-4.dat

16   0 0 -1.237    1.2374 0  1.2374   0 1 0   -1.2374 0  1.2374   ldcConRing-1-4.dat

16   0 0 -1.237   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-1-4.dat

16   0 0 -3.712   -1.2374 0 -1.2374   0 1 0    1.2374 0 -1.2374   ldcConRing-3-4.dat

RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2018-01-12, 21:39)Roland Melkert Wrote:
(2018-01-12, 18:31)Joshua Delahunty Wrote: If I'm understanding correctly, the spec would not change from a user perspective, only the technical discussion talking about how the u-v are calculated? The user specifies the base "center" of the wrapped texture around the cylinder, and the renderer will correct for the fact that this doesn't line up with expectations for PLANAR, or are you saying the user should specify P3 as the top middle point of the texture application?
I'm ok ether way, just wanted to bring this oddity/ambiguity to light as support for cylindrical textured parts is still very limited so changing something now won't break much.

What have you set-up in LDCad at this point? I recently reported a TEXMAP issue to Leonardo Zide about LeoCAD and as part of that conversation he reminded me that he's ready to implement CYLINDRICAL and SPHERICAL (he was one of the first to do PLANAR) as soon as I gave him info from the spec -- and he has been for years Undecided

.

Believe it or not, making the relationship of P1-P2-P3 so different from that of PLANAR was purposeful. I had to remember back 8 years as to why we tried to go that way, and as I recall it, we wanted a strong differentiation from how the points worked in a planar example (all points basically "on" the texture) to how they worked in CYLINDRICAL (two off-texture, and the third at a midpoint rather than a corner).

That said, while I objected to changes to the spec because of a large volume of work I'd done defining PLANAR TEXMAP parts between 2009 and adoption of the standard, since both Benjamin and yourself found it counter-intuitive, I'd be willing to have this change to CYLINDRICAL opened up and potentially changed. Unfortunately, the spec specifically forbids change without ratification of the LSC, which could make it tough.

Again, how does LDCad work currently? I'll ask Leo to mirror that work, and if the only two working examples are out of spec, at least they will be consistent.
------
Side notes:

Yes, 'a' was meant to be expressed in degrees.

CYLINDRICAL was designed specifically because PLANAR textures would start to shear/warp at the edges if one textured the "entire" face of the mini-figure; and it was expected to help solve that particular issue. SPHERICAL came along for completeness. The implementation details, PLANAR, CYLINDRICAL and SPHERICAL were all based on OpenGL source examples from "the literature" (I've yet been able to go back and find them, unfortunately), and were intended to therefore be pretty straightforward. I regret the angst SPHERICAL has caused you guys in your attempts to implement.

CYLINDRICAL as conceived was always presumed to max out at a=180, since we'd not seen a texture that wrapped an entire cylinder at the time. If I were to use CYLINDRICAL on a mini-figure double-inked head, I would use two separate textures -- I do that now with PLANAR. I suppose by extension, SPHERICAL was never meant to go over a hemisphere either.

Everything about TEXMAP was meant to make it easier for end-user participation and experimentation without having to understand 3D concepts to a super high degree (this is also why we focused on PLANAR so heavily). If the user created a TEXMAP source rectangle that ran past the extents of the geometry, that was acceptable. If smaller, yeah, infinite outer transparency was expected -- the idea was if the heavy lifting had been skipped at the PNG generation stage, it could be "tweaked" in the texturing stage.

We figured that after two separate renderers had been able to implement the standard without too much headache, then it would be easy to forward to other renderers. I didn't get a blow-by-blow from Leonardo about how hard LeoCAD was, but he made it seem really simple: I asked, he implemented.

(2018-01-12, 18:31)Joshua Delahunty Wrote: BTW, I think it's interesting the way you're using FALLBACK above. FALLBACK was intended to allow "dual-use" decorated parts. The existing geometric designs (we called this Design By Architecture) would go in the FALLBACK section, and the new, often-less-complicated geometry would appear in 0 !: lines. The intent being that TEXMAP parts could be issued in the wild that would not break existing implementations (such as MLCAD).
Following the spec, your last example should work just as well with the less-work-intensive:

Quote:
Quote:Makes sense, I'll have to check my implementation.

Again, it was meant to keep things really easy. If a part never had DBA designs in it, it shouldn't have nor need FALLBACK or cryptic 0 !: lines

I think I saw you putting in GLOSSMAP in some examples as well; that's meant to be an optional parameter. if it's absent, no problem, if it's present, then the PNG file should follow else it's an error.

Finally, attached is my hand-drawn diagram of what I recall (from memory and reading the spec) CYLINDRICAL to be. Did you place P3 where it shows, or at the other end of the black line (in the colored version)?

[img]file://Users/jdelahunty/Downloads/cylindrical.jpg[/img]

RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2018-01-12, 21:39)Roland Melkert Wrote:
(2018-01-12, 18:31)Joshua Delahunty Wrote: I'm also a HUGE fan of the fact that you double-space between triplets. We do this in all of our experiments, Foundry actually outputs LDR files in that format. It makes things SO much easier to follow. If I had my way (ha), it would be a required standard of LDRAW official files.

Edit: forgot to response to this, I can go even 'weirder' if you like :

Code:
1 16 0 0 3.712 1.2374 0 1.2374 0 1 0 -1.2374 0 1.2374 ldcConRing-3-4.dat 1 16 0 0 1.237 1.2374 0 1.2374 0 1 0 -1.2374 0 1.2374 ldcConRing-1-4.dat 1 16 0 0 1.237 -1.2374 0 -1.2374 0 1 0 1.2374 0 -1.2374 ldcConRing-1-4.dat 1 16 0 0 -1.237 1.2374 0 1.2374 0 1 0 -1.2374 0 1.2374 ldcConRing-1-4.dat 1 16 0 0 -1.237 -1.2374 0 -1.2374 0 1 0 1.2374 0 -1.2374 ldcConRing-1-4.dat 1 16 0 0 -3.712 -1.2374 0 -1.2374 0 1 0 1.2374 0 -1.2374 ldcConRing-3-4.dat

Nothing weird to me about this. If I could go back in time, I'd suggest to James that he use it (though I've always been more the numbers guy than another parts guy). I think it's that important, and I've OFTEN done this with the signs on numbers, when the files all relate to one another.

RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-12

(2014-08-14, 20:42)Roland Melkert Wrote: LDView doesn't support the cylindrical projection yet, it seems to crash as a result.

BTW, I tried CYLINDRICAL in a recent build of LDView (I was hoping Travis had finally gotten to it), and while it didn't work, the part didn't crash LDView either.

FWIW.

RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-13

(2018-01-12, 23:00)Joshua Delahunty Wrote: Again, how does LDCad work currently? I'll ask Leo to mirror that work, and if the only two working examples are out of spec, at least they will be consistent.

I've checked the sourcecode as it has been along time since I touched that part of the code, and it seems I'm using p3 at the same level as p1. But revisiting this now makes me want to change that (I'm about to release 1.6b anyway) to follow the spec and just invert the texcoord distance instead.

Current source of interest:

Code:
TLDCylindricalTextureInfo::TLDCylindricalTextureInfo(TGL2DTexture *tex, const TGLVector3d &p1, const TGLVector3d &p2, const TGLVector3d &p3, const double angle) :

  inherited(tex),

  topCen(p1), botCen(p2), nor(p1-p2), restDir(p3-p1),

  angle(deg2Rad(angle)), angleIs360(angle>=360.0 || angle<=-360.0) {

  nor.normalize(len);

  restDir.normalize();

};

void TLDCylindricalTextureInfo::calcUV(TGLVector3f **pnts, const int pntCnt, TGLVector2f *uv) {

  //Alles via vec3d tbv rounding errors

  TGLVector3d baseDir(false), curDir(false), pnt(false);

  double baseAngle(0.0), curAngle;

  for (int i=0; i<pntCnt; i++)

  {

    pnt.init(*pnts[i]);

    TGLVector2f &tc=uv[i];

    pnt.calcDirectionTo(botCen, nor, curDir);

    curDir.inverse(); //moet van midden naar buiten net als restDir

    curAngle=nor.calcSignedAngleBetween(curDir, i==0 ? restDir : baseDir);

    if (i==0)

    {

      baseDir=curDir;

      baseAngle=curAngle;

    }

    else

      curAngle+=baseAngle;

    tc.u=0.5+curAngle/angle;

    tc.v=distanceToPlane(pnt, nor, topCen, nor)/len; //afst tot top

  }

};

edit: A change isn't a big deal imho as officially the cyl/sph implementations in LDCad are still 'experimental'

RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-14

(2018-01-13, 18:14)Roland Melkert Wrote:
(2018-01-12, 23:00)Joshua Delahunty Wrote: Again, how does LDCad work currently? I'll ask Leo to mirror that work, and if the only two working examples are out of spec, at least they will be consistent.
I've checked the sourcecode as it has been along time since I touched that part of the code, and it seems I'm using p3 at the same level as p1. But revisiting this now makes me want to change that (I'm about to release 1.6b anyway) to follow the spec and just invert the texcoord distance instead.

Current source of interest:

Code:
TLDCylindricalTextureInfo::TLDCylindricalTextureInfo(TGL2DTexture *tex, const TGLVector3d &p1, const TGLVector3d &p2, const TGLVector3d &p3, const double angle) : inherited(tex), topCen(p1), botCen(p2), nor(p1-p2), restDir(p3-p1), angle(deg2Rad(angle)), angleIs360(angle>=360.0 || angle<=-360.0) { nor.normalize(len); restDir.normalize(); }; void TLDCylindricalTextureInfo::calcUV(TGLVector3f **pnts, const int pntCnt, TGLVector2f *uv) { //Alles via vec3d tbv rounding errors TGLVector3d baseDir(false), curDir(false), pnt(false); double baseAngle(0.0), curAngle; for (int i=0; i<pntCnt; i++) { pnt.init(*pnts[i]); TGLVector2f &tc=uv[i]; pnt.calcDirectionTo(botCen, nor, curDir); curDir.inverse(); //moet van midden naar buiten net als restDir curAngle=nor.calcSignedAngleBetween(curDir, i==0 ? restDir : baseDir); if (i==0) { baseDir=curDir; baseAngle=curAngle; } else curAngle+=baseAngle; tc.u=0.5+curAngle/angle; tc.v=distanceToPlane(pnt, nor, topCen, nor)/len; //afst tot top } };

edit: A change isn't a big deal imho as officially the cyl/sph implementations in LDCad are still 'experimental'

I attempted to test CYLINDRICAL with LDCad last night, and either got no image (P3 even with P1) or a scrambled one (P3 even with P2). It was very strange.

In other news, my buddy changed Foundry last night to render textures correctly on transparent geometry, something that none of the platforms currently does right (including Foundry, as the reference platform). LeoCAD is close, he's using a shader to get the desired effect.

(The issue is, nearly every renderer will render the texture transparently when applied to transparent geometry, when the alpha of the texture and the alpha of geometry need to combine, with opaque alpha on the texture overriding any alpha of the underlying part. Both GL_DECAL and GL_REPLACE give the wrong results). I presumed we'd HAVE to go to a shader solution (something I don't really mind because it was always presumed to be needed for proper GLOSSMAP support), but Foundry is apparently doing a double render manuever to get the desired results.

RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-14

(2018-01-14, 0:52)Joshua Delahunty Wrote: I attempted to test CYLINDRICAL with LDCad last night, and either got no image (P3 even with P1) or a scrambled one (P3 even with P2). It was very strange.

Seems to work fine for me (in 1.6a):

.png

cyl.png (Size: 72.75 KB / Downloads: 132)

Using

Code:
Cyl texmap test

UNOFFICIAL PART

BFC CERTIFY CCW

16 0 0 0 1 0 0 0 1 0 0 0 1 s\3626bs02.dat

16 0 4 0 13 0 0 0 13 0 0 0 -13 1-8cyli.dat

16 0 4 0 -13 0 0 0 13 0 0 0 -13 1-8cyli.dat

16 0 4 0 13 0 0 0 13 0 0 0 13 2-4cyli.dat

16 0 4 0 0 0 8 0 -6.4 0 8 0 0 t04o6250.dat

16 0 4 0 -8 0 0 0 -6.4 0 0 0 8 t04o6250.dat

16 0 17 0 0 0 -8 0 6.4 0 8 0 0 t04o6250.dat

16 0 17 0 8 0 0 0 6.4 0 0 0 8 t04o6250.dat

16 0 4 0 0 0 -8 0 -6.4 0 -8 0 0 t04o6250.dat

16 0 4 0 8 0 0 0 -6.4 0 0 0 -8 t04o6250.dat

16 0 17 0 0 0 8 0 6.4 0 -8 0 0 t04o6250.dat

16 0 17 0 -8 0 0 0 6.4 0 0 0 -8 t04o6250.dat

!TEXMAP START CYLINDRICAL 0 4 0  0 17 0   0 4 -13  90 smile.png

16  0 4 0  -9.1923 0 9.1923  0 13 0  -9.1923 0 -9.1923  1-4cyli.dat

!TEXMAP END

and

Code:
Cyl texmap test 2

UNOFFICIAL PART

BFC CERTIFY CCW

!TEXMAP START CYLINDRICAL 0 4 0  0 17 0   0 4 -13  90 smile.png

16  0 0 0  1 0 0  0 1 0  0 0 1 3062a.dat

!TEXMAP END

As you see it uses P3 at the top, I will change this for 1.6b unless anyone thinks bot planer and cylindrical should use top for uniformity ?

(2018-01-14, 0:52)Joshua Delahunty Wrote: In other news, my buddy changed Foundry last night to render textures correctly on transparent geometry, something that none of the platforms currently does right (including Foundry, as the reference platform). LeoCAD is close, he's using a shader to get the desired effect.

(The issue is, nearly every renderer will render the texture transparently when applied to transparent geometry, when the alpha of the texture and the alpha of geometry need to combine, with opaque alpha on the texture overriding any alpha of the underlying part. Both GL_DECAL and GL_REPLACE give the wrong results). I presumed we'd HAVE to go to a shader solution (something I don't really mind because it was always presumed to be needed for proper GLOSSMAP support), but Foundry is apparently doing a double render manuever to get the desired results.

Transparent is very problematici ndeed (especially since LDCad 1.x uses fixed piped line), it also has to do with draw order on top of the normal trans draw order issues.

2.0 uses >= GL 3.0 so custom shaders for everything will have to revisit the problem when the time comes.

RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-14

(2018-01-14, 20:46)Roland Melkert Wrote:
(2018-01-14, 0:52)Joshua Delahunty Wrote: I attempted to test CYLINDRICAL with LDCad last night, and either got no image (P3 even with P1) or a scrambled one (P3 even with P2). It was very strange.

Seems to work fine for me (in 1.6a):

<snip>

Do you have smile.png available for download on the web?

Roland Melkert> As you see it uses P3 at the top, I will change this for 1.6b unless anyone thinks bot planer and cylindrical should use top for uniformity ?

[I admit my point following is of a semantic nature only]

I would argue the top would be for *intuitiveness* (rather than uniformity), since the triangle formed by CYLINDRICAL is orthogonal to the triangle defined for PLANAR (and my original reasoning was, put P3 at the base so that the part designer could try to remember that the triangle for PLANAR was wider at top than at bottom, and the plane of the triangle faces the viewer, whereas the CYLINDRICAL had the wider part at the bottom, and was "viewed" edge-on (also in PLANAR P3 defines an endpoint, while in CYLINDRICAL it defines a midpoint). I was specifically thinking that making them as different as possible in all ways was better than having things in common.

I'm not arguing it should not change (as intuitiveness is obviously subjective), I am saying that I don't personally feel that P3 at "top" is uniform with how PLANAR is defined. I'd be happy with P3 in either location, and if more people (so far, 2 to my 1) felt it makes more sense in the top position, that's far more important than my initial intention (putting it at the bottom).

(2018-01-14, 0:52)Joshua Delahunty Wrote: In other news, my buddy changed Foundry last night to render textures correctly on transparent geometry, something that none of the platforms currently does right (including Foundry, as the reference platform). LeoCAD is close, he's using a shader to get the desired effect.

(The issue is, nearly every renderer will render the texture transparently when applied to transparent geometry, when the alpha of the texture and the alpha of geometry need to combine, with opaque alpha on the texture overriding any alpha of the underlying part. Both GL_DECAL and GL_REPLACE give the wrong results). I presumed we'd HAVE to go to a shader solution (something I don't really mind because it was always presumed to be needed for proper GLOSSMAP support), but Foundry is apparently doing a double render manuever to get the desired results.
> Transparent is very problematici ndeed (especially since LDCad 1.x uses fixed piped line), it also has to do with draw order on top of the normal trans draw order issues.

That sounds like some of the issues Travis is facing with LDView.

> 2.0 uses >= GL 3.0 so custom shaders for everything will have to revisit the problem when the time comes.

I look forward to a really good textured, bump-mapped rubber eventually... ;-)

-- joshua

RE: TEXMAP extension thoughts and findings. - Michael Horvath - 2018-01-15

Does MLCad support texmaps? I'm guessing not.

RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-15

(2018-01-15, 20:10)Michael Horvath Wrote: Does MLCad support texmaps? I'm guessing not.

No, as far I know MLCad is not actively maintained anymore. Adding texture mapping to it would probably be a big job as it uses software only rendering.

RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-15

(2018-01-14, 22:51)Joshua Delahunty Wrote: I would argue the top would be for *intuitiveness* (rather than uniformity), since the triangle formed by CYLINDRICAL is orthogonal to the triangle defined for PLANAR (and my original reasoning was, put P3 at the base so that the part designer could try to remember that the triangle for PLANAR was wider at top than at bottom, and the plane of the triangle faces the viewer, whereas the CYLINDRICAL had the wider part at the bottom, and was "viewed" edge-on (also in PLANAR P3 defines an endpoint, while in CYLINDRICAL it defines a midpoint). I was specifically thinking that making them as different as possible in all ways was better than having things in common.

I'm not arguing it should not change (as intuitiveness is obviously subjective), I am saying that I don't personally feel that P3 at "top" is uniform with how PLANAR is defined. I'd be happy with P3 in either location, and if more people (so far, 2 to my 1) felt it makes more sense in the top position, that's far more important than my initial intention (putting it at the bottom).

Actually I'm thinking to support both as p3 is really only needed to determine the base direction (or facing direction).

You can calculate that direction using p3 at any place by using it to find the perpendicular vector to the p1 p2 direction.

RE: TEXMAP extension thoughts and findings. - Joshua Delahunty - 2018-01-16

(2018-01-15, 20:41)Roland Melkert Wrote:
(2018-01-15, 20:10)Michael Horvath Wrote: Does MLCad support texmaps? I'm guessing not.

No, as far I know MLCad is not actively maintained anymore. Adding texture mapping to it would probably be a big job as it uses software only rendering.

The fact that MLCad does not (and likely will not) support texture mapping is specifically why the FALLBACK syntax was developed and built for TEXMAP, so that existing tools would continue to work as they have with parts (and decorations of both types could be provided for use by MLCad users). It complicated the syntax and support a great deal, but backwards compatibility was very important to us as we designed TEXMAP.

RE: TEXMAP extension thoughts and findings. - Roland Melkert - 2018-01-17

(2018-01-15, 20:45)Roland Melkert Wrote: Actually I'm thinking to support both as p3 is really only needed to determine the base direction (or facing direction).

You can calculate that direction using p3 at any place by using it to find the perpendicular vector to the p1 p2 direction.

I've implemented this and it works fine, so the whole p3 point location is basically up to the part author imho.

.png

cyl.png (Size: 71.37 KB / Downloads: 85)

at the bottom (left in img)

Code:
!TEXMAP START CYLINDRICAL 0 4 0  0 17 0   0 17 -13  90 smile.png

16  0 0 0  1 0 0  0 1 0  0 0 1 3062a.dat

!TEXMAP END

at some random place (center in img)

Code:
!TEXMAP START CYLINDRICAL 0 4 0  0 17 0   0 12 -13  90 smile.png

16  0 0 0  1 0 0  0 1 0  0 0 1 3062a.dat

!TEXMAP END

at the top (right in img)

Code:
!TEXMAP START CYLINDRICAL 0 4 0  0 17 0   0 4 -13  90 smile.png

16  0 0 0  1 0 0  0 1 0  0 0 1 3062a.dat

!TEXMAP END