<div dir="ltr">Hi dz,<div><br></div><div style>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...</div>
<div style><br></div><div style>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...</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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!</div>
<div style><br></div><div style>Cheers,</div><div style><br></div><div style> - Gwyn</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 9 July 2013 17:16, dz <span dir="ltr"><<a href="mailto:dz@bitzend.net" target="_blank">dz@bitzend.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">dz<br></div></font></span></div></div></div></div>
<br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>"I'm not building a game. I'm building a new country."<br>
-- Philip "Linden" Rosedale, interview to Wired, 2004-05-08
</div>