llRezObject with self-determining rotation.

[Chaz Longstaff]

Okay my subject line sucks. But then I suck at rotations too.

I have some holo-vendors that I've jerry-rigged, several years ago. They rez cards (the cards have 0 rotation) for people to look at. Whenever we have a re-arrange in the shop and move the holo vendors around, sometimes changing the rotation of the vendors themselves from 0 to 90 or whatever, I have to manually edit the script in each holo vendor to adjust the jerry rigging.

Picture attached of what goes wrong. Is there a way to have the script pick up what rotation the holo vendor is at, and then compensate accordingly, so that I don't have to manually adjust each script?

Doing this right now:

input = input * DEG_TO_RAD;
rotation rot = llEuler2Rot(input);
vector rezzingOffset = <0,0,0>;
llRezObject(Object,llGetPos() + rezzingOffset, ZERO_VECTOR, rot, holoChannel);

If the holo vendor is rotated to 270, I have to do adjustments like this: vector input = <0,0,90>;  to compensate.

 

 

 

 

[Darkie Minotaur]

You have to set the rotation relativ to the vendor's rotation. I can't tell what the difference between the two rotations are, but I would start with 

llRezObject(Object,llGetPos() + rezzingOffset, ZERO_VECTOR, llGetRot(), holoChannel);

which would mean that both items have the same rotations.

if that doesn't yield the right result, you have to add or substract the difference:

vector diff = <0,0,0>; //a Euler rotation in degrees - this is the difference between the rotations of the 2 items

llRezObject(Object,llGetPos() + rezzingOffset, ZERO_VECTOR, llGetRot() * llEuler2Rot(diff * DEG_TO_RAD), holoChannel);

[Ela Talaj]

Try this:

input = input * DEG_TO_RAD;
rotation rot = llEuler2Rot(input);
vector rezzingOffset = <0,0,0>;
llRezObject(Object,llGetPos() + rezzingOffset*llGetRot(), ZERO_VECTOR, rot*llGetRot(), holoChannel);

 

(The  rezzingOffset*llGetRot() part is of course only meaningful if rezzingOffset != ZERO_VECTOR, but is useful for generality as one day you might have a non-zero offset)

[Ela Talaj]

This part seems incorrect: llGetRot() * llEuler2Rot(diff * DEG_TO_RAD)

The order of rotation multipliers matters and it prolly should be: llEuler2Rot(diff * DEG_TO_RAD)*llGetRot()

But re-check, I might be wrong cuz  kinda hard to think at this hour

[Innula Zenovka]

Assuming you've initially calculated the position and rotation of the rezzed object relative to the rezzer with the rezzer at ZERO_ROTATION (which is by far the simplest way to do it), then it's  

		rezzingOffset = <1.0,0.0,0.0>;//one metre in front of me, no matter how I'm facing		rot = llEuler2Rot(<0.0,0.0,90.0>*DEG_TO_RAD);//angled at 90 degrees to me, no matter how I'm facing		llRezAtRoot(Object,llGetPos() + rezzingOffset * llGetRot(), ZERO_VECTOR, rot*llGetRot(), holoChannel);

 

[PeterCanessa Oh]

If you are just rezzing the cards so the customers can see the pictures then you might prefer to use a particle emitter rather than actually rezzing them.

Holovendors - just rez one thing and leave it there until something else is required - are not significant lag-generators but do require prims for the rezzed objects.  For a card I'd guess there are only 2 prims each but even so the collective prim-count might be significant in your shop(s).

Temp-rezzers - set object TEMP_ON_REZ and keep re-rezzing it at less than 1min intervals - don't affect prim-count in the same way but all that re-rezzing can mean a lot more work (and lag) for the sim.  With a small, 2-prim, card that's probably not too important but again the cumulative effect with many vendors may be significant.

A particle-emitter i) Does not take prim-count, ii) causes (almost) no lag, iii) will always face the customer, even as they walk around

 

[ETA for below:  No problem then.  If you don't have to worry about prim-count or lag the only advantage to a particle emitter would be that it always faces the customer.  That can be a good effect but it's not always what is wanted]

[Chaz Longstaff]

Hey Peter, figured that topic would come up.

Though it's a "holo vendor", I'm not doing temp on rez. I own the sim and am careful with prim usage in other ways, so lots of prim.

[Alicia Sautereau]

http://wiki.secondlife.com/wiki/LlRezObject

 

// Rez an object on touch, with relative position, rotation, and velocity all described in the rezzing prim's coordinate system.string object = "Object"; // Name of object in inventoryvector relativePosOffset = <0.0, 0.0, 1.0>; // "Forward" and a little "above" this primvector relativeVel = <0.0, 0.0, 0.0>; // Traveling in this prim's "forward" direction at 1m/srotation relativeRot = <0.0, 0.0, 0.0, 0.707107>; // Rotated 90 degrees on the x-axis compared to this priminteger startParam = 10;default{    state_entry()    {           }    touch_start(integer total_number)    {        vector myPos = llGetPos();        rotation myRot = llGetRot();         vector rezPos = myPos+relativePosOffset*myRot;        vector rezVel = relativeVel*myRot;        rotation rezRot = relativeRot*myRot;         llRezObject("rezzed", rezPos, rezVel, rezRot, startParam);    }}

 

Just removed the 2 meter offset and gave the object a name
Should do what you need it to do