Building bugs! Die die die!!

Am I the only one seeing lots of slightly off positions when building? I have this one building that while I'm working on it, it seems almost like the entire world is on a very slight angle or something!

Then there's also the weird stuff like this--note, both of these prims are rotated exactly 90 degrees (if at all), and they should *defintely* not look like they are angled slightly. This is the most subtle of what I've noticed:

HATE THIS

I can live with that, I GUESS...but this stuff really seems to get out of wack BAD sometimes. Tonight I was shift-copying stuff and while it was saying that the only difference between the two prims was the z-dimentions, visually there was clearly some y-dimension difference...even though they were identical objects and the y position said it was the same. I'll get actual screenshots next time I see it. Relogging didn't help fix this wierdness. And when I say it was "visually" off, I don't mean like the screenshot I just posted, I mean *really* off. Even a blind ATI player would notice it...but numerically these objects should be lining up perfectly. I'm having trouble reproducing it, though. It might be related to a specific build I have.

Yeah, that bug is definitely one of my most hated. After some experimentation with the help of one of the Lindens, we discovered that while the text entry field in the edit menu is an integer, the actual rotation data is stored as a float.

While the edit window SAYS your object is at 90 degrees, it's actually at 90.3, or something similar. To fix your objects, manually rotate them to 0,0,0 and then back to the intended rotation.

On a side note, the text field for texture tiling per square meter rounds off, so if you type in, 0.25 repeats and hit enter, it'll round up to 0.3. If you press "apply" first, it'll tile your texture at 0.25m.

*insert sarcastic, UI-belittling comment here*

Oh geez. Thanks for that info I'll try it.

Something about this was screaming "float inaccuracy" but I shrugged it off. At least there's a way to fix it, though.

I'd like to actually see the floats in the rotation. theres been times when I've needed to actually rotate to 11.5 degrees (for example). (180 / 6).

I completely agree Mezz, same here.

if you use a script, you can get that precission. if you need one, i can(or someone else) can post it to the library.

edit-talking about the rotating of said objects.

Okay, the rotation thing worked for that problem, but here's one that I'm REALLY stumped by. Can anyone explain this one?

WTH

Notice a few things here...the screenshot shows both objects while they are selected

1) the SIZE of both walls are identical (in the height (Z) direction)
2) the POSITIONS of both walls are ALSO identical, in the Z direction
3) the only other difference between the two walls (besides that they don't visually line up) is that one is rotated on the Z axis 90 degrees....but that should not effect the z position in any way (try it in game to see what I mean if you're confused)

I needed to move up the right wall by .03 in order for it to match up visually. Relogging didn't fix this the other night, they still showed up visually off and the numbers were the same. Tried playing around with the rotations and nothing made it go to where it should...

So now I ask this.....huh?

I've seen that one and reported it.

In the meantime, I just re-scaled my rotated walls and un-rotated them.

maybe the pokemon is causing the problem?

have you let it fight other pokemon recently? maybe it's lonely?

lol

Bah, building bugs have to be the next worst bugs after crashes.

I didn't think about the Pokemon thing, I think that's the problem, thanks.

"Gotta catch em all"

Could it be a stretch?

I mean, 'stretch' sometimes affects the 'size' of an object, but if at any point its stretched while linked, it will apply a sort of scale matrix to it, which doesn't show up in the 'size' fields, but is nevertheless applied.

Not sure, I know it wasn't stretched while it was linked, although it may have been resized using the "stretch both sides" at some point. (I switch back and forth between those modes alot.) Still have no idea what would have caused this bug, maybe Tiger does.

As far as I can tell, stretch can do two different things to the object, depending on circumstance.

It can modify the objects Size (X,Y,Z), that is shown in the texbox and you can edit...

or...

It can apply a SCALING to the object or group of objects.

You can see the size and edit the size, but the SCALING is not vieweable in the user interface and is not editable in any way that I can see. It gets applied after everything else has been applied (size,shear,etc). For those techies out there: It appears to be a scaling matrix that is put on the very end of the object generation queue.

Note that the objects 'SIZE' (as appears in the boxes) does not actually appear to change when scaling these things.

This is not really a bug - but, it would be nice to be able to at least reset the scaling....

Things appear to be SCALED when you are using STRETCH on linked objects OR on rotated objects when LOCAL AXIS is disabled. Sometimes it just does so anyways.

Things appear to be SIZED (ie, actual textbox values change) when you STRETCH in local axis or when no rotation is applied (sometimes).

Since theres no way for us to actually access this final scaling, you may as well delete the object and copy a fresh one.

I would suggest not stretching anything linked to another object, nor stretching when not in local axis mode, until we are provided with a 'Reset Scale' button or an actual scale text entry of some kind.

PS the scaling thing is every useful, its not a bug, things like being able to scale groups of objects up and down would be impossible without it (like making clothing attachments fit properly)... the problem is more that we cant actually access this scale.

Perhaps if there were 3 new edit boxes next to size that contained scale.

(Scale would be a percent modifier along x,y,z)

Well I don't think it's simply scaled, because the actual size of the object is the same, I think. (I probably didn't scale that object anyway, I think it was just a shift-copy and 90 rotation.) I don't think I agree about the scaling being done the way you describe, but I'll have to check it out in game some time and look for myself.

All of the scaling that I know about changes the numbers in the text box (that's why you sometimes can't scale past a certain amount, if it causes an object in your linked set to be bigger than 10 or less than 0.01 in one dimention.) I don't think there's a second calculation going on. Anyway--

Here's another shot...in this I was moving it in the Y direction only, but you can see that the further I move it away from the original copy, the more "off" it looks. It appears to gain altitude! If you go the other way, it slowly gets closer to the ground... I have this prim in my inventory and it's entirely reproducable.

(btw I layed it out in reverse order, the top one is when it's moved the furthest)

BTW are those gnomes....? HMMMMM...

Yes. This is the same bug I saw and reported. They replied that they know about it and are working on it.

In the meantime, as I said, rotate the object back to zero rotation, and re-scale it to the shape you want. Then it will align. This only happens to rotated objects.

I reported this myself, Dan Linden wanted me to send him the object that does this but I don't think I have any way to do that.

I think you can drop it on his calling card if you have it?

No I don't have it, but he said I could drop it on his profile using Find, so that should work.

This is a display deficiency in our build tools. You can rotate an object a fraction of a degree, but our rotation window displays the nearest whole degree. You can make an object with a rotation of <0.5, 0.5, 0.5> and it will appear to have a rotation of <0,0,0> in the tool palette but will not be perfectly alligned with another object. The current workaround is to type 0's into the rotation windows, which will set them to true 0.

This has been entered as a bug, but I don't have an estimated time for a fix.