(tekkies) raycasting function

a new lsl function wich trace an imaginary ray originating from a global coordinate X along a vector Y with a maximum length Z

llRaySensor(vector start,vector direction,float max_length,integer die_on_collision)

once processed it would return a sensor event with a maximum of 16 objects it crossed if die_on_collision is set to false, and the first object it crossed if set to true.

it would fill the gap between the current sensors and volumedetect.

could be usefull for all sort of things, like robot pathfinding (they could see if there is something blocking them), game systems that wouldn't kill the physic engine, etc...

That would be a really good tool. Right now the way you fake this is you rez a small temporary prim and fire it along the path, and use a collision event in the prim. Being able to do it without impacting the physics engine more than minimally would be great.

Unfortunately, LL seems reluctant to implement any new "sensor" style functions because of the overhead on teh sim of storing all the snapshotted info for the sensor until it's used. They've said that they're looking at some new API to enumerate all objects on a parcel. This is useful for landowners, but not so good for artificial life and robotics.

I would suggest changing the call to only return the information on the first prim intersected, and an option to have it detect or ignore phantom prims. That would avoid the overhead.

I would like that, but we can't ever get something as simple as a set of type-checking functions (is_integer, is_float, is_key, etc), min/max functions, etc. Simple little functions which would take precious little developer time to implement.

I have a feeling that very little is going to be done with LSL until after the Mono version is implemented.

well if i remember raycasting in the game industry work on the physical side, but it has a much lower signature than firing a full "object prim" since it only pass through things.

There's two kinds of functions in LSL, there's ones that are completelyinternal and are part of the "language", and ones that are almost completely external and are part of the Second Life simulator. Changes to the LSL language itself are stalled. But they're continuing to add new capabilities to the SL simulator and (of course) providing LSL interfaces to them.

In this case, this isn't a change to LSL... for LSL it's just another entry in the built-in symbol table, the underlying functionality would be the same whether you're calling it from Mono or the existing LSL bytecodes.

Well, yes, calculating intercepts on a line is a lot cheaper than performing physicas calculations on a physical object for dozens of frames.

I didn't mean that the "guide bullet" was a *good* replacement for the suggested function, just that if you have an immediate need for this kind of thing you could use that as a workaround.

Another possibility, while not fantastic, is to actually do the line intercept calulations in LSL.

In one of my products, I wished to determine if a target was blocking my sword strike, and did not want them to be able to block if they were facing away, so I wrote a quick function that calculated a plane from the avatar's current location and direction, and tested my position to see if it was on the positive halfspace of that plane, like this:

 	vector p1 = pos + <0,1,0> * dir;
 	vector p2 = pos + <0,0,1> * dir;
 	vector normal = llVecNorm( (p2 - p1) % (pos - p1) );
 	vector dv = llVecNorm( target - pos );
 	float test = normal * dv;
 
 	return (test > 0);
 

Such a test makes use of a sensor sweep first, as a broad-phase detection that then iterates through the list of returned avatars and fed the llDetectedRot() and llDetectedPos() to the above calculation.

I should think that it would be possible to do something similar for a short range ray intersection with the bounding box of anything returned by your broad-phase sensor sweep.

Did that make any sense? If not, sorry, I have a headache the size of Texas and am trying to explain through the haze of pain

BAH! Nevermind the above post, since the OP was really looking for something with the precision of a ray/polygon intersection test, at best it could be used for an early-out test to determine whether to fire a physical projectile, but until we get Mono (and dramatically increased LSL perf as a result) it would be too slow to be practical in most cases.

That sort of thing works for avatars or other things with a detectable and/or fairly constant shape, but unfortunately not for linked objects, where the bounding box returned by LSL is for the whole object rather than individual prims (which can obviously include lots of empty space). If one is in an environment composed of unlinked boxes it could work, but one rarely is....

edit: above post made during intervening time noted and appreciated

oh i already tried in lsl it is waaay too slow to be useable

a true function sould like the only way to go in my opinion

1. llSensor() only returns the 16 closest objects.
2. llSensor() only gets you the bounding box of the objects it *does* find.
3. llSensor() gets you the bounding box of the *object*, not the prims.

llSensor inside any linked building will simply tell you that you're inside the bounding box of the building.

soo what would be needed to get this function implemented?

A miracle of computer science that means that raycasting isn't computationally slow and expensive.

it isn't draco look at any modern fps game , and even not so moder they all use ray casting for their bullets

You're mixing up two different uses of the word raycasting. I think. Or maybe three.

There's the old computer graphics technique of "radiosity", that's so expensive it makes raytracing look fast, where you calculate the illumination of the entire scene light-by-light, recursively, then raytrace the result.

There's the gaming technique of doing one raycasting pass to figure out where shadows are.

Then there's just tracing a single ray on request, which is about as expensive as doing a render of a 1pixel by 1pixel window in the screen, and could be handled by a typical 1989 laser printer in Postscript fast enough to be useful.

This is what I'm aware of being talked about and what I'm talking about. A single ray is not very expensive, no, but compaired to other functions they are. Calling the llRay() fuction repeatedly would bog down the system very quickly. For it to be useful for game design, it is typically called EVERY FRAME (or, 30 times a second). "how close am I? how close am I? how close am I? ok, collisison. how close am I?"
If we go, ok, that's a little much, we're talking SL here, I'll only call it once a second. Then, yes a single script might not do much damage, but the cumulative effect of several of these objects would be a drain on system resources.

And it's not the same as rendering a 1x1 pixel. Ever heard of Z-depth? The farthest polygones get drawn first (in completeness), the the next ones up, then the next ones up until the nearest one gets drawn on top. Things have been optimized since then, but it's still not a raycast to see what that pixel has.
And if you're raycasting to a point, you're looking for EVERYTHING in the ray's path, so it might not be "rendering the one pixel once" but a list of everything in the Z-depth of that pixel and their distance or location from the ray's origin.

BTW, the raytracing that is done for if your avatar is standing or falling is a 1-ray that is done serverside. How can you tell? You pop through the ground for a half-second as the client keeps up where it thinks your avatar is based on last known position and velocity and then resyncs with the server. The CLIENT doesn't even to ONE raytrace to keep you from shooting into the ground.
Or better yet, you're walking and lose connectivity, your avatar continues in known direction, passing through the ground as the client isn't smart enough to do the raytrace itself.

Um, the alternative is to rez a probe, llSetForce it so it doesn't fall, and llApplyImpulse it along the path... and there's robots that do this repeatedly to "feel" their way along a path. This function would significantly *reduce* the overhead on the sim.
Even if someone wantedto use it that way in second life script execution is simply not real-time enough to do that. You wouldn't be able to use llRay() that way, and you wouldn't want to... SL provides physics algorithms that integrate the effects of thousands of intersection algorithms a second. You only need this kind of thing when you're trying to do something (like planning a path for an AI) that's off the beaten track. Like you don't build a plane by doing real-time flight calculations and calling llApplyImpulse over and over again, you use the vehicle code, unless you're making a really oddball kind of plane.
In this case you'd do the nearest ones first, because you're looking for the closest intercept.

It's been proposed before . It also goes by other names, such as "picking".

never heard of "picking" before, and what was the conclusion?

thing is its about one of the most basic function you find in any 3D SDK, would be worth to implement

I'm sure I've mentioned it to Lindens since my last post on this thread. I think its overall effect would be to make scripting *more* efficient, since at the moment we have all these daft workarounds that must be used.

oh i mentioned it to them, it has been a so long time since they really made a big addition ot the scripting toolset

that's all? nobody else think that this would totally benefit SL?

Of course it would, seems pretty obvious to me I just don't think saying so will in any way influence the LL devs to actually implement it.