The Unspeakable Bug

It must be an unspeakable bug, since I never see anyone mention it. Oooh... Maybe it's a conspiracy by the Lindens, and this thread will vanish without a trace!

Bua-hahaha. I kill me.

Seriously, I think no one ever talks about this because it's been around since the beginning. We've all gotten used to it. It's all about textures on prims and UV coordinates.

Make a 3x3x3 cube and give it a texture with a grid-like pattern, like brick. Now adjust the top size down to 0.5 in both directions. Look at the textures on the sides.

One half of the face is heavily distorted.

I know why this is happening, I just don't know why It's never been FIXED.

You see, 3D cards use nothing but triangles to make shapes. So a square side of a cube is actually two triangles. When you reduce the top size, the triangles change shape. But the UV coordinates assigned to each vertex (corner of a triangle) don't change. They drag the texture along with them, squishing it in the process.

There's an old Bugs Bunny cartoon where a show host (probably modeled after Spike Jones) has a black suit with yellow gridlines on it. (Or something like that.) The odd thing about it is that when he moves, the grid doesn't move with him. The texture stays steady while the shape (of his suit) moves. This is what the trangles should do too. Instead of just moving the xyz points of the vertexes, the UV texture coordinates should also be adjusted by the same amount. (Not when in motion, of course, just when being warped with the tools.)

But this is just the tip of the 'berg. There's more...

Make a new 3x3x3 cube, cut it to 0.5, hollow it to 50. Look at the textures on every face. They aren't all to the same scale, are they?

Well, there's a tool just for that, setting all faces of an object to the same scale. It's very handy. It's called "Repeats Per Meter" and you enter a number and hit Apply. Oops. But that makes no difference. Only the original faces are set correctly, the rest are hosed.

It's the same thing for cylinders. You have to multiply the U repeats by PI (by hand) to get the texture there to match other objects.

This is just silly!

Why haven't people complained? That's what I want to know...

[If you have seen this, and didn't like it, post a one-word reply of support here... or forever hold your (mis-textured) peices.]

A visual example...

I would love to see this fixed. Cones have this problem too.

And while they're at it, maybe they can provide more options for texturing spheres too.

Agreed, its a pain.

Allow me to chime in and echo the discontent with the way textures get applied to odd shaped prims. For me it is roof textures, annoys me to no end.

I just want to know why the inside of a hollow cube is a single face.

And you have to multiply the U value for the inside of a hollow cube by 4 to get it to tile right.

it gets even worse on a wedge, the triangle side is well, sliced diagonal, so its a clean texture surface, the other triangle side is contorted just as you explain, so is this saying that none of the sides are conforming to the same laws?

It's just that whatever code is in there to adjust the UV coordinates isn't doing its job and never has. It makes even Linden builds look unprofessional. Just look at any of the roads when they make a sharp curve. All those triangular slivers that make up the curve are half asphalt and half grey blur.

For those that don't know, "UV coordinates" are the X's and Y's in a texture. U and V are used to keep them from being confused with XYZ position information. The values of UV range from 0.0 to 1.0, no matter what the size or shape of the texture. <0.0,0.0> is the top left corner and <1.0,1.0> is the bottom right (or vice versa). What we put in as UV data in the texutre edit window is how much of the texture to show, with 1.0 being exactly one span of the image across the face, 0.5 being half the image, and 2.0 being two repeats, etc.

The "Repeats Per Meter" control SHOULD calculate the height and width of every face in meters, and multiply that by the value. So if the cut edge of a cube is 2 meters wide and the RpM value was 0.5, then the U value for that face should be 1.0. (2 x 0.5 = 1.0)

Some faces seem to have their U and V backwards. Others, like the curved outer surface of a cylinder, don't properly calculate the width of the face (need to multiply by PI there), and still others like a cube with a less than 1.0 topsize value don't take into account the changes to the face's shape.

Fixing this will change how a lot of existing builds look, but I think EVERYONE will be happy with the change. I don't think anyone is actually COUNTING on this bug to get the look they want.

It's a simple fix and the world will look LOADS better. Let's hear it for this fix!

Actual reply from a bug report directly related to this problem
from helpdesk, defining it as 'not a bug'. (?)

To make clear... this is not a post from Kelly Lindens, but a transcript from a bug report reply. I assume they have no problem with me sharing it in this forum.



Bug: no strectch texture doen't take rotation into account

Customer (Damanios Thetan) - 06/19/2004 08:26 AM When resizing a prim with a rotated texture and 'Stretch Textures' unchecked... the texture repeat values are changed as if there was no texture rotation. Eg 90 deg. texture rotation will actually change the Horizontal repeat value, when the Verical one should be changed and vice versa.

---------------------------------------------------------------
Response (Kelly Linden) - 07/20/2004 03:58 PM Dear Damanios,

Thank you for your report. This is currently not a bug. The problem is with significant texture warping that would occure at non-90 degree rotations. We would like to eventually implement a better way of handling rotated textures in the future.

Regards,
Kelly



So it apparently has their attention, but is no priority....

Just to clarify, there are multiple issues being discussed in this thread. Tiger's 'unspeakable bug' is a different bug than the one Damanios submitted. While they both relate to textures I do not think they are the same issue.

[edit: oops double negative]

Not the same bug, but in the same category, Kelly. As I mentioned in my posts in this thread, many of the cut and hollowed faces on prims will get their U an V values backward when tiling textures. Damanios' bug may have been on one of those faces, and if so, is the same bug. (Or very similar.)

If it's on all faces, then it is a bug in and of itself.

I've reported the "unspeakable bug" as a bug repot several times in the past. I saw that all pre-1.4 bugs were being closed, but i never got an email about that one being closed. I'm hoping it has just slipped through the cracks until now. Glad you saw this thread, Kelly.

(Though really, I expected the Linden content creators to have noticed this before, especially the road builders...)

I've seen this bug for some time. When I first encountered it, I assumed SL was doing the right thing and that it was just a quirk of OpenGL that everybody who used OGL compensated for.

But I'm now thinking that even if this is the case, SL should compensate for it, so that it works more intuitively as the userbase expands to a more mainstream crowd.

If it's a bug, then let's start a new thread to discuss a fix, since fixing it may cause some people trouble who have already made builds compensating for it -- though I agree it'd be best to get it fixed now than a year from now when the world is 10 times the size and there's even more builds that will be affected by fixing it.

Here's hoping this thread gets addressed in Cory's next Town Hall.

I've seen this one for awhile now. As I understand it, our method to make a texture to a face (even a warped or tortured one) is often the mathematically simplest.

The trapezoid is the easiest example, and the mention of 3D using triangles is spot-on. You can draw a line from top-right to bottom-left across the line of distortion. This divides the trapezoid into two triangles. Draw the same line across the square texture being mapped; this gives you a rough idea of how the texture is applied. The distortion is partly because the two triangles we've made on the TEXTURE are the same size, but the two triangles on the trapezoid clearly are not. As a result, the bottom-right triangle appears larger and grainier than the top-left, and the texture's skewed.

I managed to correct this once by using Photoshop to transform the texture I was applying; essentially deforming it ahead of time so it lined up afterward. It had to be done specific to the prim I had made; it was a nightmare to do the math for; and, ultimately, I eyeballed it after 13 incorrect uploads (half of which I corrected in the wrong direction).

It's probably something we can do better. By the same token, I see why it was done the way it was, and the "gee that should be easy" fixes I can think of, as was mentioned, fall apart when you start rotating a texture by odd angles.

Indeed. I found this out the hard way when I attempted (and failed) to build UV mapping support for my 3D Model Importer.

The one thing that interests me on this subject is we're not allowed to create our own UV maps for prims - naturally, that would greatly increase the stored data, so we can't do that.

And here enters my own personal frustration - when textures are rotated, their maps follow a set skewing pattern on all sides. We're unable to change the size of the skew itself, because it's relative to the size of the prim.

One solution that comes to mind is to start manufacturing new primitives - and there are many ways to attack the problem through that. But the question there is - is there enough utility to make that worthwhile?

I see that as the only viable solution, really. If we magically changed everything, today, it would break countless objects with the old texture system.

Actually it's been talked about quite a bit. The best thread on how to deal with it is here:
/109/51/34398/1.html


This happens on every 3D application there is, including professional tools like Maya. I deal with this every day. The ways around it are computationally expensive, and not well suited to real-time applications. Sure it can be fixed, but it's a question of whether it's worth the extra processing requirements in comparison to other things, especially when textures can simply be altered to compensate. Of course, not everyone will possess the know-how or the skill to make it work, but there are thousands of commonly useful things in SL that not everyone is able to do. I guess it's a question of where we want to draw the line between what users do and what the software does for us. Personally I'd rather let the system be as computationally inexpensive as possible, and let the users determine the best way to operate within that streamlined framework.


Yes, this would do it, but as I said, it's computationally expensive, and would slow things down.


Okay, here I agree with you. It is more than a little silly that repeats per meter does not affect all faces equally.



I'm not usually one to complain. My first instinct is usually just to figure out how something works and use it that way. Of course I always think about how it could work better, but then I usually find myself probing the reasons why it doesn't before I go complaining about it. If I can't find a good reason, then I might suggest an improvement. Rarely do I actually break down & actually complain. Just the way my brain works I guess. I'm kind of hard wired to want to understand a situation as a whole before I judge any piece of it. I realize that's not always the fastest method to deal with problems, but I do feel it's the most complete way, and in the long run it usually works best. Not sure if that's really of interest to you or not, but you did ask why, so there's the why for me.