LDraw.org Discussion Forums
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)

Pages: 1 2 3 4


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:
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:

[attachment=1308]

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:
0 !TEXMAP START CYLINDRICAL 0 0 0  0 -200 0   0 0 -200   180 checker.png
0 !: 1 15  0 -200 0  200 0 0  0 200 0  0 0 -200 4-4cyli.dat
0 !TEXMAP FALLBACK
1 15  0 -200 0  200 0 0  0 200 0  0 0 -200 4-4cyli.dat
0 !TEXMAP END

gives (over scan):
[attachment=1309]

and
Code:
0 !TEXMAP START CYLINDRICAL 0 0 0  0 -200 0   0 0 -200   360 checker.png
0 !: 1 15  0 -200 0  200 0 0  0 200 0  0 0 -200 4-4cyli.dat
0 !TEXMAP FALLBACK
1 15  0 -200 0  200 0 0  0 200 0  0 0 -200 4-4cyli.dat
0 !TEXMAP END

gives (enclosed)
[attachment=1310]

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.

[attachment=1312]

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

I also implemented spherical projection:

[attachment=1311]

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:

[attachment=1318]

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.

[attachment=1319]

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?