characters Chacter collision detection avoidence

[VirtualKitten]

Hi

I am attempting a  collision avoidance system and would be grateful of some advice:

I have coded so far 

    collision_start(integer num) {
        collision_velocity=llDetectedVel(num);
        collision_key = llDetectedKey(num);
        
    }    
    collision(integer num_detected)
    {
        l_collision_object_sz = llGetBoundingBox(collision_key);
        if(llSubStringIndex((string)llDetectedName(0),"wood") || llSubStringIndex((string)llDetectedName(0),"tree")) {
             
             // Do something to avoid if we are able to avoid
             llSetStatus(STATUS_PHANTOM, TRUE);
        }
        else if(~llListFindList(avoid_access_list, (list)llDetectedName(0)))
        {
            llSetStatus(STATUS_PHANTOM, TRUE);
        }
    }
    collision_end (integer num) {
         llSetStatus(STATUS_PHANTOM, FALSE);
    }

But characters cannot be phantom so they must avoid not fly through things,  this is not helpful I but can get bounding box size of item I collided with  from llGetBoundingBox() and also obtain Velocity impact point in llDetectedVel() How do I compare these too and work out probably best avoidance  presumably I can somehow find the edge offset from some comparison of bounding box and impact point but one is a list and other is a vector . I searched for this but could find no information I would be grateful of any kind ideas you could share  thank you for looking

 

Edited January 31, 2021 by VirtualKitten
to add prefix and was in a quote for me strange reason

[animats]

It's surprisingly difficult to find out if a space is empty. It takes quite a few llCastRay calls.

My NPCs do horizontal ray casts ahead to check for obstacles. This is done at several heights and widths. I do 9 of those, at head height, waist height, and ankle height, times center, left, and right.

But that's not enough. I had to add vertical ray casts, to detect thin horizontal planar objects, like table tops. I do five of those, looking downward, to the four corners of a square and the center.

Even that isn't airtight. It can miss narrow objects like railings.

And then there are some bugs related to objects with degenerate triangles in the collision model.

Incidentally, the documentation for llCastRay says you don't get hits reported from the object you're casting from. This is only true if the object is convex. The real check is that you only get hits reported when you hit the outside face of something. If you manage to get entirely inside an object, llCastRay, like the rest of the system, can't see it.

[VirtualKitten]

@animatsYes am not happy with llCastRay I was hoping collision_before would give an update it gives box shape but its in a list  and the hit is a vecor i need to be able to figure out which way to go up left or right.

my understanding of the bounding box is list [vector min corner , vector max corner] so to get the face dimensions  how from vector of the hit location  please? so that I can work out how to move up right or left?

 

There is also llDetectedPos() used in things whas the difference 

 

I have read its like

vector centre = llDetectedPos(llDetectedKey(0)) + llList2Centre(llBoundingBox(target),0)) +llList2Centre(llBoundingBox(target),1)*5;

and vector size =  llList2Centre(llBoundingBox(target),0)) +llList2Centre(llBoundingBox(target),1);

 

Thanks 
D

Edited January 31, 2021 by VirtualKitten

[Wulfie Reanimator]

3 hours ago, animats said:

My NPCs do horizontal ray casts ahead to check for obstacles. This is done at several heights and widths. I do 9 of those, at head height, waist height, and ankle height, times center, left, and right.

But that's not enough. I had to add vertical ray casts, to detect thin horizontal planar objects, like table tops. I do five of those, looking downward, to the four corners of a square and the center.

Even that isn't airtight. It can miss narrow objects like railings.

And then there are some bugs related to objects with degenerate triangles in the collision model.

Random thought; would it be possible viable to use a separate object (the same size as the character collider) and for example llMoveToTarget to test for collisions in a more "volumetric" way? And then if there is a collision, optionally do a raycast towards the collision point to check if it's just a small incline on the floor.

Edited January 31, 2021 by Wulfie Reanimator

[VirtualKitten]

Well I did yet a 24 page @animatpath building thing on github but didn't understand how it related to LSL as it was a different language not Linden Script .

I have made a start but got no further  to try and get some useful variables out :

 

    collision_start(integer num) {
        collission_velocity=llDetectedVel(num);
        collission_key = llDetectedKey(num);
        l_collission_object = llGetBoundingBox(collission_key);
        centre = llDetectedPos(0) + (llList2Vector(llGetBoundingBox(collission_key ),0) +llList2Vector(llGetBoundingBox(collission_key),1))*0.5;
        size = llList2Vector(llGetBoundingBox(collission_key ),1) -llList2Vector(llGetBoundingBox(collission_key),0);
    }    
    collision(integer num_detected)
    {
      
        if(llSubStringIndex((string)llDetectedName(0),"wood") || llSubStringIndex((string)llDetectedName(0),"tree")) {
             
             // Do something to avoid if we are able to avoid.
             
             //llSetStatus(STATUS_PHANTOM, TRUE);
        }
        else if(~llListFindList(avoid_access_list, (list)llDetectedName(0)))
        {
            //llSetStatus(STATUS_PHANTOM, TRUE);
        }
    }
    collision_end (integer num) {
         //llSetStatus(STATUS_PHANTOM, FALSE);
    }

 

[VirtualKitten]

Am not getting much further with this today I don't understand the need for llCastRay or 9 or more up down left or right  things when we have collision before  which should trigger before collision how much by I don't know perhaps someone does

[animats]

2 hours ago, Wulfie Reanimator said:

Random thought; would it be possible viable to use a separate object (the same size as the character collider) and for example llMoveToTarget to test for collisions in a more "volumetric" way? And then if there is a collision, optionally do a raycast towards the collision point to check if it's just a small incline on the floor.

As a means of exploring the world, that bangs things around too much.

A phantom object doesn't get collision events, so that doesn't help. There are "llVolumeDetect" objects, but they only report collisions with physical objects, which includes avatars. Can't detect walls that way. Rapidly moving an invisible physical object around as an object detector will hit and push around avatars and vehicles.

In a totally controlled environment, where every fixed obstacle was marked as a static obstacle in the navmesh, you could use llVolumeDetect objects to detect avatars and physical objects. But that means a large amount of parcel prepping. It also won't detect above-ground obstacles like low clearances.

There's no easy way to do this with SL's current API. It's possible to do it via llCastRay, but it takes a lot of programming.

 

Edited January 31, 2021 by animats

[VirtualKitten]

9 hours ago, animats said:

As a means of exploring the world, that bangs things around too much.

A phantom object doesn't get collision events, so that doesn't help. There are "llVolumeDetect" objects, but they only report collisions with physical objects, which includes avatars. Can't detect walls that way. Rapidly moving an invisible physical object around as an object detector will hit and push around avatars and vehicles.

In a totally controlled environment, where every fixed obstacle was marked as a static obstacle in the navmesh, you could use llVolumeDetect objects to detect avatars and physical objects. But that means a large amount of parcel prepping. It also won't detect above-ground obstacles like low clearances.

There's no easy way to do this with SL's current API. It's possible to do it via llCastRay, but it takes a lot of programming.

 

The PHANTON model doesnt work at all when you use 

llSetStatus(STATUS_PHANTOM, TRUE);

it reports an error in the console that character's cannot be set to phantom. Further more i tested a bit more with collision  and a flapping wing the collision system did report about 10 hits using the collision script above and strangely rotated himself away . I am not sure how or why As I have no coding to do that . My coding was in a loops like this

 collision_start(integer num) {
        while(num--) {
        collission_velocity=llDetectedVel(num);
        collission_key = llDetectedKey(num);
        l_collission_object = llGetBoundingBox(collission_key);
        centre = llDetectedPos(0) + (llList2Vector(llGetBoundingBox(collission_key ),0) +llList2Vector(llGetBoundingBox(collission_key),1))*0.5;
        size = llList2Vector(llGetBoundingBox(collission_key ),1) -llList2Vector(llGetBoundingBox(collission_key),0);
        llOwnerSay("Collission: " + (string)collission_key);
        }
    }    
    collision(integer num_detected)
    {
      
        if(llSubStringIndex((string)llDetectedName(0),"wood") || llSubStringIndex((string)llDetectedName(0),"tree")) {
             
             // Do something to avoid if we are able to avoid.
             
             //llSetStatus(STATUS_PHANTOM, TRUE);
        }
        else if(~llListFindList(avoid_access_list, (list)llDetectedName(0)))
        {
            //llSetStatus(STATUS_PHANTOM, TRUE);
        }
    }
    collision_end (integer num) {
         //llSetStatus(STATUS_PHANTOM, FALSE);
    }
    land_collision_start(vector pos) { 
        
       llStartObjectAnimation( flyandperch );
        llStopObjectAnimation( curr_animation );
        curr_animation = flyandperch;
    }
    land_collision(vector pos) {
        llStartObjectAnimation( perched );
        llStopObjectAnimation( curr_animation );
        curr_animation = flyandperch;
    }

 

As you can see I positioned him with is wing on the item outside:


This gave the following hits:
[01:01] Dragon (version three): Collission: 2033c133-1af8-91a4-fbcb-0fd5881ce389
[01:01] Dragon (version three): Collission: 059ea966-ebfc-07e7-6ab8-572ac51b227e
[01:01] Dragon (version three): Collission: 16d080f3-8568-a3ff-0399-c6fea7bfc2ed
[01:01] Dragon (version three): Collission: 2033c133-1af8-91a4-fbcb-0fd5881ce389
[01:01] Dragon (version three): Collission: 16d080f3-8568-a3ff-0399-c6fea7bfc2ed
[01:01] Dragon (version three): Collission: 059ea966-ebfc-07e7-6ab8-572ac51b227e
[01:01] Dragon (version three): Collission: 579fc543-454d-b7e1-aa16-4f80668e0362
 

And he turned away on his own

[VirtualKitten]

@animats i did look at your code 24 pages its seems very complicated and hybrid code of LSL and perhaps 'C' I  am not sure what environment it was written for . I have played with llCastRay( but I found it was not good with single ray too it was unable to detect items if they slightly overlapped with a single llCastRay has this now been made to work ? Currenly I am still not aware how much time  before a collision _before event occurs  before the collision. I could not find this written anywhere . I am unsure how he is turning from the collision after reporting hits  maybe there is some inbuilt physics rebuttal from normal mesh objects ?

The keys it returned was all different oddly  I need to look to see what they are  but haven found an easy route yet.

 

[Mollymews]

43 minutes ago, VirtualKitten said:

 Further more i tested a bit more with collision  and a flapping wing the collision system did report about 10 hits using the collision script above and strangely rotated himself away . I am not sure how or why As I have no coding to do that

 

As you can see I positioned him with is wing on the item outside:


This gave the following hits:
[01:01] Dragon (version three): Collission: 2033c133-1af8-91a4-fbcb-0fd5881ce389
[01:01] Dragon (version three): Collission: 059ea966-ebfc-07e7-6ab8-572ac51b227e
[01:01] Dragon (version three): Collission: 16d080f3-8568-a3ff-0399-c6fea7bfc2ed
[01:01] Dragon (version three): Collission: 2033c133-1af8-91a4-fbcb-0fd5881ce389
[01:01] Dragon (version three): Collission: 16d080f3-8568-a3ff-0399-c6fea7bfc2ed
[01:01] Dragon (version three): Collission: 059ea966-ebfc-07e7-6ab8-572ac51b227e
[01:01] Dragon (version three): Collission: 579fc543-454d-b7e1-aa16-4f80668e0362
 

And he turned away on his own

 

this can happen when our dragon is physical. A moving physical object can ricochet off another non-phantom object, changing its trajectory

 

[VirtualKitten]

@Mollymews thanks Molly we just need to find out why path finding doesn't work at 3000m can an estate be parceled up differently so the pathfinding works in one area but know another  strangely I have been using build  >> fathfinding > view/tests: which passes tests however there appears to be no random pathfinding which is curious

[VirtualKitten]

Can parcel areas have different dynamic path finding than the rest of the SIM
I built a little tester script to test if dynamic path-finding  was enabled it is enabled so why is this not available at 3000m please in a different  parcel
I wrote this and it was enabled
 

default
{
    touch_start(integer total_number)
    {
        string version = llGetEnv("sim_version");
        llOwnerSay("Region " + llGetRegionName() + " is running "
                   + llGetEnv("sim_channel") + " version " + version );
 
        list ver = llParseString2List(version, ["."], []);
 
        llOwnerSay("Build: "+llList2String(ver, 3));
        llOwnerSay("Build Date: "+llList2String(ver, 2)+"-"+llList2String(ver, 1)+"-20"+llList2String(ver, 0));
        llOwnerSay("Estate ID:"+llGetEnv("estate_id"));
        llOwnerSay("Estate Name:"+llGetEnv("estate_name"));
        llOwnerSay("Dynamic Path Finding (on/off):"+llGetEnv("dynamic_pathfinding"));
        if (llGetEnv("dynamic_pathfinding")== "enabled") llSetColor(<0.180, 0.800, 0.251>,ALL_SIDES); 
        else llSetColor(<1.000, 0.255, 0.212>,ALL_SIDES);
        llOwnerSay("Region Start Time:"+llGetEnv("region_start_time"));
        llOwnerSay("Sim Channel:"+llGetEnv("sim_channel"));
        llOwnerSay("Sim Version:"+llGetEnv("sim_version"));
        list details = llGetParcelDetails(llGetPos(), [PARCEL_DETAILS_NAME, PARCEL_DETAILS_DESC, PARCEL_DETAILS_ID]);
 
        llOwnerSay( "Local Parcel Name:" + llList2String(details ,0));
        llOwnerSay( "Local Parcel Desc:" + llList2String(details ,1));
         llOwnerSay( "Local Parcel Desc:" + llList2String(details ,1));
    }
}

 

[VirtualKitten]

@Mazidox Linden

• Mazidox Linden

I have been looking at error codes and it is reporting 3  PU_FAILURE_INVALID_GOAL When it is flying only on same spot  at 3000m and not llNavigate to next place.

   path_update(integer type, list reserved) {
        if (~llListFindList([PU_FAILURE_INVALID_START,PU_FAILURE_INVALID_GOAL,PU_FAILURE_UNREACHABLE], [type])){
            list l = llGetClosestNavPoint(llGetPos(), []);
            if( l!=[]){
                llNavigateTo(llList2Vector(l, 0), [FORCE_DIRECT_PATH,TRUE]);
            }
            else{
            //Houston, we have a problem... 
            llOwnerSay("Houstan we have a problem: " +(string)type + ", " + path_err_msg(type));
            }
        }

which means    Goal is not on the navmesh and cannot be reached.

Goal is not on the navmesh and cannot be reached.

What does this mean  exactly as the whole mega-prim its on is navmesh? See above!

 

 

Edited February 1, 2021 by VirtualKitten
added code