TEXMAP extension thoughts and findings.


TEXMAP extension thoughts and findings.
#1
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.



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

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)
   

Both having the -180 == 180 problem

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

Thoughts?
Reply
Re: TEXMAP extension thoughts and findings.
#2
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?
Reply
Re: TEXMAP extension thoughts and findings.
#3
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.
Reply
Re: TEXMAP extension thoughts and findings.
#6
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.
Reply
Re: TEXMAP extension thoughts and findings.
#4
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.
Reply
Re: TEXMAP extension thoughts and findings.
#5
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).
Reply
Re: TEXMAP extension thoughts and findings.
#7
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.)


Attached Files Thumbnail(s)
   

.png   f.png (Size: 1.02 KB / Downloads: 4)
.mpd   testcyl.mpd (Size: 1.75 KB / Downloads: 0)
Reply
Re: TEXMAP extension thoughts and findings.
#8
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: 4)

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
Reply
Re: TEXMAP extension thoughts and findings.
#9
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?
Reply
Re: TEXMAP extension thoughts and findings.
#13
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.)
Reply
Re: TEXMAP extension thoughts and findings.
#10
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?
Reply
Re: TEXMAP extension thoughts and findings.
#11
LDView doesn't support the cylindrical projection yet, it seems to crash as a result.
Reply
Re: TEXMAP extension thoughts and findings.
#12
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:
0 FILE main.ldr
0 unofficial part
0 0 BFC CERTIFY CCW

2 4  0 0 0  25 0 0
2 2  0 0 0  0 25 0
2 1  0 0 0  0 0 25



0 !TEXMAP START SPHERICAL -15 -45 0  -15 -45 -10   -10 -45 -10  360 180 checker.png
0 !: 1 15  -15 -45 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP FALLBACK
1 15  -15 -45 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP END

0 !TEXMAP START SPHERICAL 15 -45 0  15 -45 -10   20 -45 -10  180 360 checker.png
0 !: 1 15  15 -45 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP FALLBACK
1 15  15 -45 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP END



0 !TEXMAP START SPHERICAL -15 -15 0  -15 -15 -10   -10 -15 -10  270 90 checker.png
0 !: 1 1  -15 -15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP FALLBACK
1 1  -15 -15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP END

0 !TEXMAP START SPHERICAL 15 -15 0  15 -15 -10   20 -20 -10  90 270 checker.png
0 !: 1 2  15 -15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP FALLBACK
1 2  15 -15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP END



0 !TEXMAP START SPHERICAL -15 15 0  -15 10 -5   -5 10 -5  120 60 ldTexTest.png
0 !: 1 3  -15 15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP FALLBACK
1 3  -15 15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP END


0 !TEXMAP START SPHERICAL 15 15 0  15 15 -10   20 10 -10  360 180 checker.png
0 !: 1 4  15 15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP FALLBACK
1 4  15 15 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
0 !TEXMAP END



0 !TEXMAP START SPHERICAL 45 -15 0  45 -15 -10   50 -15 -10  360 180 checker.png
0 !: 1 5  45 -15 0  0.5 0 0  0 0.5 0  0 0 0.5 4588.dat
0 !TEXMAP FALLBACK
1 5  45 -15 0  0.5 0 0  0 0.5 0  0 0 0.5 4588.dat
0 !TEXMAP END


0 !TEXMAP NEXT PLANAR 60 0 0  80 0 0   60 20 0  ldTexTest.png
1 16 60 -45 0  1 0 0  0 1 0  0 0 1 test1.ldr


0 FILE test1.ldr
0 unofficial part
0 0 BFC CERTIFY CCW

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

0 !TEXMAP START SPHERICAL 0 0 0  0 0 -10   10 0 -10  360 180 checker.png
0 !: 1 4  -20 0 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat

0 !TEXMAP NEXT Cylindrical 0 10 0  0 0 0   0 10 -5  120 smile.png
0 !: 1 4  0 0 0  10 0 0  0 10 0  0 0 10 box4.dat

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

0 !TEXMAP FALLBACK
1 4  -20 0 0  10 0 0  0 10 0  0 0 10 48\8-8sphe.dat
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
0 !TEXMAP END
Reply
Re: TEXMAP extension thoughts and findings.
#14
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.
Reply
Re: TEXMAP extension thoughts and findings.
#15
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.
Reply
Re: TEXMAP extension thoughts and findings.
#16
http://en.wikipedia.org/wiki/Hairy_ball_theorem
Reply
Re: TEXMAP extension thoughts and findings.
#18
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.
Reply
Re: TEXMAP extension thoughts and findings.
#17
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.
Reply
Re: TEXMAP extension thoughts and findings.
#19
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?
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)