Is it just me?

I am having a really annoying problem lately.

If I have 2 prims together, as in, lets say, a floor, and they are perfectly aligned mathematically, you can zoom in and see that one is clearly higher than the other. I'm talking about 2 prims that have the exact same height position number. This makes for some really ugly seams.

And I'm not talking about the usual "visible-seams-in-mathematically-perfectly-aligned-prims" problem either. This is something new and much uglier if you look from a certain angle.

Anybody else?

Do you have a photo? I'm wondering more about what you're describing.

Additionally, snap to grid is on?

Yes, I have seen this many times when building. Sometimes it fixes itself when I turn my attention elsewhere. Sometimes, if I link then unlink (or unlink and relink) they revert to the proper placement.

Or else... we both have the same VR hallucinations!

It could be something to do with rotations. Things that are rotated prefectly according to the numbers in the build tools, or even with scripting, only go as far as the float precision. Unlike with things like translations, rotations do more complicated things, which can lose you precision and give errors that are visible as seams.

Yes, I know exactly what you're talking about. This EXACT thing occured to me when I was making my store yesterday... lots of fiddly little bits... I'll put up a link sometime.

Yes I had this problem a while ago with prims being perfectly aligned mathematically and not lining up visually. And it's not just vertical positioning either. I had to scrap my 60x60x50 castle about half way through the project because of this annoying problem. The thing that really got to me was that everything was fine when I built those sections and then for no real reason they had drifted visually buit not mathematically. Even after going throuhg the entire section and typing in all the positions manually to make sure they were on the right place, they still were out visually. I tried relogging, tried picking up the build and placing it again.. same results. Definitely something screwy.. and this was some time ago.. may be 3 weeks.

I just finished a large castle and had to reset about 80% of the prims. The problem was due to me dragging the set around as a 500+ prim selection - since I couldn't link it all.

However, I did notice that some of the prims had tiny rotations applied, causing an effect similar to your problem. But, after I went through retyping coordinates and zeroing rotations, the walls aligned properly once again.

Also note that the edit window doesn't reveal the highest precision for vectors or rotations. A rotation axis may indicate 0.00°, but it could really be 0.004°. Same for placement vectors.

I don't use snap to grid.

As for how it looks, just imagine two prims next to each other. One is about .002 or .003 higher. But when you look at the numbers, the height coordinates are the same.

Very frustrating.

Hmmm... if you have a method of recreating this each and every time, I'd deffo like to try it and see for myself. I can see it in my mind's eye but have not reproed it so far.

Yes, same here, even when drag copying, it will be off slightly on the z axis in relation to the original. And as you stated, the numbers in edit match. Quite frustrating indeed.

Yep. This is a confirmed problem with the building system.

Don't worry. When it says it's perfectly aligned in the numbers, it is perfectly aligned. To everyone else (and when you log back in or go out of the sim a little bit), it should look just fine.

Basically, this is a problem where the viewer doesn't update properly when you've changed the object in some way.


To correct for this, just move the object slightly and hit Ctrl-Z. Ta-da!

Jeffrey, is this related to the bug where you enter coordinates for an object to displace it even greater distances or change the dimensions and it doesn't update for the viewer either?

If so, I've seen it on the macro scale, just not the micro one.

Very likely.

To be honest, the overhaul to the building system (when they added Edit Linked Parts) just made things buggy as hell when making stuff. To the point I tell people to use the aforementioned feature at their own risk.

This is one of the bugs they added around that time. A little annoying, but easy to get around.

Now, as for "Local Axes..."

I've seen this in my builds. When I built my pool I noticed the deck had seam lines along it which were quite annoying. I checked the level of the prims and noticed they were 1 to 3 degrees off in all xyz coords.

Large builds are even worse. I try to link my houses in sections as large as possible. Even though when selecting all sections and rotating it all the sections go nuts causing floors/walls/ceilings to be out of alignment (individiual prims in sections go out of alignment too). I tend to have to delete and retry rotations until it isn't so bad, then fix it after.

Don't even attempt to rotate large builds that aren't linked. They just go all over the place.

I thought it was a feature.

Maybe we should all lobby LL to have it made permanent. Then, they'll insist that it was never intended to be that way and fix it.

An undocumented one.

Oh no. Logging back in was the first thing I did--several times. The control z thing didn't work either, but I'm not sure I understood what you meant by that.

I had to delete a bunch of prims and start over. It doesn't seem to be happening now-I can't reproduce it any more. But it did seem like something new, not something that began with the addition of "edit linked prims."

I was having this trouble too. It isn't a bug, it is a rounding issue. There is more precision in the actual values than you can see in the edit dialog. You are seeing the rounded values which look correct when doing your math.

You can fix it by hand without too much trouble if there are not too many prims. Like DoteDote, I introduced this problem to a build of mine when I selected it and moved it (300+ prims). On some prims the problem is visual and in other places you can't see it at all.

I created a script you can use to fix it if you so desire. I also have a notecard that describes the problem in a little more detail -- if you want to fix by hand and not buy the script there should be plenty of info in the notecard to help you out.

The script is pretty simple to use. Just drag and drop it onto a prim and it will make the adjustments then delete itself. It displays the values before and after adjustment. Script is copyable (L$150).

Can find the notecard and the script in Andraca (138,107).

Pah, I made one today... You people can have it for free.

Here's one that rounds to what you can actually see in the edit box:

vector vecFix( vector in, float rval )
{
    return <llRound( in.x * rval ) / rval,
            llRound( in.y * rval ) / rval,
            llRound( in.z * rval ) / rval>;
}    

default
{
    state_entry()
    {        
        llSetPrimitiveParams( [ PRIM_POSITION, vecFix( llGetPos(), 1000 ),
                                PRIM_ROTATION, llEuler2Rot( DEG_TO_RAD * vecFix( 
                                        llRot2Euler( llGetRot() ) * RAD_TO_DEG, 50.0 ) ),
                                PRIM_SIZE, vecFix( llGetScale(), 1000 ) ] );        
        llRemoveInventory( llGetScriptName() );
    }
}

And here's one that rounds it to .005 increments (I found this useful on a build that I was making).

vector vecFix( vector in, float rval )
{
    return <llRound( in.x * rval ) / rval,
            llRound( in.y * rval ) / rval,
            llRound( in.z * rval ) / rval>;
}    

default
{
    state_entry()
    {        
        llSetPrimitiveParams( [ PRIM_POSITION, vecFix( llGetPos(), 200 ),
                                PRIM_ROTATION, llEuler2Rot( DEG_TO_RAD * vecFix( 
                                        llRot2Euler( llGetRot() ) * RAD_TO_DEG, 25 ) ),
                                PRIM_SIZE, vecFix( llGetScale(), 200 ) ] );        
        llRemoveInventory( llGetScriptName() );
    }
}

Just edit those in your inventory... I called the first one SeamFixer, and the second one SeamFixer2. These scripts fix position, scale, and rotation. Have fun!

Nevyn, shame on you for trying to sell such a simple thing.

A bit on the explanation... We have floating point numbers for the values of things, but the edit window doesn't display the full number. So, something that looks like "5.000" in the edit window can really be "5.00056". Rotation especially messes this up...

Hm. Thought that actually corrects itself on a height change? Guess not.

But yes. The building system only deals with three significant digits, and SL itself accounts for six. Though this is the first time I've heard those last few digits weren't "rounded off" in the system.

Guess you learn something new every day.

This really drives you crazy if you're making anything precision based with a lot of complexity. Siefert Surface makes fractals, so it would be particularly bad for him.

Just did an experiment... I have proof that scripting gets you more precision than you can get from the build tools, typing in numbers.

Basically, I have squares that should be touching at corners, but the rotation is such that some distance or scale has to have a llSqrt(2) in it. I scripted the positions and scales so that it should line up perfectly, which it virtually does as near as I can see (there might be half a pixel in it at the highest zoom in I can get). Moving one prim away and Ctrl-Z reverts it to line up perfectly. Moving one prim away then typing in the numbers for where it should have been results in a very noticeable gap (at highest zoom).

Interestingly, retyping in the location numbers when the object is in perfect position *doesn't* move it out of position. I guess the client thinks you didn't actually do anything, so doesn't send it to the server. Any sort of rotation of the set up, of course screws up the positioning, unless it is linked. I think this is because when linked, the positions of child prims are recorded relative to the base prim, and somehow the calculation with the rounding off doesn't happen here.

If someone would like a copy of the object I'm playing around with to get these effects, IM me in world and I'll throw you a copy.

I never implied that it wasn't an easy thing to do. In fact, I think my notecard even says it is easy.

As for "trying to sell" such a simple thing... and your point is? I spent some time working out a solution for a problem. To me, my time is worth something. What I am asking for the script is not much. For people who do not code, I'm sure it is not such a simple thing. It is a tool and a service I provided and to me that is worth something.

If you don't like that, well that's great, but there is no reason to criticize me for putting a price on it. Nobody is obligated to buy it. Yours probably works just fine and I'm sure people will appreciate getting one for free.

I have to agree with Nevyn's reply (just above).
A day after the original post his was the only post to address the actual issue and included a working (scripted) solution. Apparently you spent no time in-game finding the actual problem, but created a free solution based off Nev's work. (based off your first post which didn't appear to grasp the problem, then your "free solution" after Nevyn's post which pointed to the actual problem). Good job, detective.

Nothing wrong with free solutions, nothing wrong with charging fees either. It's a free market, thankfully. It does bother me though that you berate him for offering both an explaination of the actual problem and working solution.

Bos