Prims change rotations depending on location

[Pamela Galli]

I dont know if this is a server issue or not, and I am going to make a JIRA, but want to know if anyone else has noticed this. 

I updated textures on a house in my workshop. All rotations correct, root and prims.

I rez a copy of the house down in my store (on a different sim) and notice the (root) rotation was slightly off. So I correct the rotation. Then I check some walls and find their rotations are slightly off.

I go back and check the copy still in the workshop -- all rotations fine, take another copy, rez in the store -- now the root rotation is fine but the walls still not correct.

I took copies and rezzed, same result.

IN WORKSHOP:

 

IN STORE

[Whirly Fizzle]

Possibly a rounding error because your workshop is up at 1000m?

The higher the altitude, the more prevalent those rounding errors will be.

[Pamela Galli]

---

Whirly Fizzle wrote:

Possibly a rounding error because your workshop is up at 1000m?

The higher the altitude, the more prevalent those rounding errors will be.

---

Thanks! Yes it is at 1000. I never knew this, and it is a pretty significant thing. :-) Also 0.1 is a pretty significant error.

Oddly, although I have four versions of this floorplan, not all are affected.

 

[Qie Niangao]

I'm not crazy about the rounding error explanation here. For one thing, I'm not seeing why altitude should affect rotation, or really anything other than the precision of Z dimensions and calculations involving them. I can make up a story about an exotic geometry representation where that might happen, but it doesn't seem very plausible to me.

Also, yeah, that's a very large excursion for a rounding error. (I'm tempted to qiesplain floating-point representation but I'll spare y'all -- for now!)

A couple things I'd try, just shooting in the dark. One is to test rezzing copies right there at the workshop: one made by shift-drag and the other from inventory replicating the process where the problem arose at the store altitude. (Just a reminder, as you of course know very well, it's the original that's shift-dragged and the copy that's left at the previous location. It would be interesting to see if either of those got the weird rotation values.)

Then, try editing the Z location of a correct-rotation copy to push it down to store altitude (assuming that's above ground level). I know the actual store and workshop are on different sims, but we're testing the theory that altitude alone is causing the problem, and not something funky with the rezzing process.

Finally, if we can't find some other explanation, I'd try with a different viewer, one that shows fewer digits of precision. The error you're seeing would still be very visible in the Linden viewer, so... I'm not sure what it would tell us if it behaves differently, but I mean, it's an easy test, right?

[Pamela Galli]

Thanks very much Qie, I will do that testing, and I can keep the house in the same sim in the store as workshop. The error is big enough that fixing several prims and realigning textures* takes quite a bit of time. 

 

*because sometimes texture align bores, for one thing. 

[Pamela Galli]

Dont know what the implications are but:

Shift dragging at 1000m produces a copy with wrong rotations.
Taking a copy at 1000m and re-rezzing at 1000m produces a copy with wrong rotations.
Moving the house down to the store by changing Z position retains correct rotations.

Taking a copy from the ground and re-rezzing at 1000m retains correct rotations.

I really have a hard time believing I would not have noticed something like this before. Rotations being off that much is pretty noticeable.

 

[Qie Niangao]

Huh. That's so different from anything I'd expected that I honestly don't know what to make of it either. I guess it doesn't completely rule out the altitude-based rounding error theory, but it fails to confirm it in any of the ways I'd intended.

It feels almost as if there's something in the viewer that's trying to "snap to grid" the rotation of newly-rezzed items, in the sorta funky way it snaps the linkset centroid (rather than the root) to grid coordinates. But I don't know of any option that would enable such a thing.

Probably I'd try the Linden viewer at this point.

Then, if we still can't make sense of it... huh... maybe we hack up a litttle script to confirm the rotations are really as whacked server-side as they appear in the viewer's Build tool.

[ChinRey]

What is the rotation of the root prim, Pamela? That is rather important.

 

Here are two of the old rowhouses I have at Keswick:

These two houses are at ground level, only 24 m apart (you can see the first one in the background in the second picture) and they are both parts of large linksets that include the items around them.

The difference is that when I make changes to the linkset the first house is part of, its front wall modules shift from 180 to 180.05 degrees z rotation, when I make changes to the linkset the second house belongs to, the walls stay at 180.

What causes the difference, is that the root prim of the first linkset is at zero rotation while the root prim of the second has 180 degrees z rotation just like the walls.

Don't ask me why that happens. I have some ideas but don't know for sure and as Qie pointed out, the fact that you get different results at different altitudes doesn't seem to make any sense whatsoever - not even within the loose definition of "sense" we're talking about here.

[Pamela Galli]

The root is 270,0,180

 

At least this is not as big a nightmare as the old "prim drift".

But I don't even want to start checking other houses. I only noticed this problem because when I rezzed the newest house in the store, the root was off and the wall prims were aligned. When I adjusted the root, the wall prims were not aligned. All aligned in the workshop.

 

 

[mikka Luik]

Ah yes about that script checking confirmation... also tried that in case I was losing it but it confirmed edit window numbers. After the obligatory built in rounding errors converting rads to degrees of course. I build anywhere between 400 and 4k (Magnum sim) and the maddening thing is it has shown no consistency and is  fleeting with nothing to tie it to restarts or rollouts. It comes and goes, as Nanny Ogg would put it.

As ever I thought was just me but if anyone has a clue..

[ChinRey]

---

mikka Luik wrote:

Ah yes about that script checking confirmation... also tried that in case I was losing it but it confirmed edit window numbers.

---

Yes, defining the rotations as radians with a script makes no difference whatsoever.

3d software don't use radian vectors for rotations though, they're are only there to keep things from becoming too easy. What the software actually use, is quaternion rotations and it's obviosuly the conversion between that and the degree/radian values we use that causes the error.

Two brief and easy introductions to quaternion rotation:

• LSL wiki
• Wikipedia

Just one warning: Reading either of these articles will cause your head to start rotating.

This is not actually an SL specific problem but common to all 3D software I know of. It's more noticeable in SL though since modern software uses more bits to define the values. The only explanation I can think of why the bug's effect changes with altitude is that vertice posisitons also got mixed up in the mess and that doesn't seem to make any sense at all.

There are several possible solutions of course but I can't imagine we'll ever see one in SL. The number of dormant JIRAs about the problem must be two-digit by now and so far nothing's been done.

[Qie Niangao]

---

ChinRey wrote:

What the software actually use, is quaternion rotations and it's obviosuly the conversion between that and the degree/radian values we use that causes the error.

---

That's sure not obvious to me. Why should the same rotation (stored in whatever format) have a different conversion error when rezzed at a different location -- and then only unpredictably?

Also the deviations here are really huge. Even if we came up with some reason for different rotation errors at different locations, it would be a sorry representation that's subject to so much information lost in conversion. It's more than one part in 3600, right? so that would be a loss of precision worse than compressing an entire quaternion into a single 64-bit word.

Sure seems to me something else is going on here.

[Ardy Lay]

Cubey Terra once described this to me as an effect caused by the conversion between region coordinates and local coordinates when serializing an object into an asset.  He said that high altitudes result in a loss of Z-axis precision due to the magnitude of the repesentation.  The examples demonstrated showed misplaced prims in a linkset including the odd rotation change described here.  The work-around he offered was to sit on and ride the build to the ground before taking it to inventory.  He built aircraft in Second Life so this made sense at the time.  ;-)

[Pamela Galli]

Thanks, I can do a workaround. I just feel a bit dumb just discovering this. But then that is how I roll.

[ChinRey]

---

Qie Niangao wrote:

That's sure not obvious to me. Why should the same

rotation

(stored in whatever format) have a

different

conversion error when rezzed at a different

location

 -- and then only unpredictably?

---

That I meant was that the conversion should explain why we have the errors at all. I can't see any reason why it should differ depending on location either.

 

---

Ardy Lay wrote:

Cubey Terra once described this to me as an effect caused by the conversion between region coordinates and local coordinates when serializing an object into an asset.  He said that high altitudes result in a loss of Z-axis precision due to the magnitude of the repesentation.

---

That makes sense for positions but jsut like Qie, I can't see how that can affect rotation.