OBJ texture scaling error

Started by sboerner, November 25, 2018, 11:46:15 AM

Previous topic - Next topic

sboerner

Terragen throws an error when importing an OBJ file with scaled textures, and the textures are not loaded into the default shader's color image slot.

For example, this MTL definition will cause the error ("OBJReader: could not find a texture file for [filename].mtl"):

newmtl barrelStandSG
illum 4
Kd 0.00 0.00 0.00
Ka 0.00 0.00 0.00
Tf 1.00 1.00 1.00
map_Kd -s 0.25 0.25 barrelStand2_diffuse.tif
Ni 1.00
Ks 0.00 0.00 0.00

If the scaling attribute is removed everything works fine:

newmtl barrelStandSG
illum 4
Kd 0.00 0.00 0.00
Ka 0.00 0.00 0.00
Tf 1.00 1.00 1.00
map_Kd barrelStand2_diffuse.tif
Ni 1.00
Ks 0.00 0.00 0.00

Known issue?

WAS

Fairly certain Wavefront OBJ doesn't have texture scaling. Sounds like proprietary extra data for specific reader which is starting to become popular. For example you can actually embed specular and parralax info in MTL files for specific use with a companies software specifically designed to read that plain detail. When i look up wavefront mtl definitions I am not finding texture scaling.  I have a obj from sketchfab that I had to use the FBX on because it was specially formatted for another software reading extra bits and wasnt sure what to remove.

sboerner

I suppose that's possible. My obj files are exported from Maya, which as far as I know uses the standard definition. This looks like the original 1995 Alias/Wavefront mtl specification:

http://paulbourke.net/dataformats/mtl/

Quote:

The -s option scales the size of the texture pattern on the textured
surface by expanding or shrinking the pattern.  The default is 1, 1, 1.

It includes several examples of scaled textures.

WAS

#3
Oh there it is.

If you notice all examples use 3 inputs for texture scaling, while your file has 2. Additionally the scaling attribute seems to be used in conjunction with texture offsetting.

sboerner

#4
Thanks, Jordan. I appreciate the feedback. I did try adding a third argument to the -s attribute but still no joy. The Obj reader seems to accept only images with no scaling.

I took a closer look at the specs:

Quote-s u v w

The -s option scales the size of the texture pattern on the textured
surface by expanding or shrinking the pattern.  The default is 1, 1, 1.

"u" is the value for the horizontal direction of the texture

"v" is an optional argument.
"v" is the value for the vertical direction of the texture.

"w" is an optional argument.
"w" is a value used for the depth of a 3D texture.
"w" is a value used for the amount of tessellation of the displacement
map.

It appears that the -s attribute requires only the "u" parameter. "v" and "w" are optional. So it should work with one, two, or three values, no?

I understand that this is an easy fix. I always rebuild imported shading networks anyway. But . . . it should work. And the error message, which is a little misleading, could stump new users. (I recall getting many missing texture errors early on, and just worked around them.)

WAS

Hmm, yeah it should work fine. Have you tried adding a 0 offset just to see if it needs to be in conjunction? Logically speaking if you dynamically scale a texture you'd likely need to reorient with an offset.

I wonder if Matt can add this functionality to the reader. Its likely just a basic reader lacking comprehensive flags.

sboerner

QuoteHmm, yeah it should work fine. Have you tried adding a 0 offset just to see if it needs to be in conjunction? Logically speaking if you dynamically scale a texture you'd likely need to reorient with an offset.

Not if the texture repeats. And as a rule I try to avoid scaling textures even in the source (Maya) file. But sometimes it's easier to tweak a texture scale there than to roundtrip it several times through Photoshop.

There is an -o parameter for offset. When I have a chance I'll try that, too.

WAS

Quote from: sboerner on November 25, 2018, 04:35:39 PM
There is an -o parameter for offset. When I have a chance I'll try that, too.

Yeah that is the only other thing I saw used with the -s flag was the -o offset which I believe one of the examples showed a 0 offset.