Prim Face Maps

OK I have been trying to tackle the issue of buttons for interaction for quite some time now...

The main problem is: making lots of buttons uses up a lot of primitives. It also forces you to write scripts for each of the buttons, manage links, etc.

I think it would be cool if we could make the equivelant of HTML image maps on primitives, so that the area you click is a coordinate of the prim with a defined response per coordinate area. Ideally, you could do it for any axis on the prim, but to start one side would be good.

Imagine...

You have a single prim in the shape of a rectangle with an image of a menu on it. You click a particular area of the prim and it responds as if you selected something, much like an HTML image map.

You could take this a step further and allow interaction on any of the primitive's sides.

--Jack Lambert

Honestly? I want something like this to interact with imported Flash. There's presently a bug that does, but... real support would be nice.

I was just talking about this with someone the other night.

We know we have the X,Y,Z of a face that we're touching / grabbing - because the particles from our hand go to the point we touch, not the center of the prim.

If these coordinates were made usable, it would be an effective solution to the post's suggestion.

The X,Y could be added to the touch(integer number) event... make it:
touch(integer number, float x, float y)

Actually, a new function like llDetectedSide( integer side ) ( or vector pos ) would probably be a better way to go about it, since changing the touch event would break untold numbers of scripts.

Not to mention that if you added the X/Y to touch, you would effectively make it so that only one touch can be accurately handled per touch call. As it stands now, the number passed in is the number of touches, each potentially would have their own X/Y. A new Detected function would make the most sense for both backwards compatibility and being able to handle multiple touches per event.

McW

I cant remember who it was but I think it was Darwin that had mentioned this once a long time ago. At the time I think the explination was based on how prims each have polygonal faces thus a Cube would only have 6 polygon faces and no where to "Assign" a hot spot for picking like Html.

Other prims would have oddly formed Polygon structures that would have available areas but imagine creating a list of applicable prim faces to assign a hot spot to.

Dont get me wrong just representing issues brought up before. Personally I would love this as it would reduce my vendors prim counts dramaticly.

Anyway.. hope y'all find out soon.

Shadow

llDetectSide would work for flat cubes with small tops. we could at least have three buttons available per prim.

it would also allow us to rotate control prims to perform different functions for various configurations.

llDetectedTouchPos(integer  number, integer face, vector pos)

Number being which touch was made, Face being which face of the prim was touched, and pos 
being the x and y position touched on face. 

Note: the Z axis will be unused in pos.

Would be a nice function eh?

~Talila

That would be lovely! As a side note, that gives me an idea to use vectors as multidimensional bitfield arrays.

--Jack Lambert

I would love to see a solution like this implemented. Great idea Talila!

McW

Ah yes, knew I was forgetting to post this somewhere:

default
{
    state_entry()
    {
        llSetStatus(STATUS_BLOCK_GRAB,TRUE);
    }
    touch_start(integer total_number)
    {
        list spawns = [];
        
        vector start = llDetectedPos(0);
        vector height = llGetAgentSize(llDetectedKey(0));
        start += (<0,0,0.85 * height.z> / 2); 
        vector diff = llRot2Fwd(llDetectedRot(0));
        
        vector mypos = llGetPos();
        rotation myrot = llGetRot();
        vector size = llGetScale();
        size /= 2;
        
        // Unrotate our vectors...
        diff /= myrot;
        start = mypos + ((start - mypos) / myrot); 
        
        if(diff.x == 0) diff.x = 0.01;
        if(diff.y == 0) diff.y = 0.01;
        if(diff.z == 0) diff.z = 0.01;
        
        vector zero_x = start + ((mypos.x - start.x) * diff / diff.x) - mypos;        // When X = 0
        vector zero_y = start + ((mypos.y - start.y) * diff / diff.y) - mypos;        // When Y = 0
        vector zero_z = start + ((mypos.z - start.z) * diff / diff.z) - mypos;        // When Z = 0 
        
        vector temp;
        // Plane: Face 0
        temp = zero_z + (size.z * diff / diff.z);
        if(llSqrt(llPow(temp.x,2)) <= size.x && llSqrt(llPow(temp.y,2)) <= size.y)
        {
            spawns += temp;
            spawns += 0;
        }
        
        
        // Plane: Face 1
        temp = zero_y - (size.y * diff / diff.y);
        if(llSqrt(llPow(temp.x,2)) <= size.x && llSqrt(llPow(temp.z,2)) <= size.z)
        {
            spawns += temp;
            spawns += 1;
        }
            
        // Plane: Face 2
        temp = zero_x + (size.x * diff / diff.x);
        if(llSqrt(llPow(temp.y,2)) <= size.y && llSqrt(llPow(temp.z,2)) <= size.z)
        {
            spawns += temp;
            spawns += 2;
        }
            
        // Plane: Face 3
        temp = zero_y + (size.y * diff / diff.y);
        if(llSqrt(llPow(temp.x,2)) <= size.x && llSqrt(llPow(temp.z,2)) <= size.z)
        {
            spawns += temp;
            spawns += 3;
        }
            
        // Plane: Face 4
        temp = zero_x - (size.x * diff / diff.x);
        if(llSqrt(llPow(temp.y,2)) <= size.y && llSqrt(llPow(temp.z,2)) <= size.z)
        {
            spawns += temp;
            spawns += 4;
        }
            
        // Plane: Face 5
        temp = zero_z - (size.z * diff / diff.z);
        if(llSqrt(llPow(temp.x,2)) <= size.x && llSqrt(llPow(temp.y,2)) <= size.y)
        {
            spawns += temp;
            spawns += 5;
        }
            
        integer i;
        integer count = llGetListLength(spawns);
        
            
        count = llGetListLength(spawns);
        for(i = 0; i < count; i += 2)
        {
            temp = llList2Vector(spawns,i);
            temp = <temp.x / size.x,temp.y / size.y, temp.z / size.z>;
            
            llSay(0,"Intersection at Face " + (string)llList2Integer(spawns,i + 1) + " at " + (string)temp);
        }
    }
}

This script will return a local position on the face(s) of a cube (or the rotated bounding box of a prim) at any rotation, position, and scale of said cube.

You can then just use this data to "fire a bullet" at the prim, if it's an arbitrary prim type, to get touch data for any location.

To clarify, that information isn't actually transferred to the server. If I edit an object, I will see the particles going to the point I clicked, but everyone else will see them going to the object's origin point. I know you probably know this, it's just a misconception a lot of people seem to have, that it's a simple matter for the Lindens to do a copy-paste job on an existing function and changing where it gets its input.

That said, it's still obviously something we need. Perhaps the Lindens could be convinced to commit to adding XML markup to produce textures as well this for 1.7?

Actually, Catherine, Quicktime supports (at least rudimentary) XML, which we tested the other day.

I haven't checked anything more advanced than a few text operations, but it's food for thought.

I proposed Prop 621 for this feature. Would really love to see something like this implemented. Could really reduce prim usage in a number of scripted objects, and seems even more critical with HUD on the way.

I like the name llDetectedTouchPos, but I am not sure how useful an <x, y, z> vector would be (even with the face number).
I would consider having the function return a single vector in the form <u, v, face>.
Specifically, u and v are values from 0.0 to 1.0 and are the texture-space co-ordinates on the touched face.
This should be easier for the client to determine, as it has to do these calculations to draw the textures anyway - and easier for scripters, as the u and v values are easy to map to the x and y of the texture on the face. Also, prims such as a boxes with small tops, which shear the texture, will shear the "touch co-ordinates" in exactly the same way. u and v are also not affected by resizing the object. They are affected by changing texture repeat values, but so is the visual appearance of the buttons, so as with shearing, the click co-ordinates are always transformed in the same way as the visual elements.

For the time being, the above code I posted (six months ago) seems to do exactly what is being proposed. The only thing that really needs correction for is the head position of a given avatar.

Which would make a nice function in and of itself. The ability to get the height of the viewing position of a given avatar would make so many things easier, including this.

Alas.

Heh I just posted a request for a llDetectedSide function on the linden forums, for ideas and suggestions, only just noticed this thread.

I agree it would be really handy, I make games on SL and it's very hard to keep prims down, especially when you have large grid areas, and it does present problems for people with low prim limits, but anyway hope my post there well help slightly, if not then at least I tried , i did mention also having it detect the x,y location on the side as well.

All I really need for my games is detecting the side being clicked, don't really need the x,y thing, at least not for now, might need it when I start working on a sci-fi battle simulator , well anyway, I'll let you know what the lindens reply to the post.