Jump to content

What does llDetectedTouchNormal point at?


Rolig Loon
 Share

You are about to reply to a thread that has been inactive for 1745 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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
Link to comment
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

 

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
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
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1745 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...