Bullet Holes (and other collission rezzing)

Okay let's say I have a gun, and the gun shoots a bullet. On collission with an object, or land, I want to rez a "bullet hole".

Basically just a flat prim. But I want to get it so that this reasonably small prim lays retty close to flat" against the surface it is being rezzed on. Basically I want to detect the contur of the surface that It's being rezzed against, and then set the rez rotation to match.

Since these are going to be bullets, I can't guarantee that they're going to always be hitting cubes that are not rotated.

So, can anyone help?

To do that, you would need to be able to get the primitive params of the prims in the collided object, and do math to figure out where and how to orient the "hole". Since you can't get that from LSL (no way to get primitive params of other objects outside of pos and rot), I don't see a way to do it.

I'm sure you could do something bizarre by reversing along the bullet's path, rezzing a much slower projectile, and moving along the same path, turning visible when you collide again, but that method is fraught with a lot of problems probably not making it feasible either.

Basically, with what we have in LSL now, it doesn't appear to be possible or, at least, feasible to do.

You can also get the bounding box information in LSL, so if shooting at cuboid objects you could do pretty well at positioning the bullet hole.

Yes, for cuboids it would be perfectly possible, with llDetectedRot and the bounding box. Spheres, cut and hollowed cylinders, though... if only there was an llDetectedPrimitiveParams function.

You could have the bullet start a long life particle system when it collides and dies, that way the bullet can derez and a bullet hole image can remain for some time...

or you could convert the bullet into it's own bullet hole. no additional rezzing needed.

As to the orientation problem, you could use the position, bounding box, rotation and direction of travel info to guess the shape of the object.

The thing is, I've seen this done. Insides of hollowed spheres and everything.

Hmm. You could turn the bullet non-physical at the point of collision, and then possibly use relatively slow physical movement (either from the bullet or rezzed helper objects) to explore more precisely for the impact surface....

Also, probably a small black sphere would work okay in most cases. If it is on a surface, it might be hard to view from the side; if viewed from out of the plane of the surface, it'll have a circular profile like a hole.

I was actually spending some time thinking about this, and I think if I shot a halfsphere, with a flat face, on impact the prim would turn to face the surface. A split second later I could have the prim either go-non-phys and become a bullethope, or have it rez a bullethole and die.

Need to spend some time testing that.

So far the tests have proven really kind of meh.

Yes - this is the only thing that I was able to think of. On collision_start, rez a slow-moving physical prim behind the bullet, and have it continue on the bullet's original path. When it hits, then you can activate the effect. But you won't be able to detect the exact face angle.

If there's something which is reliably generating aligned bullet hole textures on the inside of hollowed spheres and cut toruses, it's either using some sort of cunning particle effect to do so, or there's something that I am missing here.

rezz a flat cube at the location of the bullet, have it filter the bullet being the first thing it collides with, then have that cube 'look at' the prim that the bullet collided with, and have it move towards it until it collides with it.

bullets can be anywhere from half a meter long to a meter long.

don't care enough to test this out myself though.

__________

and isn't there a collison sprite thingy, though I've never looked at it.

If you look at a hollow sphere after colliding with the inside, you will be looking in the wrong direction.

any though on using a minimal particle system? have the bullet hole image be the particle texture have leaving all velocities at 0, leaving life for about 5 seconds. life span of 5 seconds. since particles are client side you will be able to see the hole from any direction you look at it. and with only a 5 second life. it will not lag too much, unless you make 200 of them...

I think the same issue exists with particles as with an object. You wouldn't want it floating ten centimeters (or whatever) away from the surface. But maybe it is an acceptable issue, depending on the typical velocities and such. Probably needs to be tested.

If you did want to find the precise object surface from the point of collision, it might take doing a quick little random walk with the bullet, or rezzing a few finder objects in different directions. Worth it? Eh. Wouldn't really be to me, but you be the judge.

Oh. Also, once you determine the "collision point", you may also want to think about what to do if the object that was hit moves. You could record the relative position (in the hit object's coordinate system) and try to maintain that, but it may be a little hokey.

Think of this also in terms of it's applications as a "graffitti" tagging system, or a portal generator, We're talking about the same thing regardless.. Flat prim on impacted surface.

NO, a particle won't work, neither will a black sphere.

I'm looking specifically for a way to rez a flat object against a surface. Obviously it's being done.

If it is being done, why not ask the person who is doing it for some clues?

Failing that, reverse-engineer the "working" system a bit to see if you can figure out what it is doing.

You could look at the angle of deflection.

You know the direction the bullet was traveling before impact, and after impact. Solve for the point of impact, then normalize the vectors around the point of impact, then add them together and you should have a vector that is normal to the surface. You should make the center solver fuzzy so it can deal with slight inaccuracies.

Good idea, but I wonder if collision_start and collision_end are okay points to test trajectory. Has the deflection definitely not happened at the point collision_start triggers? Has it definitely deflected by the time collision_end is triggered? Better test it. The after-deflection point could have a workaround (small delay, and hopefully not enough for another collision or anything); the pre-deflection issue would be harder (capture velocity with a really high frequency until there is a collision? ouch).

Didn't say it would be pretty.

You need to keep a copy of both the velocity and position. You could do it entirely without the collision events.

But you should still use the collision event because if the object you hit has velocity it should change the angle of deflection.

I don't think you need to solve for the position, you can use the velocities to determine the normal. And a simple llGetPos will do for the collision start.

For grins I've implemented ricochet based on angle of deflection. This code should work, I haven't tested it but it does compile.

//Bullet Hole & Ricochet Dent Script
//Version 1.0, Written by Strife Onizuka, Copyright 2008
//
//You are free to do anything with this script (including sell it) just don't remove this header.
//If this script is included in a product then you must give the authors credit for their contributions and a free copy of the product.

//TODO List
//1) Blood effects
//2) Adjust the ricochet probability based on speed too.
//3) Do something for moving objects (like vehicals)

string ricochet = "";//ricochet dent object
string bullet_hole = "";//bullet hole object
float double_ricochet_max_angle = 1.0;//A value between 0 and PI
vector out = <0.0, 0.0, 1.0>;//the axis you want perpendicular to the normal of the surface at the point of collision.
integer ttl = 300;//kill old bullets, 300 is somewhere between 30 and 60 seconds depending upon execution speed.

vector v;
vector v1;
vector p = ZERO_VECTOR;
vector z = ZERO_VECTOR;
integer counter;

default
{
    on_rez(integer a)
    {
        if(a)
        {
            llSetTimerEvent(0.1);
            p = z;
            counter = ttl;
        }
        else
            llSetTimerEvent(0.0);
    }
    timer()
    {
        if(p)
        {
            if(double_ricochet_max_angle <= llRot2Angle(llRotBetween(v1 = v, v = llGetVel())))
            {
                llRezObject(bullet_hole, p, p = z, llRotBetween(llVecNorm(v) - llVecNorm(v1), out), 0);
                llDie();
            }
            else
                llRezObject(ricochet, p, p = z, llRotBetween(llVecNorm(v) - llVecNorm(v1), out), 0);
            return;
        }
        v = llGetVel();
        if(!(counter = ~-counter))
            llDie();
    }
    collision_start(integer num)
    {
        p = llGetPos();
        if(llDetectedType(0) & AGENT)
        {
            //TODO: Blood Effect
            llDie();
        }
        else if(llDetectedVel(0))
        {
            //TODO: do something for vehicals.
            llDie();
        }
    }
    land_collision(vector pos)
    {
        p = pos;
    }
}//

It's been ages since I've written a bullet script.