[prev in list] [next in list] [prev in thread] [next in thread]
List: opensim-users
Subject: Re: [Opensim-users] collision detection for attachments
From: Justin Clark-Casey <jjustincc () googlemail ! com>
Date: 2013-07-11 22:37:55
Message-ID: 51DF33C3.3040203 () googlemail ! com
[Download RAW message or body]
I can't remember the full history of this, but here are a few points, Gwyne=
th.
1) There are no specific collision packets being sent from simulator -> vie=
wer. Rather, on a collision the simulator =
just sends a position update to the viewer telling it that the avatar remai=
ns 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 developme=
nt, 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 wa=
s only that this functionality is supposed to
> be standard in SL, and, as such, there is no reason for OpenSim not to im=
plement it as SL does. I mean, the collision
> data is being sent to the viewer... there are special communications pack=
ets 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 w=
hole architecture of the application =97 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 de=
finitely need to know when 'bots collide with
> them :) I *can* script a *few* objects (and, in fact, some special object=
s 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 m=
issing 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 program=
mer too =97 I have no time to do professional
> code up to the standards :) All I can do are quick fixes and hope that so=
meone 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 quickl=
y find out :) If not, well, since this has to
> work on all OpenSim grids, it means sticking to ODE. I'm counting on a ce=
rtain amount of physics engine "transparency",
> but since this is an area of the OpenSim code which I never took a look a=
t, I have no idea what I'll find!
>
> Cheers,
>
> - Gwyn
>
>
> On 9 July 2013 17:16, dz <dz@bitzend.net <mailto:dz@bitzend.net>> wrote:
>
>
>
>
>
> From: Gwyneth Llewelyn <gwyneth.llewelyn@gwynethllewelyn.net <mai=
lto:gwyneth.llewelyn@gwynethllewelyn.net>>
> Subject: Re: [Opensim-users] collision detection for attachments
>
> ...
>
> First, I'm trying to make my solution compatible across SL and Op=
enSim,
> 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-spec=
ific
> 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 th=
ings, and,
> at worst, useless. Here, neither SL nor OpenSim are "perfect". SL=
's
> llCastRay() seems to give slightly better results, but they're "n=
ot 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 oft=
en worse
> and has all the other known limitations).
>
> The third assumption is that the world is full of unscripted obje=
cts, and
> the scripts will have to deal with them all to have minimally acc=
urate
> "vision". So I cannot use dz's approach, which is to drop a scrip=
t 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 even=
ts 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 w=
rap the
> whole world with leather to make all surfaces soft, because that's
> impossible; instead, wrap just a little bit of leather across you=
r 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 ma=
ke 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 ge=
t a list
> of what OpenSim (or SL) _thinks_ is ahead of the avatar. But some=
times the
> ray will just send back wrong/incomplete information, and the ava=
tar ? 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 ba=
ck 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 send=
ing rays
> in very short time frames ? just once in a while, assuming most o=
f 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: appa=
rently,
> 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 the=
y?
>
> 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 mentio=
ning
> this). Will this be implemented in BulletPhysics? (I'm not even s=
ure 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 w=
orkable solution <winks>..
>
> My solution was just the most reliable way I found to deal with all o=
f the things that did not work the way I
> expected when I tried to automate my libOMV testclient based bots, an=
d later the NPC bots available in OpenSim. I
> don't script every object.. I use a couple dozen scripted objects i=
n strategic locations (intersections) to detect
> and redirect the bots that need to move around the sim. I have secon=
dary collision detectors in places where the
> bots MIGHT wander ( but arent intended to) that simply redirect the b=
ot to the nearest "correct" intersection.
> Intersections take a percentage of the bots that pass through and dir=
ect 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 unaccepta=
ble given the difficulties with getting an
> avatar to actually move to a specific (exact) location, and sim perfo=
rmance affected the ability to determine if the
> bot had arrived. My bots moved, but to the wrong spots, and then ofte=
n never stopped.
>
> I spent a long time trying to get segregated attachments to handle th=
e collisions like others wanted, but the only
> consistent collisions I was able to detect were avatar capsules ( an=
d even those are less reliable than I
> expected). I had it explained to me WHY it is unreasonable to expec=
t 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 Op=
enSim at least let me modify the size of the
> avatar capsule somewhat, so I can prevent/react to some situations wh=
ere bots just look wrong. I recently revisited
> these tests using a rigged mesh design, but the results were no bette=
r.
>
> When CastRay became available, I attempted to implement solutions bas=
ed on that functionality, I have since filed at
> least one MANTIS on the incorrect responses you mentioned. But reall=
y.. I currently can't modify the position of a
> seated avatar to implement even the 'semi-borked" SL animation standa=
rds, so I expect it will be a while before some
> of these newer features get tested enough to be reliable and efficien=
t.
>
> My current implementation wasn't my first, second, or even third, sol=
ution and it isn't the right solution for many
> other sim designs / bot implementations, It is, in my experience, th=
e one that works most reliably in the widest
> variety of design and performance situations. On 7.6 standalone, thi=
s design allows me to generate 100 NPC bots and
> have them move about and perform background activities while maintain=
ing reasonable sim performance. I have
> generated as many as 400 bots, let them wander for 4-6 hours, and the=
n 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/naviga=
tion to a region module. I know that isn't a
> "portable" solution if you intend to migrate back to SL, but it seem=
s 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 t=
he opportunity to multi-thread physics
> interactions IS a huge step forward to having the performance require=
d to support the kinds of "enhanced" collision
> detections you desire.
>
> dz
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users@lists.berlios.de <mailto:Opensim-users@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@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
-- =
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-users mailing list
Opensim-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic