Item Insists on Rezzing Above Ground

I'm exasperated... I made a chair. I made it on level ground, flat on the ground. When I take the thing into inventory, and drag it back out, it's floating above ground level.

I've checked scripting and everything else I can think of, and I cannot figure out why the darned thing won't rez ON the ground instead of ABOVE it.

Is there some simple thing I'm missing here? Any advice would be appreciated.

Are there any cut prims in the chair? If so, be aware that the bounding box on a prim is the same whether it's cut or not. The cut away area is still there, as far as rezzing is concerned. You can't see it or collide with it, but it is still there, and it will serve to keep the prim's center off the ground when it's first rezzed.

If this is the source of your problem, then the solution is to re-orient any cut prims so the cut away area does not face the ground. This is usually pretty easy to do.

There are. But interestingly, it doesn't face the ground, and a matching love seat and couch with identical cut parts rez flat on the ground. It's very peculiar. Any other possibilities I wonder?

Exact same question: /8/9c/99082/1.html

The cut prims in my object can't really be oriented differently, they involve the top edge of a torus. I'm working on the script from the other thread, to make it work correctly.

Problem is, I've found that the object doesn't always rez at the same elevation, and that's key to making it work. If it always rezzes at the same amount too high, then I'd just knock it down by that much on the Z. What would be the best way to deal wth this?

a small script to move it down on rez event
untested (at work)

vector targetpos = <0,0,-1>; //down 1m
vector pos = llGetPos();
vector ground;
default
{
 on_rez(integer start_num)
  {
    ground = llGetPos() + (llVecNorm(targetpos - pos.z);
    llSetPos(ground);
  }
}
/
CODE


-LW

What a pain to have to script around something that ostensibly shouldn't be happening in the first place and has an unexplained cause... But it's not that big of a deal.

My main concern is that Linden addresses the root cause, and then previous copies of the object rez "xx" meters too low on the Z axis, embedded in the ground -- which could be particularly problematic if the object is too small to stick out of the ground so you can grab and move it.

I may just let the thing rez where it does, and leave it to the person rezzing it to fix it.

Wesley: check my thread about the same issue. /8/9c/99082/1.html

The script there works perfectly. All you have to do is figure out how far above the ground your object is rezzing, and where it needs to be when it's done.

I put one of the scripts in my problem object, along with some llSay commands that let me know things were working correctly. When I took the llSays out, there wasn't even a delay in the object's movement, so no one should have to know.

I do not see this as a problem to be fixed, merely a side-effect of having to work with prims. Prims are what make SL geometry possible, so until we get full polygonals, we gotta work with those lil monsters. I'm happy.

I disagree. The piece in question was built flat on the ground. None of the prims descend lower than the bottom plane. It is, in fact, identical to 4 other pieces of furniture that are identical other than their width (two chairs, one loveseat, one couch). Only this one specific object (one of the two chairs) rezzes in this way, and it does so consistently, every time.

I don't think that has anything to do with prims -- it's an oddity specific to this object, and I'd love to figure out what it is.

I'm certainly not ruling out that I did something to cause this. But it would be nice to know what's going on and how to resolve it rather than work around it with a script that could still have undesirable side-effects in a future version of the SL client software.

C'est la vie. Unless the Linden folk weigh-in on this, there's no way to know for sure what's up. Perhaps I'll try remaking it from scratch and see how the thing behaves.

Thanks everyone for the comments just the same.