Free Textures!

[Carl Palmner]

I notice that many of the textures have length and width that are multiples of 256. Why is this? Is there a texture size requirement in Uru that I didn't know about?

[dendwaler]

Mipmapping in blender (3d programs in general) scales it down by numbers of 2 , relative to the distance from the object.
1024 >512>256>128>64>32>
Textures of equal sizes can be tiled seamless when the texture is optimized for it, in size, pattern and equalized in color and light.

[tachzusamm]

I notice that many of the textures have length and width that are multiples of 256. Why is this? Is there a texture size requirement in Uru that I didn't know about?

Normally it's not necessary to pay too much attention to the size of a texture, because the PyPRP tools for Blender convert them automatically to powers of 2 width and height when exporting an age.
By the way, this is not a special URU requirement - it's more related to the way graphic cards handle textures. Nearly each game, based on DirectX or OpenGL, prefers textures in this size steps. It's just faster to process in hardware then.
Oh, and 512x1024 is usually as good as a squared format for example.

Mipmap

[Carl Palmner]

Interesting. You say that PyPRP will convert the textures to correct sizes--will this cause visible distortion and loss of quality?

[tachzusamm]

Interesting. You say that PyPRP will convert the textures to correct sizes--will this cause visible distortion and loss of quality?

It will cause no visible distortion.
Loss of quality only if very small images are used, e.g. an image of 80x80 would be reduced to 64x64. But it should not be visible if an image of 1200x1200 is reduced to 1024x1024 - and the pre-selected algorithm for conversion is "best" (and slowest).
I remember there's an option in PyPRP to switch the algorithm, but I forgot where or how. Default ist just best; I assume Photoshop can't do the reduction better.

However, this is valid for photographic images.
If computer generated images are the source - either by a pattern generator or by exporting from a vector format - it will be best to generate or export directly in a power of 2 sized image (because narrow width lines may loose details when resizing).

[Carl Palmner]

Ok. My biggest concern here is textures which are not square in dimension. For example, I have a few that are about 460x300 or so. If everything is being reduced to a power of 2, won't that also change the ratio of length to width (at least for a texture like the one I described here), thus distorting the image? It seems to me that it would--but I'm certain I've seen non-square rectangular textures in Cyan's Ages, so perhaps there is some kind of workaround?

[tachzusamm]

If you apply a non-squared texture to an object, and it looks okay and not stretched in Blender (I assume it will look okay, because it's up to the Age Writer to apply it properly), it will look okay in URU as well - because although the texture may be resampled, edges of the image stay on the same edges of the object as before. As well as each part of the image maps to the same part of the object as before, in Blender and in URU. No strange things will happen.

There may be some special cases where it's better to keep the image's original resolution and size, e.g. when you create the linking image shown in an open link book; in these cases, it's possible to switch mip-mapping off for this texture (or was it the "Interpol(ation)" switch?), and the image will be kept unchanged.
But that's not really the recommended scheme for normal texturing.

[Carl Palmner]

Right, I figured that, but what I mean is, wouldn't a non-square texture get stretched due to the re-sampling? Using my 460x300 example...the closest to 460 is 512. The closest to 300 is 256. If the image gets re-sampled to 512x256, it seems to me that that would stretch it out, because it's a completely different length-width ratio. Even if Blender (or PyPRP or whatever) always resamples downwards, that would still result in 256x256, turning a non-square texture into a square texture, which I would think would "smash" it horizontally.

Let me know if I'm wrong. I have certain "hex tile" textures that I'll need to redo if this is the case, because they would look really bad when stretched or smashed.

EDIT: Here's a visual example of what I mean, since I'm not sure if I'm communicating very well. Below is one of the textures I created. The dimensions are 427x355. It's a non-square texture intended to be used to create repeating hexagonal tiles:



Now, when I use Photoshop to resample this to 512x256 (the nearest power-of-two dimensions), I get this:


Obviously, this looks very different. Is this what would happen if I try to use the original 427x355 texture in an Age?

[dendwaler]

Because you are forced to use" uv mapping" the endresult depends on the "stretching"of the uv map instead of the stretching of the texture.
In my opinion it becomes difficult when i want to blend an overlay with a second texture and this second texture has a different format from the first one.
Then i have to use the input scaling function in blender to get it right, but it is still possible because i can set a scale factor for x, y indepent.
It becomes only a bit more difficult.
This problem however does not excist if i also use a second uvmap layer.

Personaly i prefer to have squares, but it is not necessary.
its between my ears.

[tachzusamm]

Is this what would happen if I try to use the original 427x355 texture in an Age?

No. This would not happen.

A try to make this understandable: Carl, you should try to forget that textures are in fact stored as images. But images are not displayed directly in an age. There is no possibility to "insert" an image in an age directly.
Instead, try to imagine that textures are always mapped onto objects. When you want to show the content of an image in an age, the image has to be mapped onto an object.
For example, let's assume you want to show a painting in an age's gallery. What you then have to do as an age creator is to create an object (e.g. a simple plane) with the intended size of the painting, e.g. 120 in width and 80 in height. The units do not matter here. Then, map the image as a texture onto that plane. Left edge of the image is glued to the left edge of the plane, right edge of the image is glued to the right edge of the plane, and same for top and bottom.
Now your image always gets stretched to the object dimension in the game (and in Blender too), no matter what the sizes of your image are or were.
The point is, objects (your painting carrier plane) do NOT get stretched, the width-height-ratio is fixed as soon as you created your image-carrying object.

I hope I was able to describe it more clearly.