llRezObject and llRezAtRoot woes

Okay. Is it just me, or are both these functions very broken? I'm trying to rez a single linked object (not a composite of objects, I know that's bugged in llRezAtRoot) from a single-prim rezzer at the rezzer's location (obtained with llGetPos), and for some reason both functions keep rezzing the object at weird offsets from this.

I know that llRezObject calculates the geometric center differently than llGetGeometricCenter, but the point the object is rezzing at doesn't appear to be any kind of center. Except in certain instances, it's actually rezzed at the root of the asymmetrical object. Its behavior seems to change based on... something.

As for llRezAtRoot, it appears to be rezzing at the "second-in-command" prim rather than the root. And don't even get me started on the weird rotations it rezzes at that are apparently based on the rotation the object was at when I took it into inventory.

Has anyone else had these crazy problems? I find it hard to believe I'm alone in this.

I've had none of the above, but the problem with large objects unlinking and setting rotation for all child prims to the same as the root prim has bugged me a couple of times.
Furthermore, the rotations given to objects rezzed from child objects gave me some headache at one point, finding out how to calculate rotations of rezzed objects that need to be aligned to the object rezzing it (child prim or not) is always a pain, after my experience

I'm also trying to build a rezzer for something useful, and am having plenty of difficulty with it. llRezAtRoot is clearly what I want. The Rotation doesn't seem to work. (llRezObject does at least seem to get the rotations right) I'm afraid of what would happen if I tried to actually apply a vector to something.

Beatfox Xevious seems to be on the the ROOT problem
/111/86/36267/1.html

Tommy Oz is also beating his head on this
/54/1e/35064/1.html

According to the wiki, we got llRezAtRoot with 1.5.6 on Nov 4, 2004, and it was soon acknowledged by Don Linden there was a problem (Nov 2. but it sure looks to me like it's still broke, maybe Don needs to read Beatfox's post
/54/a1/28379/1.html#post285038

I had always wondered why Apotheus's Vendor rezzed in odd locations, it uses llRezObject. I thought llRezObject used to work on the center of the bounding box, but now it seems to be weighted by the grouping of the prims... is this supposed to be the center of mass or something?

The best I think we can hope for is that this has been fixed in 1.6 and maybe that'll be released sometime... soon?

llRezAtRoot() looks ideal almost for every single application, doesn't it? Yeah, too bad about it being broken and all. It's been known to be busted for a few months now.

The good news is it's still possible to do what you're after. The bad news is that it mostly involves a lot of pain.

The idea is that llRezObject pretty much works, it just has a strange notion of what it considers to be the center of the object. So, you have to translate the delta between rezObject and the center of object, modified by the inverse of the rotation.

Try llGetGetCenterOfMass, who knows, that might work I built my rezvendor (which tries to account for the rotation of the vendor) before either of these two functions existed, so I figured out the center mostly by eyeballing it. I haven't revisited the problem since, but I do recall lots of cursing was involved in obtaining the solution.

Good luck, I hope you find a general solution and post back good news

Given I built a few scripts that work in very reliable ways, based on rezzing and center behaviors, perhaps I can help. As far as I know, llRezObject rezzes based on a world position (ie. <0,0,0> would attempt to rez at that position, even though it may be out of the appropriate range), but I believe if you move the sucker during the rez event, you risk throwing off the constant and having it end up at a *slightly* different position. Not good for mobile objects.

Anyway, as a rule of thumb I just use llRezObject with llGetPos, and it's appeared fine before. I even took the courtesy of testing that in-world moments ago. It rezzed fairly precisely.

However, to address your second question of Geometric Centers, I dealt with this a fair bit with my 3D importer. For that, depending on the shape, you would pretty much need to know that it calculates, well... a Geometric Center (the mean of points on the shape, or in reality, the mean of every point on the object with an integral or volume method). This is not the llGetPos position. llGetPos is calculated based on the center of... well, the root object in the system pre-modification. There are several ways to get that, but not one single, good geometic way for all prims other than llGetPos.

So, in English: Use llGetPos and/or position coordinates with llRezObject and you should be fine. You need not calculate this from scratch, since llGetPos should work just fine from the prim the script is in... and for moving objects, you might want a slight correction or direct vector, depending.

And I don't use llRezAtRoot, if nothing else, out of sheer habit.

Edit: Whoopsie! llGetCenterOfMass is what I meant, as opposed to geometric center. Not sure what the latter does, but it sounds to me like very similar to llGetCenterOfMass, and as I see it, neither are the true llGetPos point value.

llRezAtRoot is an extremely oddball function and I hope it gets fixed ASAP.

/me smells a bump.

Yeah llRezAtRoot is using the SECOND-to-last prim in a link instead of the LAST prim as it's "root" for centering purposes.

AND it doesn't set the rotation from 0,0,0 but from the rotation the object was in when it was last taken from the world.

Yup, been broken for awhile.

I finally gave up on this and simply told the object via a message where to go.

Same :/

It's a somewhat unsightly solution but it seems to work.