A challange :)

To some people this may be simple, but try as I might I have found this to be the source of 1 headache after another.


The scean:


One object is hit by another.

Now, detecting collisions is easy. However, what I need to detect is not where each object IS, what I need to find is the coordinates (and angle) of the exact point of contact.

Example: If object one, and object two are moving towards the same point at different angles, when they HIT each other, at what point does the one shell, touch another?

So, if I have something hit an object, I want to be able to rez a "marker" at the point of contact, so that it looks like the object was actually hit.

As to what you want to do, you might try changing the collision particles. There's a call to do that, if you browse the LSL wikis a bit. For calculating the point of contact, that's not by any means trivial for generic objects. Impossible, in fact, without having information about both of them, though you could probably guess reasonable positions.

If you DO have information about the geometry of each object, and particularly if they are simple prims, then it is possible. The more complex the objects, the more involved the computations. The run-time order of magnitude is going to be O(N*M) where N and M are the number of prims in the two objects. And if the prims are twisted/cut/hollowed, etc., even a simple prim collision calculation becomes pretty messy. You don't want to duplicate the whole physics engine in a (set of) LSL scripts, trust me!

You could probably compute the point of collision of the objects' bounding boxes pretty easily though....

Except that the data that one gets when collision_start() triggers is quite frequently not appropriate. Say one is trying to find the position of intersection between bounding boxes - that is going to involve llGetPos and llGetRot as well as the bounding boxes and llDetectedPos and Rot. But collision_start() often only triggers after the object has bounced off whatever it has hit and is facing backwards, so llGetRot is not at all reliable, and llGetPos is only approximately so.

I would advise Ms Margetts to find some other way of achieving whatever goal she has, here.

COuld you find the bounding box of each, then, at exact point of collision, find the location of each, and use that in conjunction with sizes to find the point of collision?

No, because you can't accurately find the position and rotation of the objects at the time of collision. You could be getting results from before or after any bouncing that takes place.

One can get an _approximate_ point, but, well, unless the objects are oddly-shaped, you might as well not bother with bounding boxes and that sort of rubbish and just take the mean position between the two objects.

here si something that might be intresting, i did this script real quick, it is good for shields and stuff, if anything comes near you atall it will rez a object to block it, it detects the pos of that object and spawns it right infront of the moving object

default
{
    collision_start(integer c)
    {
        if(llVecDist(llGetPos(),llDetectedPos(0)) < 10)
        {
            llRezObject("Object",llDetectedPos(0),ZERO_VECTOR,llDetectedRot(0),0);    
        }
    }
    collision_end(integer c)
    {
        llSay(500,"die");
    }
}

it may not be exally what you wonted but it could help in the conversation a bit

The intent, is to be able to rez a prim (leave a mark) on an the object that gets hit. But it has to be on the object (not up to 2-3 meters after the projectile ricochets off of it)

I don't have any idea whether its possible for an object to guess its own position at the time of collision, but it may not be impossible for it to find out the position of the other object when it collided...

The detected positions in the collision_start event are always a point *before* the collision happened. If you divide the object's speed by 45 you know how many meters it travels each time the physics engine ticks. The llDetectedPos of the object will be at one of those positions, skipping some of them (depending on performance?), but if you start from the detected position and step ahead (speed/45 at a time) you'll eventually get to the actual position at which it collided.

But the geometry crap sounds about impossible