Jump to content
Rolig Loon

What does llDetectedTouchNormal point at?

Recommended Posts

Posted (edited)

This would seem to have an obvious answer, and I thought I knew, but now I'm not sure.  Here's a test script:

vector vSpinAxis;
float fHoldTime;

default
{
    touch_start(integer total_number)
    {
        vSpinAxis = llDetectedTouchNormal(0);   // Vector perpendicular to touched face
        llSay(0, (string)vSpinAxis);
        float now = llGetTime();
        if (now - fHoldTime < 0.3)      // User has double-clicked the test object
        {
            llResetScript();  //Returns object to its initial orientation
        }
        else    // User has single clicked the test object
        {
            llSetTimerEvent(0.32);
        }
        fHoldTime = now;    
    }
    
    touch_end(integer num)
    {
        llTargetOmega(ZERO_VECTOR,0.0,0.0); // Stop spinning
    }

    timer()
    {
        llSetTimerEvent(0.0);
        if (llGetTime()-fHoldTime > 0.3)
        {
             llTargetOmega(vSpinAxis,0.5,0.1);   // Start llTargetOmega
        }
    }
}

Drop it into a brand new cube prim and click/hold.  As long as you keep holding, it will keep spinning around the vector that is perpendicular to the face you are touching.  When you let go, it stops. Double click and the cube will pop back to its initial orientation.

So, here's the thing.....  llTargetOmega is supposed to be spinning the cube client side, so its real orientation doesn't change as far as the LL servers are concerned.  That's why resetting the script pops it back to the original orientation.  It never left there, really.  So....  if that's the case, why does vSpinAxis change if you try spinning the cube around one axis after another?  That is, If my cube is in its default orientation (face 1 pointed east, face 0 pointed up), then I would expect that when I click on face 0, it will always tell me that vSpinAxis is <0.0,0.0,1.0>.  But if click on another face and then on face 0 again, it doesn't.  llDetectedTouchNormal() seems to be returning the perpendicular to the face as we see it.  Why?  What am I missing?

Edited by Rolig Loon

Share this post


Link to post
Share on other sites

i had a play with the script.  From observing the behaviour, an explanation could be that the viewer is sending back to the server, rotation info from omega objects that are touched, and saved on the stack/heap for use by functions like llDetectedTouchedNormal

 

Share this post


Link to post
Share on other sites

Yeah, that's what it looks like to me too, but I didn't think that was possible.  You have to feed llTargetOmega a real vector to rotate around, but I can't think of a reliable way --- or even an unreliable way -- to grab a vector from an object that you only know about client-side.  It looks like that's just what this script does, though.  This could be handy to know about in some applications.

Share this post


Link to post
Share on other sites

it might be that the temporary stack entry is created in the first frame of llTargetOmega, and is only updated thereafter, if/when the viewer reports a touch, or on a new call to TargetOmega

Share this post


Link to post
Share on other sites

That's almost certainly true, since I am capturing vSpinAxis with touch_start and there is no other action in the script until you release the mouse button and trigger touch_end.  Notice, by the way, that llTargetOmega isn't spinning 100% reliably around that axis.  If you click the same face several times, you get slightly different results from llDetectedTouchNormal.  The axis is wobbling, or precessing, or something.  Still, the curious thing is that it's defined at all.  As I said, there are times that it would be very handy to be able to click on an animated object like this and know where your viewer thinks it is and which way it's pointed -- as opposed to where the servers know that it is.

Share this post


Link to post
Share on other sites
Posted (edited)
30 minutes ago, Rolig Loon said:

there are times that it would be very handy to be able to click on an animated object like this and know where your viewer thinks it is and which way it's pointed -- as opposed to where the servers know that it is.

yes.  I think that what you have shown here, opens up some good potentials

edit add: Now that you started me thinking about it, I add to the list of nice to haves:  llRequestRotOmega(). Even close enough would be good. Might be a bit slow as well due to the ping time of the client, so a request and not a get.  But I would still rather have to adjust for this, rather than not have it at all

 

Edited by Mollymews

Share this post


Link to post
Share on other sites
Posted (edited)

Taking some leaps in speculation that someone would need to verify with the viewer source code, but, clicking on anything in-world requires raycasting (not talking about llCastRay), and the viewer would then have to tell the server "I have touched this object on this face at this position." It's not a very big assumption to make that the viewer would include information about the rotation of the surface/object. So any client-side effects like that of llTargetOmega would affect what the viewer tells the server, resulting in this behavior.

Edited by Wulfie Reanimator
  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, Wulfie Reanimator said:

raycasting

Oh right. By analogy (and the worst UI ever) :

default
{
    state_entry()
    {
        llSetTexture("f16e2a6b-39b7-a4c9-0904-7b5ef84b56ad", ALL_SIDES);    // old Linden Homes house numbers
        llSetTextureAnim(ANIM_ON | LOOP, ALL_SIDES, 4, 4, 0.0, 16.0, 0.5);
    }

    touch_start(integer total_number)
    {
        vector uv = llDetectedTouchUV(0) * 4.0;
        llOwnerSay((string)(13 - 4*(integer)uv.y + (integer)uv.x));
    }
}

 

  • Thanks 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...