[Opensim-users] collision detection for attachments

Wed Jul 10 01:06:58 UTC 2013

Hi dz,

My apologies for misquoting you :) It wasn't intended hehe... my point was
only that this functionality is supposed to be standard in SL, and, as
such, there is no reason for OpenSim not to implement it as SL does. I
mean, the collision data is being sent to the viewer... there are special
communications packets for that (I'm assuming that the viewer needs to know
when avatars collide with things!), but not to the LSL VM, at least not
when an object is attached. Why? I can understand it can be for performance
reasons, of course... One idea I had was to grab the collision
communications on libopenmetaverse instead of doing it in LSL. It's a
possibility (there are certainly classes to add callbacks for those special
packets), but it will mean changing a lot of logic in the whole
architecture of the application — and I have no idea if all those
collisions are really communicated back to the viewer, and under which
circumstances they are not...

As said, in my case, I cannot script all the objects in the scene, but
definitely need to know when 'bots collide with them :) I *can* script a
*few* objects (and, in fact, some special objects work that way, to let
bots know they have reached their goal), but these are insignificant
exceptions, compared to the rest of the 15,000 prims in the scene...

So I guess I have no other way but to change OpenSim's code and add the
missing functionality :) I just hope it doesn't take me too many months to
do so. We'll see. I would rather prefer not to do it, because that would
mean that only my own grid would work (as well as SL) and no one else's,
and I need to make sure all my code is portable across all grids... I'm not
only not a core developer, but I'm a very sloppy programmer too — I have no
time to do professional code up to the standards :) All I can do are quick
fixes and hope that someone might improve them later.

Thanks for the tip on BulletPhysics; I'm now going to experiment with it :)
Who knows, maybe it's easier to get collision events on attachments under
BulletPhysics. I'm sure I'll quickly find out :) If not, well, since this
has to work on all OpenSim grids, it means sticking to ODE. I'm counting on
a certain amount of physics engine "transparency", but since this is an
area of the OpenSim code which I never took a look at, I have no idea what
I'll find!

Cheers,

    - Gwyn

On 9 July 2013 17:16, dz <dz at bitzend.net> wrote:

>
>
>
>
>> From: Gwyneth Llewelyn <gwyneth.llewelyn at gwynethllewelyn.net>
>> Subject: Re: [Opensim-users] collision detection for attachments
>>
>> ...
>>
>> First, I'm trying to make my solution compatible across SL and OpenSim,
>> while developing most of the code in OpenSim: the theory is that if it
>> works in OpenSim, it should work even better in SL (based on the theory
>> that OpenSim only implements a subset of LSL ? except for OS-specific
>> functions, of course). So, keeping things simple, and making them work in
>> OpenSim, should ensure compatibility with SL later on. That's the first
>> assumption.
>>
>> The second one is that llCastRay() is, at best, tricky to find things,
>> and,
>> at worst, useless. Here, neither SL nor OpenSim are "perfect". SL's
>> llCastRay() seems to give slightly better results, but they're "not as
>> good
>> as advertised" ? when the ray is being cast from a moving avatar, i.e.
>> from
>> inside an attachment. (The alternative, using sensors, can be often worse
>> and has all the other known limitations).
>>
>> The third assumption is that the world is full of unscripted objects, and
>> the scripts will have to deal with them all to have minimally accurate
>> "vision". So I cannot use dz's approach, which is to drop a script inside
>> each and every object in a 15,000-prim area (yes, my scripts need to
>> navigate across all that), and expect them to send collision events via
>> llSay(). It's simply unfeasible. There is an old Indian Buddhist saying
>> that goes, "If the roads hurt your feet, the solution is not to wrap the
>> whole world with leather to make all surfaces soft, because that's
>> impossible; instead, wrap just a little bit of leather across your feet,
>> and you can walk all roads without hurting yourself". A very good
>> similarity applies to this case, IMHO: it's a bit pointless to make sure
>> *all* the world is scripted for collisions, when you just need to test
>> collisions on one's attachments.
>>
>> So what I'm doing is a mixed approach. First, I cast a ray, to get a list
>> of what OpenSim (or SL) _thinks_ is ahead of the avatar. But sometimes the
>> ray will just send back wrong/incomplete information, and the avatar ? in
>> the case where no human is behind it, of course ? hits a wall. In that
>> case, I wish the attachment to detect the collision and report back to the
>> system, and flag an exception ? we thought the way was clear, but it
>> isn't.
>> Also, this approach means that the script doesn't need to be sending rays
>> in very short time frames ? just once in a while, assuming most of the
>> environment will remain static, and deal with exceptions (or cast new
>> rays!) if it starts bumping into things.
>>
>> This works well enough in SL, but apparently not in OpenSim: apparently,
>> without any special tricks, it seems impossible to get collision events in
>> an attachment to work (at least on 0.7.5 Dev). Why?
>>
>> If there are any special tricks to get this working, what are they?
>>
>> Will switching to 0.7.6 Dev make any difference? (As far as I can see on
>> the Mantis and/or searching via Google, nobody seems to be mentioning
>> this). Will this be implemented in BulletPhysics? (I'm not even sure if
>> BulletPhysics already works under Linux these days...)
>>
>> ....
>>
>>    - Gwyn
>>
>
> Just to clarify..
> I never suggested that scripting all of the objects in a scene is a
> workable solution <winks>..
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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...
>
> 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.
>
>  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.
>
> dz
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>

-- 
"I'm not building a game. I'm building a new country."
  -- Philip "Linden" Rosedale, interview to Wired, 2004-05-08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20130710/43618e85/attachment.html>