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


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

[attachment=1320]

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



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