LlCastRay discrepancies

[Raven Huntsman]

I've been using ray casts recently and noticed an annoying issue that I'm confused by. Namely, custom static mesh planes which do have collision, seem to be ignored by llCastRay. 

I tested this by first confirming proper physical interactions. By creating a prim cube (Object A), enabling physics and dropping it on top of a custom mesh plane (Plane A), and then a prim cube (Plane B) scaled down on the Z axis all the way to 0.100. In both cases, Object A collides with both planes as expected.

Next, I setup some touch logic in Object A, to cast a ray downwards and report the hits, placed over both planes at the same height/distance. Object A ray casting down onto Plane A reports nothing. Object A ray casting down onto Plane B reports a hit as expected.

Is this intended behaviour? I've confirmed this raycast failure inside mesh buildings where the floor is a flat plane, the avatar is colliding with the floor and able to stand on it, but raycasts dont report a hit.

[Fenix Eldritch]

Hard to say without more info... What are the actual llCastRay command parameters you're using? What is the physics shape type of the plane? And as a sanity check, what does the plane's physics shape look like? You can get a quick visual by going to Develop > Render Metadata > Physics shapes. You'll want to probably do this in the sky to reduce visual clutter from nearby objects.

Edited November 20, 2022 by Fenix Eldritch

[Wulfie Reanimator]

To see the object's physics shape, you can also select the object and click the little eye-icon in the Build Tools window, next to the physics type.

Edited November 20, 2022 by Wulfie Reanimator

[animats]

4 hours ago, Raven Huntsman said:

I've been using ray casts recently and noticed an annoying issue that I'm confused by. Namely, custom static mesh planes which do have collision, seem to be ignored by llCastRay. 

I tested this by first confirming proper physical interactions. By creating a prim cube (Object A), enabling physics and dropping it on top of a custom mesh plane (Plane A), and then a prim cube (Plane B) scaled down on the Z axis all the way to 0.100. In both cases, Object A collides with both planes as expected.

Next, I setup some touch logic in Object A, to cast a ray downwards and report the hits, placed over both planes at the same height/distance. Object A ray casting down onto Plane A reports nothing. Object A ray casting down onto Plane B reports a hit as expected.

Is this intended behaviour? I've confirmed this raycast failure inside mesh buildings where the floor is a flat plane, the avatar is colliding with the floor and able to stand on it, but raycasts dont report a hit.

Which direction are you casting the ray? Ray-casting only detects faces facing the ray cast.

Ray-casting is strange. I have some test tools. Set up your test case in world somewhere and let us know where we should visit.

[Extrude Ragu]

17 hours ago, Raven Huntsman said:

mesh planes

If the plane is 2 dimensional cast ray will fail for the same reason rezzing on a 2d plane fails. The raycast looks for when it is 'inside' the object, which it can never be unless the object has some depth.

[PheebyKatz]

Not sure what you're using raycasting for, but I find as far as registering a hit on mesh or prims that a sensor beam usually works quite well. Even a lot of combat systems that say they use raycasting are actually using sensor beams.

Anything I've ever considered using raycasting for, I ended up having better success with a sensor, and analyzing the detected object via filtering.

Even a flying prim might not register a collision with another prim. SL is a butt about these things sometimes.

If you're using it for something specific that only it can do, then hey, I hope you find a solution to make it go. Otherwise, maybe keep an open mind about other options. There's usually at least three ways to do anything, anyway.

Edited November 21, 2022 by PheebyKatz

[Wulfie Reanimator]

1 hour ago, Extrude Ragu said:

If the plane is 2 dimensional cast ray will fail for the same reason rezzing on a 2d plane fails. The raycast looks for when it is 'inside' the object, which it can never be unless the object has some depth.

Just to test this to be sure, I created a one-sided plane in Blender and used that as the physics model while raycasting against it. The ray won't hit the backside of the plane, but it will hit the "solid" side.

llCastRay works by doing a "line-triangle intersection" check against the physics model of objects in the ray's path. This generally involves calculating the normal of the triangle, and optionally ignoring backfaces (which llCastRay does).

 

19 hours ago, Raven Huntsman said:

Next, I setup some touch logic in Object A, to cast a ray downwards and report the hits, placed over both planes at the same height/distance. Object A ray casting down onto Plane A reports nothing. Object A ray casting down onto Plane B reports a hit as expected.

Is this intended behaviour? I've confirmed this raycast failure inside mesh buildings where the floor is a flat plane, the avatar is colliding with the floor and able to stand on it, but raycasts dont report a hit.

Could you share the script you used? Just so we can confirm it's nothing simple like trying to call llCastRay(llGetPos(),<0,0,-5>,[]) for a downward ray. Also make sure that the status code is actually zero instead of one of the error values.

Ruling out all the sane cases... I recall @Fenix Eldritch and @animats investigating a particular object whose physics shape seemed to be "full of holes" despite the physics shape being solid (as in it was totally random whether a raycast would hit it, even when the position was adjusted by a fraction of a fraction). Could that be happening here?

Edited November 21, 2022 by Wulfie Reanimator

[PheebyKatz]

Actually, if it's a mesh floor in a building, even if the avatar can stand on it, that might be the whole issue. A lot of larger uploaded mesh things, particularly larger flat planes, actually DO sort of have holes in them, of a sort. Even if you upload them with proper physics, physics model, etc.

It might not be the raycast that's the problem at all. Hmm.

Now I'm actually interested in this. If you find the answer, please share it.

[Fenix Eldritch]

Down the rabbit hole we go!

I also created a test plane in Blender and uploaded it with the following traits:

• highest LOD was the model (default Blender 2x2 meter plane: 4 verts, 2 tris, no UV)
• all other LODs used "use LoD above"
• physics shape used high LOD, did not analyze or do anything else
• rezzed plane is using PRIM physics type (and I scaled the size down slightly to better fit in my raytracer scene)

I then sat it down in front of my in-world raytracer and performed some visibility tests. The raytracer can "render" what is sees in terms of physics shapes. Colors for the backdrop walls and floor are hard-coded, but anything else in the viewfinder has a random color based on uuid. The grey prim in the background registers as a mirror when rendered. My avatar is also in the frame for reference (it appears as a purple coffin-shaped thingy). The raytracer shoots 1 primary ray into the scene and then shoots a secondary ray from the point of impact to the light source to determine shadows. Both rays have a maximum hit count of 1.

 

Picture 1: the plane is facing the raytracer's camera (highlighted by me in edit mode). I would have expected the plane to render as a solid color. The speckled dark spots you see on it are a known issue. Basically, the ray did in fact hit the plane's surface, but the secondary ray that tries to rebound to the light source got interrupted, so the raytracer thinks that point is under shadow and shades it as such. I've seen this occur on torus and sphere prims under certain conditions. See BUG-202695. This seems to be a problem specific to my use case, but the important part is that the primary ray did in fact hit the plane at all points sampled.

 

Picture 2: Oh... what? Those previously shadowed points are gone and now a lot of rays are shooting through the plane entirely and hitting the scene's backdrop behind it. What changed? The "thickness" of the object. Notice the Z component of the size in the edit tool: I reduced it to the minimum 0.010m. For some reason, this is now allowing many of the rays to punch clean through.

 

Picture 3: Same as #2, but rotated the object 180 degrees to have the backface pointing towards the raytracer. Same results as #2.

 

Picture 4: Repeating test#1 (front facing the raytracer's camera, default prim "thickness" as 0.75m) but with the physics shape type now set to convex hull. Now THIS is what I would have expected for all the other tests: a clean render with all rays hitting the surface and rebounding to the light source. 

For the sake of brevity, I'll skip the rest of the pictures and just report that repeating the other tests but with convex hull produced the same results: when the prim thickness (z size) was reduced to 0.010, some of the rays would manage to punch through the plane.

Now this was with the physics model being the high LOD itself without any other options like analyzing, converting to hulls, or simplifying in the uploader. Sooooo....

Re-uploading the same plane, setting physics to highest LOD and analyzing using solid method, normal quality, no smooth and checking the close holes box (not that close holes should matter in this case). The results shown by the analyzer report Triangles: 2, Vertices: N/A, Hulls: N/A. (which were the same as the original plane I uploaded too). Interesting to note that the simplification section was greyed out at all times - perhaps this model is too simple?

All tests using this model produced identical results as with the first model - except the new plane rendered in a stylish red color.

Here's the older thread Wulfie referenced. And if anyone wants to experiment, I've left my raytracer rezzed in my workshop - see profile for slurl.

Edited November 21, 2022 by Fenix Eldritch
typos