LSC: Define TEXMAP resolution and naming conventions

[Allen Smith]

Willy has requested that the LSC define official rules for naming conventions for textures in the Part Tracker, and resolution limits or any other technical details.

I have no real opinions on the subject, except this:

I would really like to see the Part Tracker solicit vector, or Photoshop, sources for any images people submit. These would not necessarily be distributed with the official library, but would be readily available for those wishing to modify the texture in the future. Having the art source files—especially in the case of vectors—makes future refinement infinitely easier. For example, imagine in another 15 years of LDraw history that computers have significantly more oomph, and can handle higher-resolution bitmaps. If you have the vector source, you just rescale.

Allen

[Travis Cobbs]

I agree that having the vector sources (when available) be published along with the PNG would be very useful. I might go so far as to allow an obvious vector-based PNG with no Vector source artwork to qualify for hold, but I'm not sure about that.

I'm certainly open to suggestions, but I feel that the following restrictions should be in place:

1. Image dimensions are a power of 2 (e.g. 256, 512, etc.). Note: image doesn't have to be square, but both dimensions must be a power of 2.
   
2. Maximum image dimension is 2048.
   

Given 1 and 2 as requirements, 1 should probably just list all powers of 2 from 1 through 2048, since there are only 12.

The reasons for both restrictions are technical. Not having them adds significant extra work for programs to properly support TEXMAP, and while they make the job slightly harder for authors, I don't feel they make it all that much harder. (Note: properly in the previous sentence is important. The main difficulty for number 1 is that non-power-of-two textures are an extension, and having a working fallback is difficult. For number 1, as far as I know, 2048 is the maximum textur dimension supported by a lot of graphics cards, and turning a bigger texture into tiles take a lot of work to do properly.)

[Orion Pobursky]

A few thoughts:

• Require an openly defined vector format (e.g. SVG) as the base image. Then the texture can be derived from that automagically by the PT (or some other method)
  
• Filename restrictions should be the same as for parts
  
• Naming convention suggestion: <part number>tex.<whatever img format we decide on>
  
• Maybe create a new directory in PARTS? TEX?
  
• Fallbacks should be just as good as the current non-tex patterns. Yes this adds overhead for authors but I think it's vital in the beginning.
  
• At least initially, a tex should not be required for a patterned part to become official
  

[Roland Melkert]

I agree with a size max (not sure on the amount though), but the power of two thing can be a major pain, it could cause stretching (in order to get to the dimension limits). Also the power of two limit is only an issue on old (OpenGL) implementations, and even then there is an (relatively) easy workaround.

[Allen Smith]

• Maybe create a new directory in PARTS? TEX?
  

Uh-oh. The approved standard specifies a search path:

Additionally, a search for the specified texture file will first be attempted after adding a "textures/" prefix to the filename and following the standard LDraw search path. If no file is found, the search will be repeated without the "textures/" prefix.

I interpreted that to mean textures were stored in LDraw/textures. But now that I look at it again, it actually seems to be saying they are stored both in LDraw/parts/textures and LDraw/p/textures. The latter doesn't really make a lot of sense to me, but that seems to be what it says. Could someone please clarify this?

No matter what the answer is, I would rather see that re-written to make it more obvious.

Allen

[Travis Cobbs]

The intent was that they would go into <LDraw>/parts/textures. They definitely are not intended to go into <LDraw>/textures. The reasoning here is that the textures are directly connected to the parts, just like sub-parts are (which are in parts/s).

[Travis Cobbs]

• Require an openly defined vector format (e.g. SVG) as the base image. Then the texture can be derived from that automagically by the PT (or some other method)
  

This disallows using cleaned up scans as textures. I think that at the very least, "needs work" parts should be allowed to use cleaned up scans as their textures.

• Naming convention suggestion: <part number>tex.<whatever img format we decide on>
  

Since they will be in a textures directory, I don't think "tex" (or any variant) should be part of the filename. Some parts will require multiple textures though, so we definitely want the naming requirements to take that into account.

• Maybe create a new directory in PARTS? TEX?
  

I definitely feel that all part textures should be required to be in the parts/textures sub-directory (with maybe parts/s/textures being allowed, but maybe not; I'm not sure about that).

• Fallbacks should be just as good as the current non-tex patterns. Yes this adds overhead for authors but I think it's vital in the beginning.
  

As long as this is clearly indicated as a short-term stop-gap measure, I'm OK with this. Having this stick around long-term negates probably 75% of the point of textures.

• At least initially, a tex should not be required for a patterned part to become official
  

I don't think textures should ever be required for patterns. Some simple patterns are just better as geometry, and I think they always will be.

[Roland Melkert]

Thing I understood/assumed is that textures always go in a subfolder along side of the file using it's location, no matter if it's the library or some user location.

This way same named parts or variants of parts still use the correct textures due to normal search order. So after a file has been found any textures in it will be loaded from "<ldraw File Location>/textures". If they are not there no further searching will be tried (since that has been done in order to find the ldr/dat already).

All this goes recursively of course, so a referenced s\bla.dat will use textures from that file's location + "\s\textures".

[Roland Melkert]

Ok after rereading the above spec snippet and some background info I've gotten from Alex Taylor by email, I think it's supposed to be like so:

any file referring to a texture, should load that texture by looking at:

absFileLocation +"/textures"
normal ldraw search order locations +"/textures"
absFileLocation
normal ldraw search order locations

[Travis Cobbs]

That is correct. Sorry for the confusion. The idea is that "textures/" is automatically prepended to the filename, and then a search is made for the file using exactly the same rules as for normal linetype 1 files. If that fails to produce a result, the search is repeated without the "textures/" prefix.

[Allen Smith]

Is it hard to rescale a non power-of-2 image? I have to agree with Roland that trying to impose this limitation on the library files would be a headache.

I automatically rescale them in my implementation.

Allen

[Roland Melkert]

I automatically rescale them in my implementation.Allen

Yes it's quite trivial on modern hardware, but when needed (e.g OpenGL 1.1) I pad them to the nearest power dimensions and use non 1.0 u v coordinates to compensate.