Camera insanity..

Read a number of threads, which *strongly* implies that this wouldn't work even if I "did" know what I was doing. But, its worth a try anyway. lol Frankly, the most seriously annoying thing is that the "normal" camera controls have pan up/down/left/right, move up/down/left/right, but no "move forward/backward". Zoom... doesn't fracking count, so you are stuck doing some bloody absurd and confusing dance to try to get your camera where you want. I would "prefer" to avoid that.

So, here is the idea. I have an object. Due to limitations involving "object return" in the area I want to use it, I can't rez a seat, or otherwise control the object without it being an attachment. So, I attach it, and it is "supposed to" take over my movement controls and camera, then position the camera *at* the location of the object (or a little in front), so I can "see" as though I was standing where the object is. It is then supposed to rotate the "object" to face a new direction, as though it was my AV, as well as move forward/backwards/up/down.

I have tried using some script for cameras that someone pointed me to, but it won't quite do what I want. Worse, the camera doesn't seem to "set" itself to the right position if those movement keys are trapped and not passed on to the AV (Which I can't do since I don't want to be "walking" while this thing is moving), and when I move the object being tracked, it moves in a direction I don't want, then stays there, without ever moving again, no matter how often I hit the one key I am currently testing with (I would like to get it to move "forward" correctly, before figuring out how to make it rotate or move other directions). And it moves to the *same* wrong spot, no matter what displacement I try to apply to it (both in terms of magnitude "and" direction).

Here is a buggy code I am working with:

Note. The item is attached at the "chest", starts out floating a bit in front of the AV (need to figure out how to reset it back there too..), and is rotated to Y = 90, Z = 270, to get the right face to be forward and the texture right side up.

default
{
    on_rez(integer id)
    {
        llResetScript();
    }
    state_entry()
    {
        llSetTexture("5748decc-f629-461c-9a36-a35a221fe21f",ALL_SIDES);
        llSetTexture("Fox_Mask_Solid",1);
        llRequestPermissions(llGetOwner(),
            PERMISSION_TAKE_CONTROLS |
            PERMISSION_TRACK_CAMERA |
            PERMISSION_CONTROL_CAMERA |
            0);
        llSetTimerEvent(0.25);
        llTakeControls(CONTROL_FWD | CONTROL_BACK | CONTROL_LEFT | CONTROL_RIGHT | CONTROL_ROT_LEFT | CONTROL_ROT_RIGHT | CONTROL_UP | CONTROL_DOWN | 0,TRUE,FALSE);
    }

    touch_start(integer total_number)
    {

        llSetTexture("Test_Alpha",ALL_SIDES);
        llSetTexture("Fox_Mask_Trans",1);
        // Temp, to unlock when things go boom!
        // In the final design this will merely make it transparent and cost more CCS
        // stamina to sustain than the mask by itself. It will still move the camera with
        // it.
        llSetCameraParams([CAMERA_ACTIVE, 0]); 
    }
    
timer()
        {
                list getdat = llGetObjectDetails(llGetKey(),[OBJECT_POS , OBJECT_ROT]);

                vector vTargetPos = llList2Vector(getdat,0);
                rotation rTargetRot = llList2Rot(getdat,1);
                // Should set camera to the object location, a little in front, but since ***all***
                // attempts to to do that failed, lets just try to use one that "does" work, in
                // theory, and test with that.
                llSetCameraParams([
                        CAMERA_ACTIVE, 1,
                        CAMERA_DISTANCE, 0.0,
                        CAMERA_BEHINDNESS_ANGLE, 0.1,
                        CAMERA_BEHINDNESS_LAG, 0.1,
                        CAMERA_FOCUS, vTargetPos + <0.0, 0.0, 1.0> * rTargetRot,
                        CAMERA_FOCUS_LAG, 0.0,
                        CAMERA_FOCUS_THRESHOLD, 0.0,
                        CAMERA_FOCUS_LOCKED, TRUE,
                        CAMERA_FOCUS_OFFSET, ZERO_VECTOR,
                        CAMERA_POSITION, vTargetPos + <-2.0, 0.0, 2.0> * rTargetRot,
                        CAMERA_POSITION_LAG, 0.1,
                        CAMERA_POSITION_THRESHOLD, 0.1,
                        CAMERA_POSITION_LOCKED, TRUE]);
        }
        
    control(key id, integer held, integer change)
        {
            if (held & CONTROL_FWD) //For now, lets just get this thing to move forward...
                {
                list abc;
                abc = llGetObjectDetails(llGetKey(),[OBJECT_POS]);
                llSetPos(llList2Vector(abc,0) + <0,1,0>);
                }
        }
}

This is driving me nuts...

The scripting forum would be far more appropriate.

You can with a combination of Ctrl-Alt and Ctrl-Alt-Shift camming. You can cam anwyhere within your draw distance without ever having to refocus on another object.

The camera controls does have zoom in and out. It's the vertical bar between the two discs.

Two problems I can see:

1) You have to be sitting on an object, or have it attached, in order for it to legally request PERMISSION_CONTROL_CAMERA.

2) When moving the object forward, remember that <0,1,0> means "along the world's Y axis" which isn't always forward from the object's point of view - you need to multiply the vector by the object's rotation.

3) Is there any reason why you're having the object invoke llGetObjectDetails on _itself_ rather than just using GetPos and GetRot? (There might be a good reason, knowing how quirky LSL is it might actually be faster, but just thought I should ask)

Zoom anywhere works quite nicely under joystick flycam with a 3d controller such as the Space Navigator.

BTW, since you're posting code, this thread should probably go to the scripting tips forum

If you need to use the keyboard, why not rotate your view down (ctrl-alt-arrow up) then pan "up" (ctrl-shift-alt-arrow up) to move the camera forward (then turn back up of course) if you don't want to ctrl-0 zoom in?

The best day was when I learned you can move the cam forward/back by alt clicking, if only that worked in RL too!

Well, that is sort of the problem. Zoom is **worthless**, since I can't zoom past where I am already standing. Since the point is to have my camera and object move "forward", while I am stationary... Same issue with the alt/ctrl-alt. Which is bloody absurd, since one *can* drift sideways, rotate to close to 90 degrees from where you are, drift again, etc. *and* end up where you would have been if you could have just told the camera to move forward in the first place. Its... really seriously frustrating and useless.

Hmm. Noted. Guess I didn't look far enough down the page. lol

Ok, first off. It "is" attached, and the script successfully gains permissions to take hold of the camera. The zone I am trying to make it for is an RP area owned by other people, so they have the "auto return items after X" set. This means I couldn't rez it separate anyway, and I am not sure I can rez and sit on it either (this may, possibly, break a rule they have in place at the moment to help stability in the zone, which disallowed vehicles).

Second... GetPos returns where I am, not where the object is. Since I want to remain stationary, while the object moves, it would be quite dumb for me to ask where I am, and track that, instead of the object. The point here is to have the camera look from the objects position and rotation, not mine, where ever that object may have gone, and to use the normal movement keys to get it there, instead of the insanely fiddle method of the camera controls, which allow zoom, but not "forward/back". I mean, unless what ever it is I want to look at is behind me, zooming won't do jack for me, even discounting the simple fact that zoom won't move along the same logical path that I would if I walked there, but will end up where ever the panning rotation sends it, which may be 50 meters in the air or 50 meters under ground, not just 50 meters directly behind me.

Third, Yes, I figured that is the case, but you seem to have missed what I said. I ***doesn't seem to matter*** if I use <0,1,0> or <1,0,0> or <0,0,1>, it always moves left and up, to position itself about 1 meter higher and to the left than it started, no matter "what" value I use, even some insane one like 50 or 100. I realize this may be do to how the coordinates are returned, but I am not sure how to get consistent data for the position of the *actual object* in term of the sim, or, having done so, actually get a displacement that is *in* the sim space, instead of local. If I could just get it to move in "some" direction other than jumping to where it does, then refusing to do anything else after, I would work out which "directions" I really needed it to move it in to get it where its supposed to be. But, hitting "forward" multiple times seems to do "nothing" at all. If doesn't move farther away, or anything else. It just jumps to that point, then doesn't move *ever*.

BTW... Forgive me, being as I have only spent years working with 3D applications for "designing" 3D raytracing scenes, where telling a camera to go to some specific place means it move "that many units to *that* location), but... why do you multiply the rotation of the object to the value? I see it done in the camera parameters, which never seem to update to the object, even after it moves, despite the timer (at least not while the keyboard is "locked", which is itself bloody dumb if you ask me), but.. in the systems I am used to, multiplying anything by rotation simply a) makes no sense and b) would produce invalid results. It would help if I understood what the heck multiplying that value to it did, and why.

This is your problem Since you're experienced in 3D I'll assume I can talk techy: Attached objects move in their own coordinate systems. Each attachment point has its own CS with the origin at the appropriate point on the avatar armature. Thus the exact positioning and orientation of these CSs are based on the locations of your avatar's limbs - and those are tracked only on the client. Since scripts are server-side there is no way for a script to translate between an attachment's CS and the world CS, since it is missing the limb positioning info and has no way to get it. Unfortunately, the camera functions assume you to enter the position and focus coordinates in the world CS.

If you want to do this with an attachment, you will need to move the camera without moving the object. You can do this, though.



Multiplying a vector by a rotation rotates the vector by that location. You're right, it doesn't make sense in mathematics - it's an overloaded function.

Hmm. Right.. So, what I need is a "camera follower", not a "follow object with camera"? But, this is probably "still" going to generate a pain in the rear situation when trying to translate the attachment to the camera position.. Starting to wonder what will happen if I just have an attachment that rezzes the object I want to move, but that probably can't "track" the camera either... Gah!! Any idea how camera followers work, since I know people do manage to make those. Frankly, it would be "much" easier of you had some way to just a) move things to sim coordinates, and b) move and rotate the camera to any arbitrary sim point, but apparently LL decided to make it **challenging**, which is to say, so buggy even when using it the way they intended, that it often doesn't work right in that context either. lol

You can do that, and it can track the camera with llGetCameraPos and llGetCameraRot.



You do have this, just not on attached objects. On a non-attached object llSetPos will do this.



llSetCameraParams does that, you just have to make sure that the points are in sim coordinates.

Ok, found data on that. Now.. How do you "preserve" the existing rotation of an object? The dang thing is a hollowed and dimpled sphere, and it has to be rotated a bit to "face" forward, so, when you rotate it to the camera angle, it fowls up the prim angles. Not so good at vector math apparently, so I have no clue how to fix it.



Yes, noticed.

In theory. A lot of people have had serious issues getting llSetCameraParams to work right though, apparently. Its not quite as "simple" as it should be.