Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007591opensim[REGION] Script Functionspublic2015-05-28 02:532015-07-30 11:20
Assigned Tonebadon 
PlatformPCOSWindowsOS VersionSeven
Product Versionmaster (dev code) 
Target VersionFixed in Versionmaster (dev code) 
Summary0007591: [SCRIPT] llCastray v3 bugs report
DescriptionThe new v3 llCastray seems not very well. We found that with nebadon the other day.

I tested with two scripts: the first is the lazer beam, script which worked well with llCastray v1. The 2nd is the wall walker. He never worked very well on opensim and I was full of hope for that one with the new v3 llCastray ... but the result is the same, the movement is very slow with v1 and v3 also. But with v3 there is a new problem, the avatar and prim are sent to the position 0, 0, 0, which is quite unusual. I put a demo video as an attachment and also the scripts to perform you the tested and hopefully make this work properly.

We all hope!
Additional InformationTests on my simulator (home server) and on Sisyphus (OSGrid).
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Environment.NET / Windows32
Mono VersionNone
ViewerFirestorm, Singularity
Attached Fileszip file icon [^] (1,462,525 bytes) 2015-05-28 02:57
patch file icon 0001-Improve-configuration-description-for-llCastRay-V3.patch [^] (1,870 bytes) 2015-05-29 10:16 [Show Content]
patch file icon 0001-Correct-constant-RCERR_CAST_TIME_EXCEEDED.patch [^] (1,099 bytes) 2015-05-30 05:38 [Show Content]

- Relationships

-  Notes
Magnuz (reporter)
2015-05-28 10:14
edited on: 2015-05-28 10:22

Thank you for testing. Unfortunately, both your scripts suffer the same flaws:

1. They don't handle the implemented throttling status code RCERR_CAST_TIME_EXCEEDED.
See SL Wiki [^] for explanation and example.

2. They depend on over-clocking the timer in a way that is not recommended in OpenSimulator, and even less so with a function so heavy even SL needs to throttle it.
See core developer Dahlia Trimble's post [^] for explanation.

Also, the linked wallwalker script doesn't even compile in OpenSimulator, neither on 0.8.1 release or 0.8.2 dev, using Firestorm or Singularity, owing to syntax errors, so I haven't been able to test it.

The first flaw is easy to fix by adding a simple check:
            list cast = llCastRay(...);
            if ( llList2Integer(cast, -1) == RCERR_CAST_TIME_EXCEEDED )
Note that you need to do this for each occurrence of llCastRay in the wallwalker script and use the list cast in the continuation of both the wallwalker and laser beam scripts.
This flaw is responsible for "resetting" the prims since the scripts try to read a non-existing vector and "gracefully" get the default ZERO_VECTOR instead then.

The second flaw is harder to handle, and it's possible the llCastRay V3 implementation isn't fast enough to handle e.g. the wallwalker without a thorough re-work of the LSL scripts, and perhaps not even then, depending on the server performance and region environment. You may simply need to wait until the OpenSimulator pros have implemented a physics engine based llCastRay if so.

Magnuz (reporter)
2015-05-29 10:17

Since there is no actual bug in the llCastRay V3 implementation reported, but rather a lack of information about what is required for and what can be expected from llCastRay V3, I'd suggest improving the description of it at the config switch enabling it:

Implements llCastRay similar but not identical to Second Life.
See [^] .
Meshes prims for good accuracy in ray hit detection,
handling basic and tortured prims, sculpts and meshes.
Uses ellipsoid, correctly sized avatar capsules.
Handles complex terrain, multi-prim objects and seated avatars.
Implements throttling and the status codes
so LSL scripts need to handle these responses and RCERR_SIM_PERF_LOW.
Can be faster on some servers and scenes, but slower on others,
compared to previous version of llCastRay in OpenSimulator.
Is in most cases considerably slower than llCastRay in Second Life.
Generates geometry meshes and can therefore use much system resources.

The submitted patch 0001-Improve-configuration-description-for-llCastRay-V3.patch updates the OpenSimDefaults.ini file with the above.
djphil (reporter)
2015-05-30 00:46

Ok, I have noted your comments and thank you.

Note that the two scripts provided are original's and both work very well as they are in SL (I mean without using RCERR_CAST_TIME_EXCEEDED).
This possibly suggest that SL provided a default value if RCERR_CAST_TIME_EXCEEDED is not used in the script.
djphil (reporter)
2015-05-30 01:13
edited on: 2015-05-30 01:17

I just tested by adding to RCERR_CAST_TIME_EXCEEDED lazer script but I do not see any change.
If I debug with llOwnerSay((string)llList2Integer (cast, -1)) I get the value 1 and normally the SL wiki say value for RCERR_CAST_TIME_EXCEEDED is -3
and if a debug with llOwnerSay((string)RCERR_CAST_TIME_EXCEEDED), i get valur 3 ... not -3

Magnuz (reporter)
2015-05-30 05:38
edited on: 2015-05-30 05:47


The two scripts you tested probably work well in Second Life because the implementation of llCastRay there is so fast the scripts never encounter the throttling. It is possible similar speed can be achieved in OpenSimulator using the physics engine, but I don't have the competence to try that. Vegaslon said it's on the list for BulletSim and has been partially started, but it may very well take months or years. Meanwhile, the V3 implementation at least improves accuracy quite a bit, until it can be replaced by a hopefully faster implementation.

The status code from llCastRay will be the number of hits (0-16), unless an error (-1), poor sim performance (-2, but not implemented yet) or throttling (-3) happens, so if you see the status code 1 on a single run, that is expected, since only consecutive runs may be throttled if the script has already exceeded the alotted cast time.

You did a good catch seeing the RCERR_CAST_TIME_EXCEEDED is wrong. I admit I never checked the actual value in OpenSimulator, but just compared to it. It should of course be -3 instead of 3. Actually, it may explain a few rare oddities I saw, if the number of hits happened to be 3 so my script discarded it as throttled when it shouldn't. I'm adding the patch 0001-Correct-constant-RCERR_CAST_TIME_EXCEEDED.patch to fix that. Thank you!

nebadon (administrator)
2015-06-01 10:33

patches are applied to git master [^] [^]
nebadon (administrator)
2015-06-01 12:20

I am setting this to feedback because I am also experiencing the failure with my test rig that I provided an IAR for, the lasers seem to not hit anything anymore. When i initially tested the patches, everything seemed to be working well, then all the sudden not sure why but they are failing completely I see them flickering a lot and they never seem to work correctly. [^]
nebadon (administrator)
2015-06-01 12:25

also the shape tests I created also fail when the lasers are going you can see here > [^]

however if i set scripts to not running on the lasers, the shape tests work again [^]

any ideas?
Magnuz (reporter)
2015-06-03 14:49

There are 3 issues here, 2 explained in the SL Wiki on llCastRay, and 1 in Mantis post 7547.

1. The lasers and the shape tests in Nebadon's test rig uses the same cast time pool, as explained in SL Wiki, the region pool, so when the lasers deplete it, the shape tests get throttled as well.

The throttling does not increase speed by 200%, but reduces load by 65% by dropping 2/3 of the calls, to try to stay within the alotted cast time. So, if trying to fire a single manual test, there is a 2/3 chance it will be throttled and hence "fail".

2. From [^] :
"To ensure robust results, be sure to check for RCERR_CAST_TIME_EXCEEDED and RCERR_SIM_PERF_LOW and sleep or do other work for a while before trying again." (OK, DON'T use llSleep in OpenSimulator, but the Wiki is written for SL, where it works.)

The scripts used to test still don't handle RCERR_CAST_TIME_EXCEEDED, so 2/3 of the attempted casts results in sending the ray prims or wallwalker 10 meters towards positions <0,0,0>. This causes "flickering" in the rays.

3. Poor calculation precision using singles (Mantis 7547) means that it will be random if the cast ray mathematically is starting before the rear end of the ray prim, exactly on the rear end, or after the rear end.

If the ray starts before the rear end of the ray prim, it should report a hit in the ray prim rear end, if exactly on the rear end, it's a matter of definition, and if after the rear end, it should not report a hit. In a static rig, this random result will be consistently repeated, while in a moving rig, it will change depending on positions and rotations. This was made consistent in favor of reporting hit, not to discard definite hits in some other corner cases, by increasing the calculation error tolerance (Mantis 7575).

Actually, the reshaping of the ray prim gives the result that every second call it will hit the rear end of the ray prim and appear to flicker off, since it shrinks to be hidden inside the ray caster, and every other second call, it will hit the intended target and appear to flicker on, since it extends outside the ray caster. However, this effect is not clearly visible until after fixing the status code handling.

Below is the laser script tidied up some and fixed to handle status codes and not hit its own ray prim:

        llLinkParticleSystem(2, [
                PSYS_PART_FOLLOW_SRC_MASK |
            PSYS_PART_MAX_AGE, 0.25,
            PSYS_PART_START_COLOR, <1.0,0.0,0.0>,
            PSYS_PART_END_COLOR, <1.0,0.0,0.0>,
            PSYS_PART_START_SCALE, <0.04,0.25,0.0>,
            PSYS_PART_END_SCALE, <0.04,0.25,0.0>,
            PSYS_SRC_BURST_RATE, 0.01,
            PSYS_SRC_ACCEL, <0.0,0.0,0.0>,
            PSYS_SRC_BURST_PART_COUNT, 10,
            PSYS_SRC_BURST_RADIUS, 0.01,
            PSYS_SRC_BURST_SPEED_MIN, 0.0,
            PSYS_SRC_BURST_SPEED_MAX, 2.0,
            PSYS_SRC_ANGLE_BEGIN, 0.0,
            PSYS_SRC_ANGLE_END, PI,
            PSYS_SRC_OMEGA, <0.0,0.0,0.0>,
            PSYS_SRC_MAX_AGE, 0.0,
            PSYS_SRC_TEXTURE, "",
            PSYS_PART_START_ALPHA, 0.7,
            PSYS_PART_END_ALPHA, 0.0
        vector position = llGetPos();
        vector direction = llRot2Fwd(llGetRot());
        vector rayStart = position + direction * 0.01; // avoid hitting ray prim end
        vector rayEnd = position + direction * 32.0;
        list cast = llCastRay(rayStart, rayEnd, [RC_MAX_HITS, 1]);
        if ( llList2Integer(cast, -1) < 1 )
            return; // discard zero hits and status codes
        float distance = llVecDist(position, llList2Vector(cast, 1));
        if ( distance > 32.0 )
            distance = 32.0;
        llSetLinkPrimitiveParamsFast(2, [PRIM_SIZE, <0.0,0.0,distance * 2.0>, PRIM_POSITION, <distance,0.0,0.0>]);
nebadon (administrator)
2015-06-03 16:39

ok that script does work a lot better, however when i have 12 of those lasers going, my blue box shape testers seem to fail a lot, you can see in this screenshot it fails 3 out of 5 times. [^]

I guess that is to be expected? anyway thanks for the updated script it does seem to work considerably better, hopefully in time we can resolve all of these issues with better implementations of Ray Casting.
Magnuz (reporter)
2015-06-03 23:11

60-65% calls throttled (or "failing") is expected behavior when the 12 lasers run with 0.05 s interval, and proves the throttling works as intended. 12 scripts running means 240 calls to llCastRay per second, and that requires about 2 full (180%) CPU threads with llCastRay V3 and the server performance we both seem to have. There are however a few things you can play around with:

1. If you sit down on (the blue box of) the shape tester, it's moved into the owner's personal cast time pool as a "vehicle", and not throttled by the lasers (in the region cast time pool) any longer.

2. Increasing the timer interval in the script to e.g. 0.1 (s) will decrease the throttling without impacting the visual performance much. In the static setup you could even use 0.5 or 1.0 (s) without visible impact, but in a dynamic setup, 0.1 (s) is about the minimum before visual appearance is affected too much.

3. Increasing AvailableTimeInMsPerRegionInLlCastRay and AvailableTimeInMsPerAvatarInLlCastRay in settings will permit more casts but at the cost of a higher CPU usage.

4. Setting ThrottleTimeInMsInLlCastRay in settings to a negative value, e.g. -1, will effectively disable throttling, but at the risk of overloading CPU and cripple server performance.
djphil (reporter)
2015-06-09 03:58
edited on: 2015-06-09 04:36

Hello, after installing the new OpenSim (Last OSGrid view), i tested yet llCastray

Here's what I found:
- The original script lazer not the same behavior with llCastRay v1 and v3 llCastray
Yet in SL 3 status_code are also implemented. This makes me think that in SL, if the status_code is not used in the LSL script, it is ignored or treated otherwise.

- I tested the values ??returned by the 3 status_code, they are good now. Thank you for that.

- I tested your lazer script:
- There is more movement back and forth endless as is the case with the original script used in OpenSim.
- There is a problem with your script. If the radius no obstacles in front of him (32m) radius remains at its position and do not change size. Normally if the ray does not encounter any obstacle he must become a length of 32m height and not stuck as is the case with your script.
I solved this problem by slightly modifying your script like this:
Replaced if (llList2Integer (cast, -1) <1)
By: if (llList2Integer (cast, -1) < 0)
Now the lazer has a size of 32m as defined in the LSL script when it encounters no object in front of him (32m).

- With the WallWalker script, I did not see any change, it still works very bad, very very slow. We further sum of a fluid movement as well in SL and I do not understand why there is this problem.

I hope that together we will find a solution, it would be good to see it run on OpenSim.

Magnuz (reporter)
2015-06-09 09:44


The laser script is flawed in more than one way, so if you want it working properly also in the case it's fired closer than 32 meters from region position <0,0,0>, you actually need to change the timer part further:

        vector position = llGetPos();
        vector direction = llRot2Fwd(llGetRot());
        vector rayStart = position + direction * 0.01; // avoid hitting ray prim end
        vector rayEnd = position + direction * 32.0;
        list cast = llCastRay(rayStart, rayEnd, [RC_MAX_HITS, 1]);
        integer status = llList2Integer(cast, -1);
        if ( status < 0 )
            return; // discard status codes
        float distance = 32.0; // ray prim length if no intersection
        if ( status > 0 )
            distance = llVecDist(position, llList2Vector(cast, 1));
        llSetLinkPrimitiveParamsFast(2, [PRIM_SIZE, <0.0,0.0,distance * 2.0>, PRIM_POSITION, <distance,0.0,0.0>]);

About the wallwalker script, it was already explained above. If you want it working in OpenSimulator, you either need to adapt it to manage on 60 ray casts per second instead of up to 400, or wait until there is a physics engine based llCastRay which can manage 400+ ray casts per second.
nebadon (administrator)
2015-06-09 09:46

I believe this mantis is about as resolved as it is going to get!
djphil (reporter)
2015-07-30 11:20

llCastRay V3 is more accurate, thank you for this beautiful work :)

- Issue History
Date Modified Username Field Change
2015-05-28 02:53 djphil New Issue
2015-05-28 02:57 djphil File Added:
2015-05-28 08:47 djphil Description Updated View Revisions
2015-05-28 10:14 Magnuz Note Added: 0028480
2015-05-28 10:22 Magnuz Note Edited: 0028480 View Revisions
2015-05-29 10:16 Magnuz File Added: 0001-Improve-configuration-description-for-llCastRay-V3.patch
2015-05-29 10:17 Magnuz Note Added: 0028490
2015-05-29 10:17 Magnuz Status new => patch included
2015-05-30 00:46 djphil Note Added: 0028497
2015-05-30 01:13 djphil Note Added: 0028498
2015-05-30 01:13 djphil Note Edited: 0028498 View Revisions
2015-05-30 01:17 djphil Note Edited: 0028498 View Revisions
2015-05-30 05:38 Magnuz Note Added: 0028501
2015-05-30 05:38 Magnuz File Added: 0001-Correct-constant-RCERR_CAST_TIME_EXCEEDED.patch
2015-05-30 05:47 Magnuz Note Edited: 0028501 View Revisions
2015-06-01 10:33 nebadon Note Added: 0028515
2015-06-01 10:33 nebadon Status patch included => resolved
2015-06-01 10:33 nebadon Resolution open => fixed
2015-06-01 10:33 nebadon Assigned To => nebadon
2015-06-01 12:20 nebadon Note Added: 0028518
2015-06-01 12:20 nebadon Status resolved => feedback
2015-06-01 12:20 nebadon Resolution fixed => reopened
2015-06-01 12:25 nebadon Note Added: 0028519
2015-06-03 14:49 Magnuz Note Added: 0028563
2015-06-03 16:39 nebadon Note Added: 0028566
2015-06-03 23:11 Magnuz Note Added: 0028568
2015-06-09 03:58 djphil Note Added: 0028644
2015-06-09 03:58 djphil Status feedback => assigned
2015-06-09 04:36 djphil Note Edited: 0028644 View Revisions
2015-06-09 09:44 Magnuz Note Added: 0028650
2015-06-09 09:46 nebadon Note Added: 0028651
2015-06-09 09:46 nebadon Status assigned => resolved
2015-06-09 09:46 nebadon Resolution reopened => fixed
2015-07-30 11:20 djphil Note Added: 0029029
2015-07-30 11:20 djphil Status resolved => closed
2015-07-30 11:20 djphil Fixed in Version => master (dev code)

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker