llRezAtRoot doesn't work in some cases

There are various prim configurations (pretty basic ones, nothing complex) that don't work with llRezAtRoot. They rez at odd positions with weird rotations.

Pretty sure they don't work with llRezObject either, but I'm not sure exactly what that one does when the geocenter is not entirely clear.

This is a bit of a show-stopper for me as I have to reconfigure objects if I want them to work with RezObject/Root

Could you give an example of a configuration where such problems occur? Or drop me one in SL?

Till Stirling

Sent you an object in SL.

Would you mind to send me one as well? I tested it during the preview and didn't have any problems. I'd like to see what you are running into. KTHXBYE!

Yeah, I sent it to you as well. Pretty sure this doesn't work with rezobject either.

I too gave up on this - I wanted to rez larger grouped 'scenes' on my land but found the rotation was off, and trying to calulate the vector for the position was impossible

If anyone solves this and I was just totally missing something - i'd LOVE to hear about it

I'm having a hard time finding a composed object that actually works.

Sigh.

oh i just gave up. I send it a message and tell it where the root position is supposed to be.

if you're having difficulty getting either function to work, you can simply use the old tried and true method of calculating the offset of where you want the object from where it rezzes. (For larger linked objects, your object may simply not rez because it's offset is further than the silly 10m restriction).

So normally the process is simple.
First, place your object where you want it relative to the rezzer and GetRot and Getpos it.
Record these values.
Next, have your rezzer rez the object at these values. Getrot and Getpos it.
if the object is not where you want it, subtract the second values from the first to get an offset.
Apply this offset to the first values.
This should give you a correct position and rotation in relation to your original placement.
if your object is not appearing at all, you may have to hit or miss guess a few times to bring it closer to the rezzer. I've had to do this a few times with objects that were roughly 30x20x10 or so.

ok - so this implies ignoring llRezAtRoot() all together yes?

I have no trouble with this process if it works thanks for the tip! looking forward to trying this!

Can you give me a copy of the object you are trying to rez, and the script call you are using?

I made an object and script and sent it to your avatar. I believe it's also busted for llRezObject as well.

Can you explain the difference between rezzing at the Geometric center versus the Root position?

If you rez at the geo center, can't you just take the diff between the geo-center and the current position and then adjust the current position by that to get the original rez position?

The problem with this is that you cannot compute the geometric center of an object spontaniously, from inventory. If you require it, you need to rez it, make the appropriate calculation, and somehow store it in a way that the rezzor script knows the value that corresponds with the object.

Not only this, but last I heard, llRezObject's definiton of "geometric center" is different from the one calculated by llGetGeometricCenter()

Hmm you're right, there is a bug here. I will take a look at it next week. It is using the wrong prim in the linked set to make its calculations... For now you can use a workaround though. Make the last item in your multi-selection a single prim object, and then it will be forced to use the correct prim for its calculations. Then, you should be able to multi-select your whole building and choose a single-prim 'anchor' object last, and just rez the anchor at the same position/rotation it was at before you "Take" it into inventory.

Is anyone actually using llRezAtRoot? I plan on fixing it, and am just wondering if this will break anything people have out now. (The workaround I mentioned will still work after the fix, and won't be affected).

Christopher,

The idea is to calculate the geo-center from the rezzed object and then shift itself to the right position. However you said that geo-center as calculated by rezobject is different than what's calculated by llGetGeometricCenter .. Don, can you explain the difference? I would really appreciate if you could.

Right now, I sent it a message telling it where to go and it does it that way with llSetPos. It all works great now, and I was sending a message anyways so no real extra overhead (though I do lose some space I could use for other things..)

Don,

I don't know the objects a-priori. They could be anyone's objects and I can't expect them to relink in order to use my scripts. Thanks for the suggestion though. Also, if you have a second, can you explain the difference between llGetGeometricCenter and what llRezObject is calculating for the geometric center?

I really should check scripting tips more often lol.

Okay the difference is largely that llGetGeometricCenter seems to largely have no use.

So basically the rez functions will calculate where to rez a linked set based on THEIR calculation of the geometric center of the thing they're going to rez. This is insanely annoying.

Frankly, I would have found it much easier to calculate by root prim position simple because it's known, available, and there'd be no need for users to double rez something to calculate relative offset and hardcode it into scripts for specific objects. I'd love to see rezzing changed to this. Even fixing geometric center won't be all that great as none of the edit menus display geometric center. It's just one extra, unnecessary step we'd have to take

My best guess on how they're calculating differently is one is using the size of the prims and the other is using their positions. Or something like that anyway. It's been awhile since I last experimented so that's the best I can tell you.

In theory you can follow the llRezAtRoot function to rez something offcenter (say you had a large 30x30x30 platform and wanted to rez objects over one corner of it instead of the middle), you could use the method I described earlier for calculating offset to appropriately position your rezzed object where it should go. But if you're just rezzing over the center of an object and that's where your root prim is anyway, there's no real difference between the functions.

Hmm .. ok, *next* preview I beta-test. probably save me a lot of anguish to get them while they're paying attention!

When you select a group of prims (linked or unlinked, but lets assume linked), you get the dragable arrow cluster somewhere in the middle of them all. That spot is actually the average position of every prim's center. That is the "center" used by llRezObject. The only real way to calculate it is to somehow get the position of every prim, add all those vectors together and divide by the number of prims.

llRezAtRoot uses the root object's position instead, something I've wanted for ages. But it looks like it has a bug with unlinked collections of objects. It doesn't use the prim you expect it to (the root prim of the last object added to the selection), which is why Don suggested making sure that the last object added (when including multiple objects in a selection) has a single prim, so there is no discrepancy.

If you are rezing a single linked object, you should be fine.


On a side note, I tend to name things like this:

prim - an unlinked single prim
object - a linked group of prims
collection - a selection that includes any mixture of more than one prim or object, unlinked
inventory item - a single line of inventory or contents that can be any of the previous three types

Tiger, the question was what is the difference between llGetGeometricCenter and what llRezObject does. I'd be interested in a detailed answer if you have one.

My concern to the workaround is that people don't know apriori or can't modify the object before rezzing and so have no control over linkage.

Bump for those who are interested.

Has anyone done anything about this YET?
Is fixing this simple problem with rezzing objects really that hard LL?
==Chris

Erm anybody been into preview to test this, seems its been bumped, sittin in 1.7 rezzing from root now using this, rezzing a cube a meter above a linked set of 3 spheres.

default
{
    touch_start(integer num_detected)
    {
        llRezAtRoot("Object", llGetPos() + <0,0,1>, ZERO_VECTOR, ZERO_ROTATION, 0);
    }
}

llRezAtRoot doesn't go really wierd until the object being rezzed has 2 or more prims.

I'd rather forgotten about this bug... I'll have to test in 1.7 and send in another bug report when it uses the wrong prim again.

Yes i've just seen the bug, its the rezzed object thats positioned using the 2nd to last linked prim, and not the rezzer which i had thought from the thread. So i've submitted a bug in 1.7 with code.