[Opensim-users] collision detection for attachments

Thu Jul 11 22:37:55 UTC 2013

I can't remember the full history of this, but here are a few points, Gwyneth.

1) There are no specific collision packets being sent from simulator -> viewer.  Rather, on a collision the simulator 
just sends a position update to the viewer telling it that the avatar remains in the pre-collision location.

You might be able to emulate receiving actual collision data in very messy (through using health) or extremely messy 
(via sending a custom non-LL UDP message on collision) ways.

2) llCastRay() in current development code is much improved, afaik, though I can't tell you specifics since I didn't 
have anything to do with it.  Current master is under quite heavy development, but in general it should be okay.

3) BulletSim has also come on in leaps and bounds since 0.7.5 was released.

On 10/07/13 02:06, Gwyneth Llewelyn wrote:
> 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 <mailto:dz at bitzend.net>> wrote:
>
>
>
>
>
>         From: Gwyneth Llewelyn <gwyneth.llewelyn at gwynethllewelyn.net <mailto: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 <mailto: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
>
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>

-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc