Which face did I click on?

I click on an object. I certainly know which prim got hit..

Can find out which face was clicked on?

(I'm writing a texture chooser for floors/windows/etc.. so far so good, but if I could get to the "face" level of detail, I'd smile a bit)

Unfortunately, no. You can 'guess' by getting their location on touch with llDetectedPos() in the touch() event handler, but no way to be certain if they've panned their camera around to another side.

Unless of course you were to track their camera too...

That might be interesting, try to determine which face they are looking at from their camera position/rotation.

Sounds like a pain though, good luck with that.

~Az

I think the main benefit of face-detection would be an ability to use a single prim, such as a XyText prim, for multiple functions. And in that instance, camera detection wouldn't be of use, since all faces are at nearly equal angles.

In this case, a two-click method might work (though I think MS has a patent on the idea). Basically, normal quick clicks toggle the 'active' face (via hilight maybe). A single, 2-3 second click/hold actually triggers the button's function. I already use the click/hold method in scripts to access back-panel control settings for my objects, so I know it works well in that case.

As the OP, I'll clue in a bit as to what I have in mind.. the overall
idea is to make it easy for purchasers of buildings to customize
them (if the customer wants to use their own textures for a building
they purchased, who am I to say no?!)

Right now, I have a demo object of some floors, walls, window, and
a ceiling... a controller prim has an inventory of textures and
a script... uses llLinkMessage to talk to the others. Works
wonderfully on an ALL_SIDES basis.

So I can click on any prim, and that sets the type of thing I want
to which I'll apply a texture. Just name each prim "floor", "ceiling_2", etc..
I can then use a dialog or chat commands to pick a texture. Groovy.
I can demo - ask me in-world

Wont ramble here (too late!) - question sprang from the desire
to control updates on a per-face basis. I can work around it
via chat or dialog inputs.

LL - if you ever return face info for a click, you may as well
throw in X,Y,Z coordinates

So that your customers don't have to deal too much with numbers, you should make sure that the prims are all rotated in a similar manner---for example, side 0 facing inside the house for walls, or side 0 being the floor side of a ceiling/floor prim. So they can do something like:

/12 wall inside texture rose
/12 wall outside texture brick

I started to do a texture changing house for a friend of mine, but quit working on it when I got to the part of making simple names for things... it gave me a headache

(OP) -- As it turns out, overloading the Name field for a prim is
a fun way to differentiate types.. and prims can easily
belong to different types .. if you know php or perl,
this works out to be "fun with split()"

easy: floor
- no faces specified - so that means ALL_SIDES

which faces?: floor=4,5
respond to different types?: wall+halfwall
which faces?: wall=0,1,2+halfwall=3,4

can I call something "EastsideExteriorWall"? sure.. knock yourself out.

In other words, on a per-prim basis, I can derive one or more types,
and assign faces to each type. When prims get an llLinkedMessage,
they can see if the texture being sent is meant for them.
The receiver script for each prim is generic.

And of course, we want to control alpha and color and other things

Will post it this weekend. IM for a demo (and if I dont respond,
send me a little notecard)

Let me return this to the original question. It was the story of faces on an prim. And let me introduce this idea.