Thanks - that's a very interesting and useful background, and explains a lot about the current implementation.
And I can certainly understand the desire for the raycasting to be independent of the physics engine for OpenSim. Teravus Ovares wrote: > Just a note... it's probably nothing.. however.. a bit of history > on llcastray in OpenSimulator.... I wrote the obb collision detection > being used for llcastray currently. It wasn't actually intended to > be used in llcastray... it was intended to be used to raycast against > objects when rezzing cubes and objects. It was also designed to > handle things like 'duplicate on ray'. Anyway... . Melanie_T > thought that the system needed a physics independent implementation of > llcastray and so made use of the OBB raycast that is used for rezzing > for llcastray. That said, there are now physics interface APIs that > can be used to replace the physics independent llcastray method being > used now. The physics layer needs to set a property for if it can > handle raycast requests to true and it needs to implement that part of > the OpenSimulator physics API. > > For more information, go to the bottom of this file: > https://github.com/nebadon2025/opensimulator/blob/master/OpenSim/Region/Physics/Manager/PhysicsScene.cs > > Best Regards > > Teravus > > On Fri, Feb 28, 2014 at 3:36 PM, Handy Low <handy.low.syst...@gmail.com> > wrote: > > Oh, you certainly didn't steal the thread. All this is part of the > > same investigation I'd been doing, even if attachments weren't on my > > particular agenda at the moment. > > > > And it's always seemed to me to be the nature of volunteer projects, > > that quite understandably people usually work on what interests them. > > > > Certainly I'm hugely grateful to all the volunteers and commercial > > contributors alike who've made OpenSim what it is. > > > > Gwyneth Llewelyn wrote: > > > >> Hi Handy, > >> > >> Interesting -- 'size matters' :-) Actually, I suspected that a small > >> attachment might have some issues, so I've been consistently using huge > >> transparent attachments (boxes or spheres... or even pyramids, which sort > >> of 'flare out' in the direction that is more interesting, as you suggest) > >> which completely encloses a normal-sized avatar (so they would have a > >> volume of at least 2 x 2 x 2 m). > >> > >> However, as much as I understand the underlying code -- which is not much > >> -- this shouldn't actually make any difference. Per SL specifications, an > >> attachment detecting collisions will not detect collisions *with the > >> attached prim's bounding box* but *with the avatar's bounding box*. This > >> is a major difference between detecting collisions inside prims -- when > >> they're attached, collisions *by the avatar* are passed to the scripts > >> *inside the attached prim*. When they're unattached, the physics engine > >> uses the prim's bounding box. Actually, the code dealing with collisions > >> with attachments is in there! There are a lot of interesting checks at the > >> avatar-collision level (both at the abstraction level but even further > >> down on the interface with the physics engine) to see if llVolumeDetect() > has been called or not, if an avatar has a scripted attachment that has > signaled the simulator to receive collision events, and so forth. A *lot* of > work has been put into this, and, as far > as I can > >> understand the very convoluted way this is supposed to work, the algorithm > >> seems to be conceptually sound. What I mean is that every time an avatar > >> collides with 'something' (and, again, notice that this will be a check > >> made using the avatar's bounding box, not the attachment's) there are, > >> indeed, checks being done to see if the avatar has a scripted attachment > >> and if it has registered itself to receive collision events. The code is > >> there, it just doesn't work... most of the time. Just the fact that it > >> DOES, indeed, work SOME of the time, tends to make me believe that there > >> are some timing issues involved, of which I haven't been aware, and have > >> no idea where to start looking for those timers. Maybe these low-level > >> collision events have to be enqueued somehow, to avoid getting 'lost', a > nd thus might need to be retrieved later at a much higher and more abstract > level (e.g. the virtual machine running the LSL bytecode...). I have not the > faintest clue on how this can be prog > rammed. > >> > >> I didn't wish to 'steal' the thread, but rather explain that the very > >> tempting, but naive alternative to llCastRay() to detect where a bullet > >> might hit an avatar is very tempting: get an avatar with lots of > >> attachments, and try to detect those attachments with llCastRay()... or > >> fire real, invisible bullets expecting the attachments (one per body part) > >> to respond, depending on which one was hit, and feed that information to a > >> central location... aye, all these are theoretical workarounds, but none > >> of them will actually work. Following SL's inspiration, a collision event > >> *of the avatar with something else* will be sent to *all* attachments > >> simultaneously (or, in the case of OpenSim, to none at all...). Of course, > >> when it works, you'll get some positioning information, and while this is > >> no > t highly accurate, at least you could figure out if the avatar has been > hit/detected/collided with something at the front, behind, sides, upper part, > lower part, etc... > >> > >> Well, it's such a pity that the few people who actually understand the > >> very intricate and convoluted code are uninterested in collecting data > >> about the environment and feeding it to LSL. For others, specially my case > >> (I do research on intelligent agents...), this means that NPCs are blind > >> as bats and, worse, do not even 'feel' anything when they bump into things > >> :) > >> > >> Ah, note that *some* collision information gets passed on to the viewer, > >> because the viewer will need to know where to apply those neat special > >> effects during a collision (playing sounds, showing some textures, etc.). > >> Ironically, these work actually quite well, and even show up relatively > >> accurately, but I have not the faintest idea on where those messages are > >> being generated and how they're passed to the viewer! (As much as I've > >> looked into libopenmetaverse, there seems to be little interest in getting > >> those 'collision hints', since, well, most libopenmetaverse applications > >> are text-base and do not pass visual clues back to the user...). > >> > >> Sorry for the long rant. I'm actually in the middle of writing some things > >> about OpenSimulator and why some crucial functionality is not only > >> missing, but workarounds are next-to-impossible, and implementing the > >> missing functionality -- as time passes and OpenSimulator becomes more and > >> more complex -- take so much time. I envy the volunteers who managed to do > >> those zillions of code in their spare time. It is the equivalent of > >> several lifetimes to replicate that :) ... and a considerable amount of a > >> lifetime just to understand enough of it to fix a tiny bug :) > >> > >> Cheers, > >> > >> - Gwyn > >> > >> On 27/02/2014, at 17:13, Handy Low wrote: > >> > >> > Hi Gwyn (sorry for misspelling your name up-thread) > >> > > >> > One thing I've discovered through testing is that the size of the > >> > projectile also makes a difference. If I increase the length of my > >> > bullets to a metre or two in the direction of travel, they fire the > >> > collision events every time (at least so far in my testing). The > >> > bullets do need to be that actual length too - "cheats" like > >> > path-cutting and slicing to hide the size will reduce the detection > >> > rate again. > >> > > >> > The workaround that I favour involves firing two bullets - a normal, > >> > small one and a long, invisible one - the target object can use a > >> > collision filter by name to avoid detecting both. > >> > > >> > I was wondering if that workaround would help in your case - make the > >> > attachment large (at least in the appropriate direction) but partly > >> > invisible? > >> > > >> > Gwyneth Llewelyn wrote: > >> > > >> >> Although this is not the *dev* list (to which I'm not subscribed > >> >> anyway), I > >> >> would certainly enjoy understanding better how the collision code > >> >> works. I > >> >> actually don't use llCastRay, but I wanted to get collisions been > >> >> caught by > >> >> attachments, just like SL does. After months of delving deep into the > >> >> code, > >> >> the best I could come up with was some very sporadic messages when the > >> >> avatar collided with a physical prim (or with 'itself'). This was highly > >> >> unpredictable, though -- now I guess it has to do with these 'timing > >> >> issues' > >> >> you've mentioned > >> >> > >> >> Ultimately, I had to give up on that and start my own research project > >> >> using a totally different approach. Which is a pity, really, since SL > >> >> gets > >> >> collisions on attachments so nicely, but lacks the powerful NPC library > >> >> that OpenSim already has. > >> >> > >> >> Cheers, > >> >> > >> >> - Gwyn > >> >> > >> >> > >> >> On 27 February 2014 01:34, Handy Low <handy.low.syst...@gmail.com> > >> >> wrote: > >> >> > >> >>> A very helpful explanation - thanks. > >> >>> > >> >>> Perhaps you could shed some light on the way the collision code works, > >> >>> particularly in regard to a physical projectile (a bullet) being fired > >> >>> at a scripted prim? > >> >>> > >> >>> The script inside the target prim reacts to collision_start() events, > >> >>> but these only seem to be triggered in some cases, depending on the > >> >>> shape of the prim, the velocity of the bullet, and even (it seems) the > >> >>> distance the bullet has travelled. > >> >>> > >> >>> Is there anything I can do to increase the likelihood of the event > >> >>> being triggered, other than those factors? I'm seeing large cylinder > >> >>> prims needing bullets travelling as slowly as 2m/s. > >> >>> > >> >>> Thanks. > >> >>> > >> >>> Dahlia Trimble wrote: > >> >>> > >> >>>> FWIW... > >> >>>> > >> >>>> I'm the one who wrote most of the collision geometry code in > >> >>> OpenSimulator. > >> >>>> Someone else wrote llCastRay(). From my understanding and from memory > >> >>>> of > >> >>>> past conversations, the author(s) of llCastRay implemented what they > >> >>> could > >> >>>> given the constraints of object accessibility in the core > >> >>>> OpenSimulator > >> >>> and > >> >>>> timing needs of llCastRay. Bounding boxes are easier to get to than > >> >>>> the > >> >>>> geometry, which is usually passed to the physics engine of choice > >> >>>> from a > >> >>>> manager object which is generally inaccessible. There is a way to ask > >> >>>> ODE > >> >>>> to do a raycast against geometry, however, it requires a time delay > >> >>> between > >> >>>> physics frames as the requests must be queued and the responses > >> >>>> retrieved > >> >>>> on the next frame. I was told this is an unacceptable delay although I > >> >>> did > >> >>>> not research it any further to see if this is really the case. I'm not > >> >>> sure > >> >>>> if Bullet has the same capability but I'd be surprised if it didn't. > >> >>>> > >> >>>> I'm not sure about other devs, but in my case the reason I have not > >> >>>> implemented a more accurate llCastRay() is that I don't get paid for > >> >>>> my > >> >>>> contributions to OpenSimulator and hence I usually don't implement > >> >>> anything > >> >>>> unless I need it and nobody else will do it. Often (but not always) > >> >>>> when > >> >>> I > >> >>>> do implement such features I choose to share them with the community > >> >>>> by > >> >>>> committing them to core, as I believe this is how open source works: > >> >>>> many > >> >>>> people contribute and the whole becomes greater than the sum of the > >> >>> parts. > >> >>>> Unfortunately I have no need for llCastRay() at this time and I am > >> >>>> pretty > >> >>>> busy so I probably wont be considering improving it for quite some > >> >>>> time, > >> >>> if > >> >>>> ever. However, I am willing to share my insights about collision > >> >>>> geometry > >> >>>> with others who would endeavor to implement it. > >> >>>> > >> >>>> > >> >>>> On Wed, Feb 26, 2014 at 6:07 AM, James Stallings II < > >> >>>> james.stalli...@gmail.com> wrote: > >> >>>> > >> >>>>> My apologies if you found my contribution discouraging; my intent was > >> >>>>> exactly the opposite. To be quite explicit, I encourage anyone who > >> >>>>> can > >> >>>>> improve this functionality to do so; for the rest of us, we must have > >> >>> faith > >> >>>>> that those who can contribute to the improvement of the code, > >> >>> eventually > >> >>>>> will. > >> >>>>> > >> >>>>> My experience has been that some things are more difficult than > >> >>>>> others > >> >>> to > >> >>>>> accomplish; and OpenSim devs, despite myth and appearances, are human > >> >>> too > >> >>>>> ;) > >> >>>>> > >> >>>>> Implementations of these things often happen in stages. First some > >> >>>>> groundwork is laid, and then improvements are added incrementally. I > >> >>> rather > >> >>>>> suspect that will be and has been the case as concerns llCastRay. > >> >>> First the > >> >>>>> framework is established simply with bounding boxes; then projection > >> >>> of the > >> >>>>> bounding box intersection onto the mesh, etc. It's even fairly likely > >> >>> that > >> >>>>> one will finish what another has begun, though it is not always the > >> >>> case. > >> >>>>> > >> >>>>> I think the point is, we all know what the ideal functionality of > >> >>>>> llCastRay is; and we all know it's desirable to have that > >> >>> functionality. My > >> >>>>> message is, it will eventually happen, and if we are not in a > >> >>>>> position > >> >>> to > >> >>>>> do it ourselves (I know I'm not in such a position), the best we can > >> >>> do is > >> >>>>> have a little faith, note the current behavior, and watch for > >> >>> improvements. > >> >>>>> > >> >>>>> A well phrased mantis is always good, as it keeps the need for > >> >>> improvement > >> >>>>> in view of the devs; but complaints about lack of functionality on > >> >>> mailing > >> >>>>> lists rarely do more than rub people the wrong way; the very people > >> >>>>> who > >> >>>>> will likely improve the code. This is something that has taken me > >> >>> YEARS to > >> >>>>> get through my thick skull; which is why I rarely post to this list > >> >>> these > >> >>>>> days ;) > >> >>>>> > >> >>>>> In any case, don't let me slow your roll :) > >> >>>>> > >> >>>>> > >> >>>>> Cheers > >> >>>>> > >> >>>>> James > >> >>>>> > >> >>>>> > >> >>>>> On Feb 26, 2014 7:26 AM, "Dr Ramesh Ramloll" <r.raml...@gmail.com> > >> >>> wrote: > >> >>>>> > >> >>>>>> Hi James, > >> >>>>>> It is important for user to make their needs known. Often > >> >>>>>> optimization > >> >>>>>> decisions for invisible underlying important stuff are made that may > >> >>> impact > >> >>>>>> user needs at the top. It is crucial here for users not to be > >> >>> discouraged > >> >>>>>> to voice their opinions in a civil way (which I think we were > >> >>>>>> doing). > >> >>> Some > >> >>>>>> things may be needed at the top user level but can cannot be > >> >>> implemented > >> >>>>>> because it would mess up underlying thing that is important. I do > >> >>>>>> understand that, designing complex systems is almost always about > >> >>> comprise. > >> >>>>>> In this case, a bounding box may have been opted for may be because > >> >>> it is > >> >>>>>> faster for scenes containing large number of objects (and less error > >> >>> prone > >> >>>>>> than for complex shapes)... and it could be that a decision was made > >> >>> to > >> >>>>>> sacrifice precision of values returned by llCastRay for speed and > >> >>>>>> that > >> >>>>>> would be understandable. In short, most people are mature enough to > >> >>> know > >> >>>>>> that competing concerns arise often and is typical, BUT stakeholders > >> >>> have > >> >>>>>> the right to try to influence direction and motivate development ... > >> >>>>>> hopefully statements in that regard would not be viewed as a sign of > >> >>>>>> "impatience". > >> >>>>>> Hence the need for conversation... certainly 'keep quiet while we > >> >>> work > >> >>>>>> patiently in the background' or 'why don't YOU do it?' is not a > >> >>> feature of > >> >>>>>> a lively and thriving community. > >> >>>>>> Sorry for the rant man, when llCastRay works, we found some really > >> >>>>>> beautiful things happening... > >> >>>>>> Ramesh > >> >>>>>> > >> >>>>>> > >> >>>>>> On Wed, Feb 26, 2014 at 7:46 AM, James Stallings II < > >> >>>>>> james.stalli...@gmail.com> wrote: > >> >>>>>> > >> >>>>>>> The key point being missed here is that OpenSim code is not > >> >>>>>>> 'frozen' > >> >>> or > >> >>>>>>> 'static' in any way. The llCastRay function is not exceptional in > >> >>> this > >> >>>>>>> respect; it could readily be extended (by someone knowledgeable in > >> >>> the > >> >>>>>>> subject area) to support the behavior that is anticipated based on > >> >>> the > >> >>>>>>> implementation in SL. > >> >>>>>>> > >> >>>>>>> Whether or not anyone participating in this discussion meets that > >> >>>>>>> description, it is quite likely that this will eventually happen; > >> >>>>>>> all > >> >>>>>>> that's required is a bit of patience and/or coding skill (depending > >> >>> on who > >> >>>>>>> you might be ;) > >> >>>>>>> > >> >>>>>>> Not to put too fine a point on it, but "...patches are welcome." > >> >>>>>>> For > >> >>> the > >> >>>>>>> rest of us, that translates as "Be patient." > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Cheers! > >> >>>>>>> James > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> On Tue, Feb 25, 2014 at 10:20 PM, Dahlia Trimble < > >> >>>>>>> dahliatrim...@gmail.com> wrote: > >> >>>>>>> > >> >>>>>>>> OpenSimulator currently only uses bounding boxes for llCastRay(), > >> >>>>>>>> regardless of the physics engine selected. Other collisions are > >> >>> computed in > >> >>>>>>>> the physics engine, and in the case of BulletSIm or ODE, are > >> >>> computed > >> >>>>>>>> against mesh triangles or convex hulls, and are usually quite > >> >>> accurate. > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On Tue, Feb 25, 2014 at 7:46 PM, Dr Ramesh Ramloll < > >> >>> r.raml...@gmail.com > >> >>>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>> Hello, are we to assume that opensim will only use bounding > >> >>>>>>>>> boxes > >> >>> for > >> >>>>>>>>> llCastRay or when detecting collisions? There are a lot of > >> >>> compelling > >> >>>>>>>>> applications that require the data for the point at which the ray > >> >>> hits the > >> >>>>>>>>> surface of a mesh object or for the point of collision on a mesh > >> >>> object. Is > >> >>>>>>>>> this one area where Second Life is definitely ahead because of > >> >>> Havok4? I am > >> >>>>>>>>> not very familiar with the underlying opensim infrastructure, so > >> >>> would be > >> >>>>>>>>> glad to hear more about this. > >> >>>>>>>>> Thanks > >> >>>>>>>>> R > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> On Tue, Feb 25, 2014 at 12:00 PM, Chris <mewtwo0...@gmail.com> > >> >>> wrote: > >> >>>>>>>>> > >> >>>>>>>>>> If I recall correctly, the default physics engine was switched > >> >>>>>>>>>> to > >> >>>>>>>>>> BulletSim some time ago although I can't recall when. Assuming > >> >>> recent code > >> >>>>>>>>>> is being used and also assuming the physics engine hadn't been > >> >>> switched > >> >>>>>>>>>> from default I would venture to say that BulletSim is likely > >> >>> being used, > >> >>>>>>>>>> but, that is just a guess on my part based on what I've seen and > >> >>>>>>>>>> experimented with myself; I have no idea what setup OSGrid is > >> >>> using since > >> >>>>>>>>>> it has been a while since I've ran a sim connected there. > >> >>>>>>>>>> > >> >>>>>>>>>> I haven't had a chance to test this myself on BulletSim but I > >> >>>>>>>>>> have > >> >>>>>>>>>> noticed some slight quirkiness with cast ray on some surfaces > >> >>> (especially > >> >>>>>>>>>> angled prims). I've not given it a full run on tests as I > >> >>>>>>>>>> haven't > >> >>> used the > >> >>>>>>>>>> cast ray functions all that much in my scripting. > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> On 2/25/2014 10:48 AM, Handy Low wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> Gwyneth Llewelyn <gwyneth.llewelyn <at> gwynethllewelyn.net> > >> >>> writes: > >> >>>>>>>>>>> > >> >>>>>>>>>>> Hi Handy, > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Just for the sake of completeness, did you test with ODE or > >> >>>>>>>>>>>> BulletSim? I > >> >>>>>>>>>>>> > >> >>>>>>>>>>> believe the implementation might be > >> >>>>>>>>>>> > >> >>>>>>>>>>>> slightly different (or, then again, it's just my > >> >>>>>>>>>>>> not-so-precise > >> >>>>>>>>>>>> testing). > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Thanks, > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> - Gwyn > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> On 25/02/2014, at 16:09, Handy Low wrote: > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Currently it seems that the OpenSim implementation of > >> >>> llCastRay() > >> >>>>>>>>>>>>> gives > >> >>>>>>>>>>>>> coordinates on a target object that lie on the bounding box > >> >>>>>>>>>>>>> of > >> >>> the > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>> object > >> >>>>>>>>>>> > >> >>>>>>>>>>>> rather than on the face of the prim itself. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> For example, casting a ray at a pair of linked cubes in > >> >>>>>>>>>>>>> OpenSim > >> >>>>>>>>>>>>> will > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>> generate > >> >>>>>>>>>>> > >> >>>>>>>>>>>> coordinates that lie on the cuboid bounding box that > >> >>>>>>>>>>>> constrains > >> >>> both > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>> cubes. > >> >>>>>>>>>>> > >> >>>>>>>>>>>> Likewise, casting a ray at a sphere will generate a point on > >> >>>>>>>>>>>> the > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>> sphere's > >> >>>>>>>>>>> > >> >>>>>>>>>>>> cubic bounding box. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> In SL, the same tests will both return points on the prim > >> >>> surfaces. > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Is this expected behaviour? > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>>> Thanks > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>> Thanks to Michael and Gwen for the fast replies. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Off the top of my head, I don't know which physics engine they > >> >>> were > >> >>>>>>>>>>> using, > >> >>>>>>>>>>> or how I can find out - the tests I've been doing have been in > >> >>> OSGrid > >> >>>>>>>>>>> (Sandbox Plaza) and in Kitely, if that's any help. > >> >>>>>>>>>>> > >> >>>>>>>>>>> -- > >> >>>>>>>>>>> Handy > >> >>>>>>>>>>> > >> >>>>>>>>>>> _______________________________________________ > >> >>>>>>>>>>> Opensim-users mailing list > >> >>>>>>>>>>> Opensim-users@lists.berlios.de > >> >>>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users > >> >>>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> -- > >> >>>>>>>>>> OpenSim: 10 Region Standalone on 0.7.6 Dev > >> >>>>>>>>>> Physics: Open Dynamics Engine > >> >>>>>>>>>> OS: Windows 7 (x64) > >> >>>>>>>>>> CPU: AMD Phenom II X4 840 3.2 GHz > >> >>>>>>>>>> Memory: 11 GB DDR3 > >> >>>>>>>>>> Database: MySQL 5.1.63 (x64) > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> _______________________________________________ > >> >>>>>>>>>> Opensim-users mailing list > >> >>>>>>>>>> Opensim-users@lists.berlios.de > >> >>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> -- > >> >>>>>>>>> 'Consider how the lilies grow. They do not labor or spin.' > >> >>>>>>>>> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate > >> >>> *Research > >> >>>>>>>>> Associate Professor*, Idaho State University, Pocatello, ID 83209 > >> >>>>>>>>> Tel: 208-240-0040 > >> >>>>>>>>> LinkedIn <http://www.linkedin.com/in/rameshramloll>, > >> >>> DeepSemaphore LLC<http://www.deepsemaphore.com>, > >> >>>>>>>>> RezMela <http://www.rezmela.com>, Google+ profile< > >> >>> https://plus.google.com/103652369558830540272/about> > >> >>>>>>>>> > >> >>>>>>>>> _______________________________________________ > >> >>>>>>>>> Opensim-users mailing list > >> >>>>>>>>> Opensim-users@lists.berlios.de > >> >>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> Opensim-users mailing list > >> >>>>>>>> Opensim-users@lists.berlios.de > >> >>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users > >> >>>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> -- > >> >>>>>>> =================================== > >> >>>>>>> http://osgrid.org/ > >> >>>>>>> http://simhost.com > >> >>>>>>> http://twitter.com/jstallings2 > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> _______________________________________________ > >> >>>>>>> Opensim-users mailing list > >> >>>>>>> Opensim-users@lists.berlios.de > >> >>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users > >> >>>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> -- > >> >>>>>> 'Consider how the lilies grow. They do not labor or spin.' > >> >>>>>> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate > >> >>> *Research > >> >>>>>> Associate Professor*, Idaho State University, Pocatello, ID 83209 > >> >>>>>> Tel: > >> >>>>>> 208-240-0040 > >> >>>>>> LinkedIn <http://www.linkedin.com/in/rameshramloll>, DeepSemaphore > >> >>> LLC<http://www.deepsemaphore.com>, > >> >>>>>> RezMela <http://www.rezmela.com>, Google+ profile< > >> >>> https://plus.google.com/103652369558830540272/about> > >> >>>>>> > >> >>>>>> _______________________________________________ > >> >>>>>> Opensim-users mailing list > >> >>>>>> Opensim-users@lists.berlios.de > >> >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users > >> >>>>>> > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> Opensim-users mailing list > >> >>>>> Opensim-users@lists.berlios.de > >> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-users > >> >>>>> > >> >>> -- > >> >>> Handy Low > >> >>> > >> >>> _______________________________________________ > >> >>> Opensim-users mailing list > >> >>> Opensim-users@lists.berlios.de > >> >>> https://lists.berlios.de/mailman/listinfo/opensim-users > >> >>> > >> > -- > >> > Handy Low > >> > > >> > _______________________________________________ > >> > Opensim-users mailing list > >> > Opensim-users@lists.berlios.de > >> > https://lists.berlios.de/mailman/listinfo/opensim-users > > -- > > Handy Low > > > > _______________________________________________ > > Opensim-users mailing list > > Opensim-users@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-users -- Handy Low _______________________________________________ Opensim-users mailing list Opensim-users@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-users
