Controlling Camera Controls

[Frankie Rockett]

Hi
I have been trying to move my camera to the position of a separate drone I created and to move with the drone. It's largely based on a script someone gave in this forum, slightly modified for my own case. It works after a fashion but there are a couple of serious problems with it and I wonder if anyone can see the wood for the trees here?

First problem: I need it to work from a HUD and to toggle the remote view on and off on repeated clicking. In a HUD, this script doesn't work at all. In a nearby prim, rezzed on the ground nearby, it works as it should (meaning on, then off). However, even as a script in a rezzed prim, it stops working after one round of off and on. After that you need to reset it to get it going again. So - can this be made to work in a HUD and repeatedly so without having to reset/remove and re-add the HUD after each remote viewing?

Second problem: no matter how I tweak the parameters relating to where the camera IS and where the camera is POINTING, it's always essentially looking AT the drone. I want the camera to adopt a position as if it was the drone's camera - on the front and looking forward. Why am I never getting that view here?
Here's the code I have so far. Note, a separate script messages the drone and it replies with it's UUID - that's picked up by this script and so works as intended. Additional note; I added some lines relating to rotation in vein attempts to modify the default rotation into something I wanted.

 

key uuid = "";
integer listen_handle;

default
{
    on_rez(integer param)
    {   
        llResetScript();//By resetting the script on rez forces the listen to re-register.
    }
    
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_CONTROL_CAMERA);
        listen_handle = llListen(166, "", "llGetOwner()", "");
        llRegionSay(166, "UUIDRequest");
    }

    run_time_permissions(integer perm)
    {
        llSetTimerEvent(0.022);
    }

    timer()
    {
        // Get the remote object's position and rotation.
        list data = llGetObjectDetails(uuid, [OBJECT_POS, OBJECT_ROT]);
        vector pos = llList2Vector(data, 0);
        rotation rot = llList2Rot(data, 1);
        rotation rot90Z = llEuler2Rot(<0, 90, -270>*DEG_TO_RAD);
        rot = rot * rot90Z;

        llSetCameraParams([
            // Begin controlling the camera and prevent it from being moved.
            // (Alt-cam will still override this.)
            CAMERA_ACTIVE, TRUE,
            CAMERA_FOCUS_LOCKED, TRUE,
            CAMERA_POSITION_LOCKED, TRUE,

            CAMERA_FOCUS, pos,                           // The position the camera will LOOK at.
            CAMERA_POSITION, pos + (< -1.0, 0.1, -0.1> * rot)    // The position the camera will BE at.
        ]);
    }

    touch_start(integer n)
    {
        llClearCameraParams();
        llSetTimerEvent(0);
    }
    
    
     listen(integer channel, string name, key id, string msg)
    // Listens to and services all menu buttons.
    {
        if (channel == 166 && msg == "UUIDRequest-Back")
        {
            uuid = (key)id;
            llOwnerSay("Receiving UUID = " + (string)msg);
        }
    }
}

So - is it even possible to have camera controls in a HUD, and if so, how can I get them to behave as intended?

Thank you in advance.

 

[Lucia Nightfire]

SL does not have the capability to auto-follow anything other than the script wearer.

Anything else you will have to call llSetCameraParams() repeatedly.

We've asked for an auto-follow means for years.

[Frankie Rockett]

Hi Lucia. While I don't have the in-depth knowledge to counter your comment, I can tell you that this script does follow a drone (which in turn is following a nominated avatar).

Please see Wulfie Reanimator's post at the foot of this page - it's the source of my variation, and again, it works as described:

Also, as I said in my initial post, this will work in a nearby (unattached and un-worn) prim.

[Qie Niangao]

This isn't really a "follow cam", it's a cam control script that runs in the fastest possible timer, updating cam parameters as fast as the network can push them to the viewer. That can work, but it will never be the kind of smooth motion you get when the viewer follows an object on its own (the hypothetical "follow cam" script function).

Anyway, for starters, the llListen() call, as written, will only listen to an object with a key corresponding the the string "llGetOwner()" which cannot exist. If this ever worked (HUD or not) it did not use that line of code.

As written, it would only work once per rezzing, and stop on a touch. The touch_start handler simply stops it, with no toggle or anything to start again. Probably the simplest way to change that is with a global integer variable that gets toggled in the touch_start function. Toggling a boolean is often done with something like "camToggle = !camToggle" which assigns the opposite sense to the variable, and start or stop the timer correspondingly.

[Frankie Rockett]

Thank you Qie. That concise toggle tip is very valuable. I've been doing it the more plodding way, with if/then to alternate a toggle's value!

It sounds like I'm flogging a dead horse here. Yes the result was very choppy. I assumed that was because the drone itself had a choppy follow movement, but whatever the cause, it wasn't pleasant.
If I read you correctly then, there is no way I can smoothly displace my camera to that of the drone's point of view?

[Qie Niangao]

13 minutes ago, Frankie Rockett said:

If I read you correctly then, there is no way I can smoothly displace my camera to that of the drone's point of view?

Right, I don't think it's possible with current scripting functions. The best I've done is accurate enough but the motion is just too choppy for recording a satisfactory video, for example.

[Quistess Alpha]

You could check if some client side scripting magic can do stuff with the camera? Here's cool VL Viewer's Lua manual: sldev.free.fr/CoolVLViewerLuaManual.pdf

I'd check it and see, but my connection to France is quite spotty.

[Frankie Rockett]

Thank you Quistess for bringing that to my attention. On balance though, I'd like a solution that works with mainstream viewers, especially Firestorm, rather than the more obscure alternatives.

[Lucia Nightfire]

On 11/8/2022 at 10:21 AM, Frankie Rockett said:

Hi Lucia. While I don't have the in-depth knowledge to counter your comment, I can tell you that this script does follow a drone (which in turn is following a nominated avatar).

Please see Wulfie Reanimator's post at the foot of this page - it's the source of my variation, and again, it works as described:

Also, as I said in my initial post, this will work in a nearby (unattached and un-worn) prim.

That script is calling llSetCameraParams() every timer() event triggered every 0.022 seconds.

This is not auto-following.

Auto-following is when you call llSetCameraParams() only once and the camera smoothly follows the target without updating llSetCameraParams() again.

This is currently only possible with a worn script targeting the wearer and using the CAMERA_BEHINDNESS_ANGLE, CAMERA_BEHINDNESS_LAG and CAMERA_DISTANCE constants.

Edited November 9, 2022 by Lucia Nightfire

[Wulfie Reanimator]

To answer the main point of OP's request, here you go. I added a global variable called active near the top, and its value is toggled between true/false in the touch_start event. I also added a check for the UUID's value so the camera doesn't move to <0,0,0> if it's active before a target is set.

key uuid = "";

float timer_rate = 0.022;
integer active = TRUE;
integer listen_handle;

default
{
    on_rez(integer param)
    {
        llResetScript();//By resetting the script on rez forces the listen to re-register.
    }

    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_CONTROL_CAMERA);
        listen_handle = llListen(166, "", "", "");
        llRegionSay(166, "UUIDRequest");
    }

    run_time_permissions(integer perm)
    {
        if (active && uuid != "")
        {
            llSetTimerEvent(timer_rate);
        }
    }

    timer()
    {
        // Get the remote object's position and rotation.
        list data = llGetObjectDetails(uuid, [OBJECT_POS, OBJECT_ROT]);
        vector pos = llList2Vector(data, 0);
        rotation rot = llList2Rot(data, 1);
        rotation rot90Z = llEuler2Rot(<0, 90, -270>*DEG_TO_RAD);
        rot = rot * rot90Z;

        llSetCameraParams([
            // Begin controlling the camera and prevent it from being moved.
            // (Alt-cam will still override this.)
            CAMERA_ACTIVE, TRUE,
            CAMERA_FOCUS_LOCKED, TRUE,
            CAMERA_POSITION_LOCKED, TRUE,

            CAMERA_FOCUS, pos,                           // The position the camera will LOOK at.
            CAMERA_POSITION, pos + (< -1.0, 0.1, -0.1> * rot)    // The position the camera will BE at.
        ]);
    }

    touch_start(integer n)
    {
        active = !active;

        if (active && uuid != "")
        {
            llSetTimerEvent(timer_rate);
        }
        else
        {
            llClearCameraParams();
            llSetTimerEvent(0);
        }
    }

    listen(integer channel, string name, key id, string msg)
    // Listens to and services all menu buttons.
    {
        if (channel == 166 && msg == "UUIDRequest-Back")
        {
            uuid = (key)id;
            llOwnerSay("Receiving UUID = " + (string)msg);
        }
    }
}

I'm not sure why it would only work "in an object rezzed nearby" when the camera control function is restricted to only work in attachments or seats. It worked as a HUD even before I made any changes to the script.

P.S. I missed the second problem about the camera's position. The reason why the camera isn't acting as the drone's POV is because CAMERA_POSITION has an offset from the drone, and CAMERA_FOCUS has the drone's position. It should at least be the other way around, and the offset needs to be changed to a different direction.

Edited November 10, 2022 by Wulfie Reanimator

[Frankie Rockett]

Thank you Wulfie! Your help is immeasurably useful, as are the contributions from Lucia and others too. I ahve enough to return to the battle now, so Thank You All again!!