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 <[email protected] <mailto:[email protected]>> wrote:
From: Gwyneth Llewelyn <[email protected]
<mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
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
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
