llCastRay a problem in 0.8.2.0

[Kayaker Magic]

Now that the Holidaze are over, I went back to do some more testing of llCastRay.
I found that (apparently) Panthalassa reverted to V1 of llCastray.
I'd like to test V3 some more and see if I can get it to crash on demand (so I can submit a Mantis!)
Could you please switch Panthalassa to V3 llCastRay again?
Might be wise to try it on a single region as well, can you set my "Test Bed" world to V3 llCastRay also?

[Kayaker Magic]

Hi Kayaker,

I changed your worlds to use llCastRay v3 again.

[Kayaker Magic]

I changed your worlds to use llCastRay v3 again.

When I go to submit mantises, what do I say so they know I am reporting problems in V3 of castray?
Is there a line in the INI file I should put in the mantis so they will know what version I am testing?

I'm already tripping over several other bugs, so there will be several mantises. For example, the LL Wiki is unclear if a llCastRay will "see" the prim the script is in. It is unclear if a llCastRay with the starting point inside a prim will "see" it on the way out. My experimentation in the past indicated that llCastRay would not detect these two cases. But it turns out I was always casting from phantom objects. Now that V3 llCastRay detects phantom objects (when I tell it not to with RC_DETECT_PHANTOM,FALSE) this is causing it to detect the prim the script is in. (That in turn is causing one of my cannons to explode and destroy itself! Another cannonball just explodes as soon as it leaves the barrel.) I'll have to go back to SL and do some tests to get a baseline of what is "supposed" to happen in some of these cases.

[Oren Hurvitz]

Just tell them that you're using llCastRay v3. The INI option that enables it is:

UseLlCastRayV3 = true

[Kayaker Magic]

Testing the V3 llCastRay on Panthalassa.
V3 has very nice low times! I never saw it take more than 3ms to run, averaging closer to 2ms and often less than that! Better than InWorldz with PhysX, better than SL!

This turned out to be a false positive. V3 is correctly throttling too many calls and returning RCERR_CAST_TIME_EXCEEDED. I wasn't checking for this (V1 never returns it) and the average time was going way down. When I take llCastRay out of a for loop, call it only once every event, once every 100ms seconds and start checking for RCERR_CAST_TIME_EXCEEDED, I get an average time of around 12ms. This is still quite good.

I'm also finding that llCastRay V3 DOES NOT detect a prim that surrounds the starting location... so why is my cannon exploding when I start inside? Perhaps because the prim with the script in it was a child prim? More testing is needed but I have chores and errands in RL to do. I will get back to this tomorrow. I still don't know enough to submit a mantis yet. Good testing is so hard to do!

[Kayaker Magic]

I have been doing testing on llCastRay V3 and submitting Mantuses. One for the failure to ignore phantom prims and one for the resolution to my cannonball issue:

It turns out that llCastRay V3 works correctly if cast from the middle of a box, but if you cast from inside a sphere it incorrectly detects the sphere on the way out. This caused my cannonballs to hit themselves and EXPLODE! I fixed the problem by replacing the sphere with a mesh sphere and my cannon now work perfectly again. But it should work with a sphere, so I submitted a mantis about this.

On a 1x1 region without many prims, when casting short distances (4 meters) llCastRay V3 is BLINDINGLY FAST! Returning in less than 1ms. When this is the default version of llCastRay there are going to be 1000's of uses for this! For example, I have a vehicle with independent suspension on all 6 wheels (or 4 or however many you want). I use llCastRay to tell about where the road prims are and have all the wheels rise and fall independently as you bump over prims or the terrain.

On Var Regions with many prims, llCastRay V3 is a little slower (typically 11ms) but this is quite fast enough for most applications. I still need to do some testing on vars, quantify the results a bit and probably submit some mantuses about this.

I've been doing a lot of testing on a 1x1 and have never seen the runnaway CPU and crash that llCastRay caused before. Perhaps this only happens on vars and I will find a way to make it happen on demand in a var.

[Kayaker Magic]

I found out that there is yet a third version of llCastRay on the Horizon! Perhaps someone will get it right!
At the recent OpenSim Dev Open House meeting I learned that if you selected ubODE as your physics engine (only available in OpenSim 0.9.0.0) it has its own version of llCastRay which uses the model built by the physics engine. This is the way everyone says llCastRay should be done! I have a few regions on OSgrid running 0.9.0.0 so I am testing this version now!

When you first call llCastRay, the results look good:
This version of llCastRay does have an accurate model of the world, it can see past the edges of rotated prims (V1 cannot)
The ubODE version of llCastRay can see through phantom prims when asked to ignore phantom (V3 could not).
It ignores child prims marked as prim type NONE whem asked to ignore phantom (neither V1 or V3 could do this).
But then the honeymoon is over:
It seems to be fast at first, but if you use it a lot is slows down. (Are they punishing me for overusing it?)
Pointing llCastRay at some objects seems fast (the ground, single prims) but feels slow when pointed at avatars or linked prims.
When I call llCastRay from a moving object the first few calls are fast, but after that they get very slow.
After calling llCastRay a bunch of times, my OpenSim server crashed with a SIGABRT message. Most of my console log was lost.
All these tests were done in a 3x3 var region, I have to test again with a 1x1 and see if it is just the old V1 bug coming back.
I need to do more testing to get hard data for this and submit a Mantis.
Good testing is hard to do.