Talk:LlCastRay

llSonar please?

I would appreciate if you took in consideration my suggestions at http://jira.secondlife.com/browse/SVC-2486 please; any feedback is more than welcome.

ps:llCastRay is already awesome, you rock! Please try the hardest you can to figure out how to get this to come to the maingrid with the least crippling as possible.

--TigroSpottystripes Katsu 03:01, 3 July 2010 (UTC)

Hi Tigro,

If I understand your feature request, it sounds much like the shape cast described in SVC-5381 (http://jira.secondlife.com/browse/SVC-5381) for a sphere or a cylinder cast along its primary axis. Is that correct?

Thanks, Falcon Linden

I have just skimmed thru the comments there, do shape casting allow for somthing liek for example have a nonphys object recognize the geometry so it could rest against a jumbled pile of prims as if it was laying against them physicly? (in the ASCII art in SVC-2486 it would be having the object represented by the O's resting in the diagonal line as if it was solid) --TigroSpottystripes Katsu 05:44, 3 July 2010 (UTC)

What am I looking at?

A function I just threw in to replace phantom bullets for quickly acquiring a point of interest -- whatever your camera's focused on (in this sim, within 20m) is returned, allowing quicker, more intuitive targeting of other objects. PERMISSION_TRACK_CAMERA must be previously set.

<lsl>key camPing() {

   // End points at the camera and 20m in front of it
   vector camPos = llGetCameraPos();
   vector endPos = camPos + ( <20.0, 0., 0.> * llGetCameraRot() );

   // Clamp the end position to within the sim
   // Except what I originally posted was wrong, and I'm too tired to do trig

   // Cast the ray; ignore hits on land, otherwise get the root key
   list contacts = llCastRay( camPos, endPos, 
       RC_REJECT_LAND,
       RC_GET_ROOT_KEY );

   // Return values
   if ( llList2Integer( contacts, -1 ) > 0 ) { // Got a return
       return llList2Key( contacts, 0 );
   }
   return NULL_KEY;

} </lsl>

Jack Abraham 04:42, 3 July 2010 (UTC)

RC_GET_LINK_NUM? Not RC_GET_LINK_KEY?

I can't think of a circumstance where knowing the link number of the return would be useful. UUID of the prim hit would be far more useful; is that within the realm of possibility? Jack Abraham 04:47, 3 July 2010 (UTC)

Hi Jack,

The default behavior is to return the UUID of the prim hit. If you want the root key instead, you have to use RC_GET_ROOT_KEY. The intended purpose of RC_GET_LINK_NUM was for scripts like your camera targeting system where it is expected that the camera will be pointed at a child of the linkset performing the cast. For example, suppose you make a minesweeper game where each tile is a prim in the linkset. And suppose you script it so that the use can select a tile by focusing on it and clicking. The script could cast a ray from the camera and determine the link number of the tile in the player's line of sight. Then it could use that link number in an llMessageLinked or some other LSL function to modify the appropriate child prim. Does that make sense? If it turns out no one has any use for RC_GET_LINK_NUM, I'll eliminate it for the sake of simplicity. But the behavior you're looking for is already there by default! Yay.

Cheers, Falcon Linden

Makes perfect sense; I need to read better. Thanks. Jack Abraham 05:44, 3 July 2010 (UTC)

Memory concerns

Dumping all possible avaible information into a list regardless of whether any of them will be used seems severely wasteful. If you really need to dump all the info as soon as the command is called straight into script memory, at least do somthing like adding a parameter to the command that is a list where each item identifies which pieces of information the scripter wants (like with llGetPrimtiveParams ) --TigroSpottystripes Katsu 05:51, 3 July 2010 (UTC)

I think we basically have that, Tigro; we only get UUID and hit position unless we set additional flags. Falcon indicated that we will not get all hits in the final version; that'll further reduce the size of the list. Jack Abraham 07:50, 3 July 2010 (UTC)

Clamping

It would be a waste of server resources if every script has to add clamping code to make sure their begin and end are inside the region! Instead, do not return an error code but just stop and return only the hits inside the region. That might mean you have to add the clamping code in the server, but that would be a hell of a lot more efficient than doing that in the LSL scripts.

Note that clamping is relatively easy, in C++ it shouldn't cost more than a few microseconds. The algorithm would be something like:

1) A bounding box can be given with two vectors: bbmin and bbmax, where bbmin is the bottom, south/west corner of the sim (0,0,0), and bbmax the upper, north/east corner of the sim (256,256,4096).

2) Let the ray begin at vector begin and end at vector end (using the same coordinate system as the bounding box).

3) Calculate bbmine = bbmin - end, and bbmaxe = bbmax - end. Check if end is outside the sim, so clamping is needed at all, by checking that at least one coordinate in bbmine is positive or one coordinate in bbmaxe is negative (set 'clamping_needed').

4) Shift coordinates so that begin becomes the origin and end becomes the direction (bbmin -= begin; bbmax -= begin; dir = end - begin). Lets call end dir from now on.

5) Check that bbmin has three negative coordinates and bbmax has three positive coordinates. If not then begin is outside the bounding box (if the signs are correct, except there are one or more zeroes, it's on the border and you can just return begin). Not sure if you should return an error code or return just no results. Finally, if begin is outside the bounding box, but end was inside, you might want to clamp begin instead of end. Lets assume that begin is inside the bounding box for now. If end was also inside it, then no clamping is needed and we stop here.

6) Clamping is needed. Calculate dir.x / bbmin.x, dir.x / bbmax.x, dir.y / bbmin.y, dir.y / bbmax.y, dir.z / bbmin.z and dir.z / bbmax.z.

7) Find the largest value 'max' of those six and return begin + dir / max as the collision point of the ray in the direction dir.

As you can see, this is a very fast routine. Still, I think it should be added to the server side. I didn't add code in order to avoid any license problems ;)

Aleric Inglewood 12:00, 3 July 2010 (UTC)

Actually, using SSE2, clamping would take just a few cpu instructions. It's not a question of efficiency for me, it's a question of future compatibility. Since we don't have script versioning for LSL, if we later add the ability to cast rays between sims or change the size of a region, existing scripts will break. I've been thinking of adding a version parameter to this function in order to deal with that possibility, in which case I could clamp in native code.

Cheers Falcon Linden 17:20, 3 July 2010 (UTC)

return also types casted

since filters RC_REJECT_AGENTS, RC_REJECT_PHYSICAL, RC_REJECT_NONPHYSICAL, and RC_REJECT_LAND are used, and therefore detected, it would be handy if in the results returned, the status AGENT, NON_PHYSICAL, PHYSICAL and LAND would also be returned. Is it douable ? --

I've been thinking about that. Either I'll somehow include the type in the list of returned data (perhaps only if you add the flag RC_GET_TYPE or something) or else modify llGetObjectDetails to return the data. You'll definitely have access one way or the other. Regarding land, though, you can definitively identify that because it will return null UUID.

Falcon Linden 17:20, 3 July 2010 (UTC)

Meep

Heya Falcon, really would absolutely love to have an llCastRay function in production.

I saw you had a concern of versioning issues. To overcome that, I heavily recommend using a list as an input, as that would be far more flexible on the kind of parameters and options you can push through rather than fooling yourself into using a hardcoded structure of llCastRay(vector start, vector end, other stuff) etc. A bit like how llSetPrimitiveParams works basically. For example in the past, LL upgraded the prim type interface from legacy to a more advanced and flexible set of input (torii, tubes and rings, yey), they could do this easily because a list was used as a parameter in the function, instead of having to expend resources on adding more functions, bloating LSL and causing legacy issues.

I also have a question, when you cast a ray and it hits an avatar, that hits the avatars' actual sphere-ish phys mesh, correct?

I have actually experimented personally with LSL and my custom client with a prototype LSL Script API, I could offload raycast processing into nearby clients easily and even built a half-working hexapod spider that can walk on a prim landscape, as well as all the fun raycasting combat gun stuff :). So, I have some serious experience to share in this field and having the raycasts locally processed would be really useful in a more timely manner (rather than suffering the delays of network lag).

What are your thoughts on the kind of filtering? Whitelist versus Blacklist? Whitelists are apparently more effective based on desire. (llSensors, llListen, ..)

--Nexii Malthus 02:10, 4 July 2010 (UTC)