Difference between revisions of "LlCastRay"

From Second Life Wiki
Jump to navigation Jump to search
m (lowercase in lsl)
m
Line 15: Line 15:
|p1_type=vector|p1_name=start|p1_desc=starting location  
|p1_type=vector|p1_name=start|p1_desc=starting location  
|p2_type=vector|p2_name=end|p2_desc=ending location  
|p2_type=vector|p2_name=end|p2_desc=ending location  
|p3_type=list|p3_name=options|p3_desc=Consists of one or more [[#options|option flag]] and it's parameters.
|p3_type=list|p3_name=options|p3_desc=can consists of any number of [[#options|option flag]]s and their parameters.
|constants=
|constants
|caveats=*Depending upon the value of '''{{LSL Param|flags}}''' (provided to [[RC_DATA_FLAGS]]), the number of values in the returned valued will vary in length, type and meaning! See [[#RC_DATA_FLAGS_flags|RC_DATA_FLAGS flags]] for details.
|spec=
===={{LSL Param|status_code}}====
 
{{LSL Param|status_code}} is a number tacked onto the end of the strided list to give you extra information about the ray cast. If the cast succeeded, it will be >=0 and will indicate the number of hits. If the ray cast failed (which should only happen right now if the simulator performance is running low), you'll get a negative status code. [[RCERR_SIM_PERF_LOW]] will be used as the status code if the overall physics time in the simulator is too high to perform raycasts. The idea is that you will know to try your cast again in a few frames.
 
<table class="lltable" border="1" id="error_code">
<caption>'''status_code''' error codes and their meanings.</caption>
<tr>
<th>Status Code</th>
<th>Value</th>
<th>Description</th>
</tr>
<tr><td>[[RCERR_UNKNOWN]]</td><td></td><td>The raycast failed for an unspecified reason. Please submit a bug report.</td></tr>
<tr><td>[[RCERR_SIM_PERF_LOW]]</td><td></td><td>The raycast failed because simulator performance is low. Wait a while and then try again. If possible reduce the scene complexity.</td></tr>
<tr><td>[[RCERR_CAST_TIME_EXCEEDED]]</td><td></td><td>The raycast failed because the parcel or agent has exceeded the maximum time allowed for raycasting. This resource pool is continually replenished, so waiting a few frames and retrying is likely to succeed.</td></tr>
</table>
 
=====[[RCERR_CAST_TIME_EXCEEDED]]=====
Ray casts are throttled by the amount of time actually taken to perform the cast. Each region is allotted a 2ms pool, divided proportionally over parcels the same way prim limits are. Each agent is allotted 50us. All scripts in attachments and, objects on which an avatar is seated, use the agent pool whereas all scripts use the parcel pool. A ray cast can be performed if at least 30us of raycast time remain in the appropriate pool. If there is insufficient time remaining, [[RCERR_CAST_TIME_EXCEEDED]] is returned as the status code. The exact time used by the ray cast is measured when it is performed and that number (in microseconds) is subtracted from the pool. (The time remaining can be a negative number.) Over time, the pool is automatically replenished (at a rate of 25% of the max time per frame).
 
For example, if you start out with 100us and perform a 50us raycast, 50us will be remain. If you then a 70us raycast during the same frame, you will have -20us remaining. Subsequent calls to llCastRay that frame will fail with status code [[RCERR_CAST_TIME_EXCEEDED]]. At the start of the next frame, you will have 5us available (25us are restored each frame) and any attempt to call llCastRay will again fail as you need 30us to execute a raycast. One frame after that, 30us will be available and a raycast can once again be performed.
 
This method of throttling puts the scripter "closer to the machine". That is, you're only being charged for what you use, and more efficient raycast techniques will automatically be charged less than less efficient ones. The exact throttle values are subject to change at any time before release to the main grid.
 
'''Tips for Efficient Raycasts:'''
*Keep the max number of hits returned as small as possible
*Set as many [[RC_REJECT_TYPES]] as possible (of factors you can control, this will likely have the largest impact). For example, if you only want to know where the nearest agent is along a ray, use <code>[[RC_REJECT_LAND]] {{!}} [[RC_REJECT_PHYSICAL]] {{!}} [[RC_REJECT_NONPHYSICAL]]</code>
*When possible, avoid raycasting through piles of prims and avoid raycasting against concave physics objects (anything with cut, hollow, twist, and so on, and any mesh object that has no decomposition and has physics type "prim"). Obviously this can't always be avoided, so some casts may take significantly longer than others. Plan for that with robust scripts that handle [[RCERR_CAST_TIME_EXCEEDED]] responsibly, namely by sleeping briefly after the call and waiting for a few frames to go by before trying again.
 
==== {{LSL Param|options}} parameter ====
 
<table class=lltable border=1 id="options">
<table class=lltable border=1 id="options">
<caption>'''{{LSL Param|options}}''' flags and their parameters</caption>
<caption>'''{{LSL Param|options}}''' flags and their parameters</caption>
Line 46: Line 78:
</tr>
</tr>
</table>
</table>
<table class="lltable" border="1" id="error_code">
<caption>'''status_code''' values and their meanings.</caption>
<tr>
<th>Status Code</th>
<th>Description</th>
</tr>
<tr><td>[[RCERR_UNKNOWN]]</td><td>The raycast failed for an unspecified reason. Please submit a bug report.</td></tr>
<tr><td>[[RCERR_SIM_PERF_LOW]]</td><td>The raycast failed because simulator performance is low. Wait a while and then try again. If possible reduce the scene complexity.</td></tr>
<tr><td>[[RCERR_CAST_TIME_EXCEEDED]]</td><td>The raycast failed because the parcel or agent has exceeded the maximum time allowed for raycasting. This resource pool is continually replenished, so waiting a few frames and retrying is likely to succeed.</td></tr>
</table>
|caveats=
===={{LSL Param|status_code}}====
{{LSL Param|status_code}} is a number tacked onto the end of the strided list to give you extra information about the ray cast. If the cast succeeded, it will be &gt;=0 and will indicate the number of hits. If the ray cast failed (which should only happen right now if the simulator performance is running low), you'll get a negative status code. [[RCERR_SIM_PERF_LOW]] will be used as the status code if the overall physics time in the simulator is too high to perform raycasts. The idea is that you will know to try your cast again in a few frames.
====[[RCERR_CAST_TIME_EXCEEDED]]====
Ray casts are throttled by the amount of time actually taken to perform the cast. Each region is allotted a 2ms pool, divided proportionally over parcels the same way prim limits are. Each agent is allotted 50us. All scripts in attachments and, objects on which an avatar is seated, use the agent pool whereas all scripts use the parcel pool. A ray cast can be performed if at least 30us of raycast time remain in the appropriate pool. If there is insufficient time remaining, [[RCERR_CAST_TIME_EXCEEDED]] is returned as the status code. The exact time used by the ray cast is measured when it is performed and that number (in microseconds) is subtracted from the pool. (The time remaining can be a negative number.) Over time, the pool is automatically replenished (at a rate of 25% of the max time per frame).
For example, if you start out with 100us and perform a 50us raycast, 50us will be remain. If you then a 70us raycast during the same frame, you will have -20us remaining. Subsequent calls to llCastRay that frame will fail with status code [[RCERR_CAST_TIME_EXCEEDED]]. At the start of the next frame, you will have 5us available (25us are restored each frame) and any attempt to call llCastRay will again fail as you need 30us to execute a raycast. One frame after that, 30us will be available and a raycast can once again be performed.
This method of throttling puts the scripter "closer to the machine". That is, you're only being charged for what you use, and more efficient raycast techniques will automatically be charged less than less efficient ones. The exact throttle values are subject to change at any time before release to the main grid.
'''Tips for Efficient Raycasts:'''
*Keep the max number of hits returned as small as possible
*Set as many [[RC_REJECT_TYPES]] as possible (of factors you can control, this will likely have the largest impact). For example, if you only want to know where the nearest agent is along a ray, use <code>[[RC_REJECT_LAND]] {{!}} [[RC_REJECT_PHYSICAL]] {{!}} [[RC_REJECT_NONPHYSICAL]]</code>
*When possible, avoid raycasting through piles of prims and avoid raycasting against concave physics objects (anything with cut, hollow, twist, and so on, and any mesh object that has no decomposition and has physics type "prim"). Obviously this can't always be avoided, so some casts may take significantly longer than others. Plan for that with robust scripts that handle [[RCERR_CAST_TIME_EXCEEDED]] responsibly, namely by sleeping briefly after the call and waiting for a few frames to go by before trying again.


====[[RC_REJECT_TYPES]] {{LSL Param|filter}}====
=====[[RC_REJECT_TYPES]]=====


'''{{LSL Param|filter}}''' is a bitwise-or combination of the following constants: [[RC_REJECT_AGENTS]], [[RC_REJECT_PHYSICAL]], [[RC_REJECT_NONPHYSICAL]], and [[RC_REJECT_LAND]] except that if you select all four of them, a script runtime error will be generated (it makes no sense to cast a ray and reject everything!). Note that phantom and volume detect objects are never returned and that seated agents are treated like unseated agents. I.e., you either get seated and unseated agents in your results, or you use [[RC_REJECT_AGENTS]] and get neither. Using 0 as the filter value will return all hits.
'''{{LSL Param|filter}}''' is a bitwise-or combination of the following constants: [[RC_REJECT_AGENTS]], [[RC_REJECT_PHYSICAL]], [[RC_REJECT_NONPHYSICAL]], and [[RC_REJECT_LAND]] except that if you select all four of them, a script runtime error will be generated (it makes no sense to cast a ray and reject everything!). Note that phantom and volume detect objects are never returned and that seated agents are treated like unseated agents. I.e., you either get seated and unseated agents in your results, or you use [[RC_REJECT_AGENTS]] and get neither. Using 0 as the filter value will return all hits.


====[[RC_DATA_FLAGS]] {{LSL Param|flags}}====
=====[[RC_DATA_FLAGS]]=====


'''{{LSL Param|flags}}''' is a bitwise-or combination of: [[RC_GET_NORMAL]], [[RC_GET_ROOT_KEY]], and [[RC_GET_LINK_NUM]]. These select whether you want link numbers and hit normals in your results list. By default, you will get the UUID ('key') of the exact child prim hit. If instead you want the key of the root prim, set [[RC_GET_ROOT_KEY]]. A terrain hit will register as [[NULL_KEY]].
'''{{LSL Param|flags}}''' is a bitwise-or combination of: [[RC_GET_NORMAL]], [[RC_GET_ROOT_KEY]], and [[RC_GET_LINK_NUM]]. These select whether you want link numbers and hit normals in your results list. By default, you will get the UUID ('key') of the exact child prim hit. If instead you want the key of the root prim, set [[RC_GET_ROOT_KEY]]. A terrain hit will register as [[NULL_KEY]].

Revision as of 15:47, 30 August 2011

Summary

Function: list llCastRay( vector start, vector end, list options );

Cast a ray from start to end and report collision data for intersections with objects
Returns a list of strided values with an additional integer status_code on the end. Each stride consists of two mandatory values {key uuid, vector position} and possibly some optional values {integer link_number, vector normal} see #RC_DATA_FLAGS_flags for details. The status_code if it is negative is an error code, otherwise it is the number of hits (and strides) returned.

• vector start starting location
• vector end ending location
• list options can consists of any number of option flags and their parameters.

Specification

status_code

status_code is a number tacked onto the end of the strided list to give you extra information about the ray cast. If the cast succeeded, it will be >=0 and will indicate the number of hits. If the ray cast failed (which should only happen right now if the simulator performance is running low), you'll get a negative status code. RCERR_SIM_PERF_LOW will be used as the status code if the overall physics time in the simulator is too high to perform raycasts. The idea is that you will know to try your cast again in a few frames.

status_code error codes and their meanings.
Status Code Value Description
RCERR_UNKNOWNThe raycast failed for an unspecified reason. Please submit a bug report.
RCERR_SIM_PERF_LOWThe raycast failed because simulator performance is low. Wait a while and then try again. If possible reduce the scene complexity.
RCERR_CAST_TIME_EXCEEDEDThe raycast failed because the parcel or agent has exceeded the maximum time allowed for raycasting. This resource pool is continually replenished, so waiting a few frames and retrying is likely to succeed.
RCERR_CAST_TIME_EXCEEDED

Ray casts are throttled by the amount of time actually taken to perform the cast. Each region is allotted a 2ms pool, divided proportionally over parcels the same way prim limits are. Each agent is allotted 50us. All scripts in attachments and, objects on which an avatar is seated, use the agent pool whereas all scripts use the parcel pool. A ray cast can be performed if at least 30us of raycast time remain in the appropriate pool. If there is insufficient time remaining, RCERR_CAST_TIME_EXCEEDED is returned as the status code. The exact time used by the ray cast is measured when it is performed and that number (in microseconds) is subtracted from the pool. (The time remaining can be a negative number.) Over time, the pool is automatically replenished (at a rate of 25% of the max time per frame).

For example, if you start out with 100us and perform a 50us raycast, 50us will be remain. If you then a 70us raycast during the same frame, you will have -20us remaining. Subsequent calls to llCastRay that frame will fail with status code RCERR_CAST_TIME_EXCEEDED. At the start of the next frame, you will have 5us available (25us are restored each frame) and any attempt to call llCastRay will again fail as you need 30us to execute a raycast. One frame after that, 30us will be available and a raycast can once again be performed.

This method of throttling puts the scripter "closer to the machine". That is, you're only being charged for what you use, and more efficient raycast techniques will automatically be charged less than less efficient ones. The exact throttle values are subject to change at any time before release to the main grid.

Tips for Efficient Raycasts:

  • Keep the max number of hits returned as small as possible
  • Set as many RC_REJECT_TYPES as possible (of factors you can control, this will likely have the largest impact). For example, if you only want to know where the nearest agent is along a ray, use RC_REJECT_LAND | RC_REJECT_PHYSICAL | RC_REJECT_NONPHYSICAL
  • When possible, avoid raycasting through piles of prims and avoid raycasting against concave physics objects (anything with cut, hollow, twist, and so on, and any mesh object that has no decomposition and has physics type "prim"). Obviously this can't always be avoided, so some casts may take significantly longer than others. Plan for that with robust scripts that handle RCERR_CAST_TIME_EXCEEDED responsibly, namely by sleeping briefly after the call and waiting for a few frames to go by before trying again.

options parameter

options flags and their parameters
Flag Parameters Default Value Description
RC_REJECT_TYPES ] integer filter ] [ 0 ] Mask used to ignore specific types of objects (and avatars).
RC_DATA_FLAGS ] integer flags ] [ 0 ] Described in the RC_DATA_FLAGS flags section.
RC_MAX_HITS ] integer max_hits ] [ 1 ] Maximum number of hits to return. Maximum value is 256. To avoid performance issues, keep it small.
RC_DETECT_PHANTOM ] integer detect_phantom ] [ FALSE ] Set to TRUE (or nonzero) to detect phantom AND volume detect objects. It is not possible to detect only phantom objects or only volume detect objects. If set to TRUE, phantom and volume detect objects will always be detected, even if RC_REJECT_NONPHYSICAL and RC_REJECT_PHYSICAL are set in RC_REJECT_TYPES.
RC_REJECT_TYPES

filter is a bitwise-or combination of the following constants: RC_REJECT_AGENTS, RC_REJECT_PHYSICAL, RC_REJECT_NONPHYSICAL, and RC_REJECT_LAND except that if you select all four of them, a script runtime error will be generated (it makes no sense to cast a ray and reject everything!). Note that phantom and volume detect objects are never returned and that seated agents are treated like unseated agents. I.e., you either get seated and unseated agents in your results, or you use RC_REJECT_AGENTS and get neither. Using 0 as the filter value will return all hits.

RC_DATA_FLAGS

flags is a bitwise-or combination of: RC_GET_NORMAL, RC_GET_ROOT_KEY, and RC_GET_LINK_NUM. These select whether you want link numbers and hit normals in your results list. By default, you will get the UUID ('key') of the exact child prim hit. If instead you want the key of the root prim, set RC_GET_ROOT_KEY. A terrain hit will register as NULL_KEY.

Caveats

  • Depending upon the value of flags (provided to RC_DATA_FLAGS), the number of values in the returned valued will vary in length, type and meaning! See RC_DATA_FLAGS flags for details.

Examples

<lsl> integer filter = 0;

default {

   state_entry()
   {
       llSay(0, "Hello, Avatar!");
   }
   touch_start(integer total_number)
   {
       vector start = llGetPos();
       vector end = start - <0,-25,0>;
       
       if ( filter > 8 )
       {
           filter = 0;
       }
       
       llOwnerSay("Filter " + (string)filter);
       list results = llCastRay(start, end, [RC_REJECT_TYPES, filter, RC_MAX_HITS, 4] );
       
       integer hitNum = 0;
       // Handle error conditions here by checking llList2Integer(results, -1) >= 0
       for ( hitNum = 0; hitNum < llList2Integer(results, -1); hitNum++ )
       {
           // Stride is 2 because we didn't request normals or link numbers
           key uuid = llList2Key(results, 2*hitNum);
           string name;
           if ( uuid == NULL_KEY )
           {
               name = "Land";
           }                
           else
           {
               name = llKey2Name(uuid);
           }
           llOwnerSay("Hit " + name);
       }
       
       filter += 1;
   }

}

</lsl>

Notes

Use llDumpList2String to see what the output looks like when you try a new set of flags.

Ideas for uses:

  • Weapons. Raycasts are the traditional tool used in game development for simulating projectile weapons. They are orders of magnitude more efficient than rezzing a prim and launching it from a weapon.
  • AI objects
  • A very slow, but kind of cool, ray tracer that could build an image of a sim by casting rays around and determining the color of the thing they hit and modifying a child prim in a display object to have that color...or something. I'd really love to see someone build something like this, actually.

Deep Notes

Signature

function list llCastRay( vector start, vector end, list options );