<div dir="ltr"><br><br><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
From: Gwyneth Llewelyn <<a href="mailto:gwyneth.llewelyn@gwynethllewelyn.net">gwyneth.llewelyn@gwynethllewelyn.net</a>><br>
Subject: Re: [Opensim-users] collision detection for attachments<br>
<br>
...<br>
<br>
First, I'm trying to make my solution compatible across SL and OpenSim,<br>
while developing most of the code in OpenSim: the theory is that if it<br>
works in OpenSim, it should work even better in SL (based on the theory<br>
that OpenSim only implements a subset of LSL ? except for OS-specific<br>
functions, of course). So, keeping things simple, and making them work in<br>
OpenSim, should ensure compatibility with SL later on. That's the first<br>
assumption.<br>
<br>
The second one is that llCastRay() is, at best, tricky to find things, and,<br>
at worst, useless. Here, neither SL nor OpenSim are "perfect". SL's<br>
llCastRay() seems to give slightly better results, but they're "not as good<br>
as advertised" ? when the ray is being cast from a moving avatar, i.e. from<br>
inside an attachment. (The alternative, using sensors, can be often worse<br>
and has all the other known limitations).<br>
<br>
The third assumption is that the world is full of unscripted objects, and<br>
the scripts will have to deal with them all to have minimally accurate<br>
"vision". So I cannot use dz's approach, which is to drop a script inside<br>
each and every object in a 15,000-prim area (yes, my scripts need to<br>
navigate across all that), and expect them to send collision events via<br>
llSay(). It's simply unfeasible. There is an old Indian Buddhist saying<br>
that goes, "If the roads hurt your feet, the solution is not to wrap the<br>
whole world with leather to make all surfaces soft, because that's<br>
impossible; instead, wrap just a little bit of leather across your feet,<br>
and you can walk all roads without hurting yourself". A very good<br>
similarity applies to this case, IMHO: it's a bit pointless to make sure<br>
*all* the world is scripted for collisions, when you just need to test<br>
collisions on one's attachments.<br>
<br>
So what I'm doing is a mixed approach. First, I cast a ray, to get a list<br>
of what OpenSim (or SL) _thinks_ is ahead of the avatar. But sometimes the<br>
ray will just send back wrong/incomplete information, and the avatar ? in<br>
the case where no human is behind it, of course ? hits a wall. In that<br>
case, I wish the attachment to detect the collision and report back to the<br>
system, and flag an exception ? we thought the way was clear, but it isn't.<br>
Also, this approach means that the script doesn't need to be sending rays<br>
in very short time frames ? just once in a while, assuming most of the<br>
environment will remain static, and deal with exceptions (or cast new<br>
rays!) if it starts bumping into things.<br>
<br>
This works well enough in SL, but apparently not in OpenSim: apparently,<br>
without any special tricks, it seems impossible to get collision events in<br>
an attachment to work (at least on 0.7.5 Dev). Why?<br>
<br>
If there are any special tricks to get this working, what are they?<br>
<br>
Will switching to 0.7.6 Dev make any difference? (As far as I can see on<br>
the Mantis and/or searching via Google, nobody seems to be mentioning<br>
this). Will this be implemented in BulletPhysics? (I'm not even sure if<br>
BulletPhysics already works under Linux these days...)<br>
<br>
....<br>
<br>
   - Gwyn<br></blockquote><div> </div><div><div class="gmail_extra">Just to clarify..<br></div><div class="gmail_extra">I never suggested that scripting all of the objects in a scene is a workable solution <winks>..<br>
<br></div><div class="gmail_extra">My
 solution was just the most reliable way I found to deal with all of the
 things that did not work the way I expected when I tried to automate my
 libOMV testclient based bots, and later the NPC bots available in 
OpenSim.   I don't script every object..   I use a couple dozen scripted
 objects in 
strategic locations (intersections) to detect and redirect the bots that
 need to move around the sim.  I have secondary collision detectors in 
places where the bots MIGHT wander ( but arent intended to) that simply 
redirect the bot to the nearest "correct" intersection.   Intersections 
take a percentage of the bots that pass through and direct them to sit 
on  local "normal" scripted objects that implement the non-movement 
related animations.   <br><br></div><div class="gmail_extra">I spent a 
while using path generators, but the results were unacceptable given the
 difficulties with getting an avatar to actually move to a specific 
(exact) location, and sim performance affected the ability to determine 
if the bot had arrived. My bots moved, but to the wrong spots, and then 
often never stopped. <br><br></div><div class="gmail_extra">I spent a 
long time trying to get segregated attachments to handle the collisions 
like others wanted, but the only consistent collisions I was able to 
detect were avatar capsules  ( and even those are less reliable than I 
expected).  I had it explained to me  WHY it is unreasonable to expect 
the sim to know where my avatar hand is when I use an animation to stick
 it in front of me. The config files in OpenSim at least let me modify 
the size of the avatar capsule somewhat, so I can prevent/react to some 
situations where bots just look wrong.  I recently revisited these tests
 using a rigged mesh design, but the results were no better.<br><br></div><div class="gmail_extra">When
 CastRay became available, I attempted to implement solutions based on 
that functionality, I have since filed at least one MANTIS on the 
incorrect responses you mentioned.  But really.. I currently can't 
modify the position of a seated avatar to implement even the 
'semi-borked" SL animation standards, so I expect it will be a while 
before some of these newer features get tested enough to be reliable and
 efficient.<br><br>My current implementation wasn't my first, second,  
or even third, solution  and it isn't the 
right solution for many other sim designs / bot implementations,  It is,
 in my experience, the one that works most reliably in the widest 
variety
 of design and performance situations.  On 7.6 standalone, this design 
allows me to generate 100 NPC bots and have them move about and perform 
background activities while maintaining reasonable sim performance.  I 
have generated as many as 400 bots, let them wander for 4-6 hours, and 
then logged them all out without having the sim crash.   I would never 
expect that to be possible if every one of the NPC's was using RayCast 
to feed an on-board scripted direction finder,  or if the physics engine
 had to calculate the "REALTIME" position of everyones 
hands/feet/heads...  <br><br></div><div class="gmail_extra">Ultimately, I
 think I will wind up offloading the bot movement/navigation to a region
 module.  I know that isn't a "portable" solution if you intend to 
migrate back to SL,  but it seems the only rational way to plan for 
OpenSim regions with 30-60,000 objects.  <br><br> Finally..  the new 
physics engine IS working in linux, and having the opportunity to 
multi-thread physics interactions IS a huge step forward to having the 
performance required to support the kinds of "enhanced" collision 
detections you desire.<br><br></div><div class="gmail_extra">dz<br></div></div></div></div></div>