#686 Textures resized on export (or is it import?)

[W. Vann Hall]

As described in this thread, texture images included in models exported to Lightwave format are often resized. Images may be upscaled or downscaled, or images may be increased in one dimension and decreased in the other; for instance, in a recently exported object, a texture image originally 400 x 400 was increased to 512 x 512, while one originally 1300 x 400 was resized to 1024 x 512. (As best I can tell, image dimensions < 384 are resized to 128; dimensions >= 384 and <= 712 are resized to 512, and dimensions > 712 are resized to 1024 -- but I may very well be incorrect about the algorithm being used, as I've not yet identified where in the source this resizing takes place.)

The image quality may suffer during either up- or downscaling: Upscaling images often produces jaggies, while downscaled images may lose content detail.

I'm not sure whether this resizing takes place during object import or export, as to date I've only tested with object textures originally imported with objects. (My next test will be to import an object, apply a texture to it within SH3D with a dimension > 1024, export the resulting object, and determine if the exported texture image has been resized.) However, I am starting to suspect the resizing occurs on importation, as objects imported into the Furniture Library Editor and saved in an .SH3F file also include resized textures.

Procedure to test:

1. Import an object into SH3D that includes a texture image with a dimension > 1024.
2. Export object in Lightwave (OBJ/MTL) format.
3. Examine exported texture image.

Workaround:

Uncertain. If resizing only occurs on export, and the user has access to the original texture image files, then the resized images can be replaced by appropriately named copies of the originals. (Note: Since SH3D exports all textures as .PNG files, if the original image is in a format other than PNG, the .MTL file must be edited to include the correct file extention in the applicable 'Kd' definition.)

This process can also be used to correct textures incorrectly resized by the Furniture Library editor, either by directly editing the .SH3F file using a Zip utility or by unzipping the .SH3F file, making changes as needed within the unzipped library, and recompressing the library. (In either case, one may need to change the library's extension from .SH3F to .ZIP before editing and back to .SH3F afterwards.)

If resizing occurs on import, the only potential workaround would be to import the object, modify its materials, and replace the resized textures with one imported directly into SH3D. (Note: In the case of textures intended to be used one-up at 100% -- for instance, a texture used to 'paint' a logo onto a nameplate, or one representing a gauge, control panel, or video display -- this requires the user know the intended size at which the texture will be shown; otherwise, the texture will either be truncated or repeated [tiled] on the object's surface.) At the moment, it's uncertain whether objects textured using this process are exported with correctly sized texture images.

[W. Vann Hall]

OK, so my first take on the rules for scaling was wrong: a 1600 x 900 test image was rescaled to 2048 x 1024 on export. I'm also finding discernible, but only barely discernible, differences on side-by-side renders of objects using original and resized textures. (However, the problem that initially started me looking -- the resizing of a 400 x 400 image of black text on a yellow background to 512 x 512, which introduced significant jaggies -- was readily apparent in renders, so it doesn't appear I can simply ignore the resize in all cases. However, as yet another potential workaround, I'm experimenting with manually resizing the images to a multiple of 512 along each dimension.)

[W. Vann Hall]

Further testing reveals that overwriting a downscaled texture in an imported object with the original, larger texture in SH3D seemingly does replace the smaller texture with the larger one. However, upon export to OBJ, the applied texture is resized.

1. Imported DAE object with texture of 1300 x 731.
2. Exported object as OBJ; texture is downscaled to 1024 x 512.
3. Imported OBJ, including downsized texture.
4. Using the 'Materials' option in the 'Modify Furniture' screen, replaced texture with comparable image at 1600 x 900.
5. 1. Exported object with overridden texture image; exported texture resized to 2048 x 1024.

[W. Vann Hall]

After additional research, it appears this may be a hold-over from an older version of Java3D, which required texture images to have dimensions that were each a power of 2. Evidently this requirement was dropped as of version 1.5 of the library, but the model loaders may still incorporate the older algorithm. While in most cases the texture degradation that results from image resizing is minor, under some conditions it is noticeable. I've been hand-tweaking .sh3f files to incorporate the original image files -- which I now suspect ultimately made no difference, assuming SH3D insists upon enforcing the power-of-2 rule regardless of where the model originates.

[W. Vann Hall]

After even more research, I've uncovered the following:

1. In theory, enabling non-power-of-two (NPOT) textures is as easy as setting a new Java3D 1.5.x variable -- ALLOW_NON_POWER_OF_TWO -- to TRUE; this causes TextureLoader to support NPOT textures.
2. However, enabling this variable assumes the associated graphic harder does support such textures; if it doesn't attempting to use such textures can result in distorted or all-black textures being displayed; graphic processing being handled in software, rather than hardware, with a noticeable performance hit; or an application or system crash.
3. Java3D provides a mechanism by which the application can query the canvas to determine if the graphics driver does or does not support NPOT textures. Unfortunately, support for this query is not uniform; for instance, some drivers report TRUE to indicate they can successfully handle such textures through software, while others simply respond incorrectly.
4. While most graphics cards manufactured in the past 10 years should support NPOT textures correctly, a number of older, lower-end systems do not. The most recent surveys I can find (roughly 3 years old) suggest a significant number of such cards are still in use.
5. NPOT textures are always supported in Q3 and Q4 renders, as these are always performed in software.
6. Optimally, SH3D would load and store textures in both native and POT formats, using the former for higher-quality renders and the latter for the 3D window and Q1 and Q2 renders. However, doing so would require massive restructuring of the application to allow the appropriate texture to be applied, based on rendering mode. In addition, TextureLoader would have to be overwritten to allow both texture files to be retained.
7. Given the degree of modification required, it may be this issue is best resolved in documentation. Admittedly, most textures survive the conversion to POT without visible degradation; the few that don't -- in my experience, primarily those containing type or other low-tolerance graphics -- could be resized by the user as long as this requirement was known.

[W. Vann Hall]

See this forum thread for more information.

[Emmanuel Puybaret]

Thanks for your detailed report.
As you suspected it, the issue comes from internal handling of textures by Java3D which converts by default all texture images to the nearest power of two size. TextureLoader constructor proposes an optional ALLOW_NON_POWER_OF_TWO parameter, but I fear it might not work in some cases. Anyway, I changed OBJWriter class to make it save the original texture images when they exist, with the additional benefit that exporting goes faster.
Please try the version 5.3 beta 12 or further that should fix this issue. Confirm also that rotation on textures works correctly in your case, because there were some important changes on this point too (note that textures at 45° will appear at their full scale on models with texture coordinates compared to previous version).

[Emmanuel Puybaret]

Version 5.3 was released yesterday.