How to preserve prim rotate with camera follower?

Seriously, how do you do this? Adding the existing rotation data to the llGetCameraRot makes it stop following the camera rotation at all (Why? Unless LSL doesn't do sanity checks and blows up on values over 360 degrees...). I have an object that I need to have follow the direction the camera is looking, but since its a sphere which is hollowed and dimpled, the "front" of the object is not facing the same "direction" as the camera's forward. So, I need to both rotate it by the camera *and* preserve the original alignment. Also, I am considering the possibility that what I actually need is for it to follow the camera Z *only*, not all three axis., i.e., spin, but not turn to face the exact camera direction.

I am at a loss why adding the two vectors won't work, since presumably vector math should take something like <300,10,60> and add it to <90,0,270> (I think that is the "alignment", and return <390,10,330>, and as a rotation, one would "presume" that this was converted to <30,10,330> automatically. Its quite odd that adding them actually *breaks* rotation, no matter which direction the camera is facing...

Pretty sure I'm not understanding what's being attempted here, but in any case it will probably be easier to just leave everything as rotations (quaternions), not vectors, and in the native radian units, not degrees, and multiply rotations instead of adding vectors (bearing in mind that quaternion multiplication is not commutative).

(Without seeing the code, my guess is that the problem is some combination of unit and coordinate system confusion.)

well if you rotate it to the camera rot, its x axis will face the way the camera points (check 'local coordinates' when editing to see which way that is). If you do a llGetRot() on it to save its rotation before you start moving, then at any given time you should be able to do a llSetRot(cameraRotation*savedRotation), or something similar.

rotations != vectors, you can convert a vector into a rotation using llEuler2Rot(<xdeg,ydeg,zdeg> * DEG_TO_RAD);

also rotations don't add, they multiply: to rotate to rotA, then by rotB, you rotate to rotA * rotB.

Am I understanding the question?

OK. I think so. Mind you, I don't comprehend the math at all. I am, frankly, used to using a program called POV-Ray and in that you would do something like:

define x = 20
define y = 40
define z = 50
define x1 = 90
define y2 = 0
define z3 = 360
camera{<50,10,2> lookat <0,0,0> rotate <x,y,z>}
object{sphere{<0,0,0>,1} rotate <x+x1,y+y1,z+z1> translate <50,10,20>}

In other words, you would "add" the rotations, not multiply them. lol Mind you, you could also do:

object{sphere{<0,0,0>,1} rotate <x1,y1,z1> rotate <x,y,z> translate <50,10,20>}

or, if you wanted to be dumb:

object{sphere{<0,0,0>,1} rotate <x1,y1,z1> translate <50,10,20> rotate <x,y,z>}

The later one would throw it off in some crazy direction, since your are moving it away from the origin <0,0,0>, "before" rotating it, so it would rotate as though the "center" of the object was still at <0,0,0>, but you where dealing with an object 100x20x40 meters in size. Oops! lol

SL uses the "only allow one *type* of action per object model, which means it will rotate an object, then "translate" it to where ever its supposed to be. This prevents the issue in the third example, but... it makes multiple cumulative rotations a real pain in the ass...

----

Anyway. You solution will mostly fix the issue. The question is, is there some way I can *just* apply the (Z) rotation to the object before multiplying? Though.. That opens a different can of worms.. How does 0 * anything = something? I.e., if I have the cameras (z) axis change the rotation, but nothing else, how the heck do I get the right results? Imho, the method they are using has some "real" serious drawbacks.