<div dir="ltr">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<div>
<br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div><br></div><div> - Gwyn</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 February 2014 01:34, Handy Low <span dir="ltr"><<a href="mailto:handy.low.systems@gmail.com" target="_blank">handy.low.systems@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A very helpful explanation - thanks.<br>
<br>
Perhaps you could shed some light on the way the collision code works,<br>
particularly in regard to a physical projectile (a bullet) being fired<br>
at a scripted prim?<br>
<br>
The script inside the target prim reacts to collision_start() events,<br>
but these only seem to be triggered in some cases, depending on the<br>
shape of the prim, the velocity of the bullet, and even (it seems) the<br>
distance the bullet has travelled.<br>
<br>
Is there anything I can do to increase the likelihood of the event<br>
being triggered, other than those factors? I'm seeing large cylinder<br>
prims needing bullets travelling as slowly as 2m/s.<br>
<br>
Thanks.<br>
<br>
Dahlia Trimble wrote:<br>
<br>
> FWIW...<br>
><br>
> I'm the one who wrote most of the collision geometry code in OpenSimulator.<br>
> Someone else wrote llCastRay(). From my understanding and from memory of<br>
> past conversations, the author(s) of llCastRay implemented what they could<br>
> given the constraints of object accessibility in the core OpenSimulator and<br>
> timing needs of llCastRay. Bounding boxes are easier to get to than the<br>
> geometry, which is usually passed to the physics engine of choice from a<br>
> manager object which is generally inaccessible. There is a way to ask ODE<br>
> to do a raycast against geometry, however, it requires a time delay between<br>
> physics frames as the requests must be queued and the responses retrieved<br>
> on the next frame. I was told this is an unacceptable delay although I did<br>
> not research it any further to see if this is really the case. I'm not sure<br>
> if Bullet has the same capability but I'd be surprised if it didn't.<br>
><br>
> I'm not sure about other devs, but in my case the reason I have not<br>
> implemented a more accurate llCastRay() is that I don't get paid for my<br>
> contributions to OpenSimulator and hence I usually don't implement anything<br>
> unless I need it and nobody else will do it. Often (but not always) when I<br>
> do implement such features I choose to share them with the community by<br>
> committing them to core, as I believe this is how open source works: many<br>
> people contribute and the whole becomes greater than the sum of the parts.<br>
> Unfortunately I have no need for llCastRay() at this time and I am pretty<br>
> busy so I probably wont be considering improving it for quite some time, if<br>
> ever. However, I am willing to share my insights about collision geometry<br>
> with others who would endeavor to implement it.<br>
><br>
><br>
> On Wed, Feb 26, 2014 at 6:07 AM, James Stallings II <<br>
> <a href="mailto:james.stallings@gmail.com">james.stallings@gmail.com</a>> wrote:<br>
><br>
> > My apologies if you found my contribution discouraging; my intent was<br>
> > exactly the opposite. To be quite explicit, I encourage anyone who can<br>
> > improve this functionality to do so; for the rest of us, we must have faith<br>
> > that those who can contribute to the improvement of the code, eventually<br>
> > will.<br>
> ><br>
> > My experience has been that some things are more difficult than others to<br>
> > accomplish; and OpenSim devs, despite myth and appearances, are human too<br>
> > ;)<br>
> ><br>
> > Implementations of these things often happen in stages. First some<br>
> > groundwork is laid, and then improvements are added incrementally. I rather<br>
> > suspect that will be and has been the case as concerns llCastRay. First the<br>
> > framework is established simply with bounding boxes; then projection of the<br>
> > bounding box intersection onto the mesh, etc. It's even fairly likely that<br>
> > one will finish what another has begun, though it is not always the case.<br>
> ><br>
> > I think the point is, we all know what the ideal functionality of<br>
> > llCastRay is; and we all know it's desirable to have that functionality. My<br>
> > message is, it will eventually happen, and if we are not in a position to<br>
> > do it ourselves (I know I'm not in such a position), the best we can do is<br>
> > have a little faith, note the current behavior, and watch for improvements.<br>
> ><br>
> > A well phrased mantis is always good, as it keeps the need for improvement<br>
> > in view of the devs; but complaints about lack of functionality on mailing<br>
> > lists rarely do more than rub people the wrong way; the very people who<br>
> > will likely improve the code. This is something that has taken me YEARS to<br>
> > get through my thick skull; which is why I rarely post to this list these<br>
> > days ;)<br>
> ><br>
> > In any case, don't let me slow your roll :)<br>
> ><br>
> ><br>
> > Cheers<br>
> ><br>
> > James<br>
> ><br>
> ><br>
> > On Feb 26, 2014 7:26 AM, "Dr Ramesh Ramloll" <<a href="mailto:r.ramloll@gmail.com">r.ramloll@gmail.com</a>> wrote:<br>
> ><br>
> >> Hi James,<br>
> >> It is important for user to make their needs known. Often optimization<br>
> >> decisions for invisible underlying important stuff are made that may impact<br>
> >> user needs at the top. It is crucial here for users not to be discouraged<br>
> >> to voice their opinions in a civil way (which I think we were doing). Some<br>
> >> things may be needed at the top user level but can cannot be implemented<br>
> >> because it would mess up underlying thing that is important. I do<br>
> >> understand that, designing complex systems is almost always about comprise.<br>
> >> In this case, a bounding box may have been opted for may be because it is<br>
> >> faster for scenes containing large number of objects (and less error prone<br>
> >> than for complex shapes)... and it could be that a decision was made to<br>
> >> sacrifice precision of values returned by llCastRay for speed and that<br>
> >> would be understandable. In short, most people are mature enough to know<br>
> >> that competing concerns arise often and is typical, BUT stakeholders have<br>
> >> the right to try to influence direction and motivate development ...<br>
> >> hopefully statements in that regard would not be viewed as a sign of<br>
> >> "impatience".<br>
> >> Hence the need for conversation... certainly 'keep quiet while we work<br>
> >> patiently in the background' or 'why don't YOU do it?' is not a feature of<br>
> >> a lively and thriving community.<br>
> >> Sorry for the rant man, when llCastRay works, we found some really<br>
> >> beautiful things happening...<br>
> >> Ramesh<br>
> >><br>
> >><br>
> >> On Wed, Feb 26, 2014 at 7:46 AM, James Stallings II <<br>
> >> <a href="mailto:james.stallings@gmail.com">james.stallings@gmail.com</a>> wrote:<br>
> >><br>
> >>> The key point being missed here is that OpenSim code is not 'frozen' or<br>
> >>> 'static' in any way. The llCastRay function is not exceptional in this<br>
> >>> respect; it could readily be extended (by someone knowledgeable in the<br>
> >>> subject area) to support the behavior that is anticipated based on the<br>
> >>> implementation in SL.<br>
> >>><br>
> >>> Whether or not anyone participating in this discussion meets that<br>
> >>> description, it is quite likely that this will eventually happen; all<br>
> >>> that's required is a bit of patience and/or coding skill (depending on who<br>
> >>> you might be ;)<br>
> >>><br>
> >>> Not to put too fine a point on it, but "...patches are welcome." For the<br>
> >>> rest of us, that translates as "Be patient."<br>
> >>><br>
> >>><br>
> >>> Cheers!<br>
> >>> James<br>
> >>><br>
> >>><br>
> >>> On Tue, Feb 25, 2014 at 10:20 PM, Dahlia Trimble <<br>
> >>> <a href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a>> wrote:<br>
> >>><br>
> >>>> OpenSimulator currently only uses bounding boxes for llCastRay(),<br>
> >>>> regardless of the physics engine selected. Other collisions are computed in<br>
> >>>> the physics engine, and in the case of BulletSIm or ODE, are computed<br>
> >>>> against mesh triangles or convex hulls, and are usually quite accurate.<br>
> >>>><br>
> >>>><br>
> >>>> On Tue, Feb 25, 2014 at 7:46 PM, Dr Ramesh Ramloll <<a href="mailto:r.ramloll@gmail.com">r.ramloll@gmail.com</a><br>
> >>>> > wrote:<br>
> >>>><br>
> >>>>> Hello, are we to assume that opensim will only use bounding boxes for<br>
> >>>>> llCastRay or when detecting collisions? There are a lot of compelling<br>
> >>>>> applications that require the data for the point at which the ray hits the<br>
> >>>>> surface of a mesh object or for the point of collision on a mesh object. Is<br>
> >>>>> this one area where Second Life is definitely ahead because of Havok4? I am<br>
> >>>>> not very familiar with the underlying opensim infrastructure, so would be<br>
> >>>>> glad to hear more about this.<br>
> >>>>> Thanks<br>
> >>>>> R<br>
> >>>>><br>
> >>>>><br>
> >>>>> On Tue, Feb 25, 2014 at 12:00 PM, Chris <<a href="mailto:mewtwo0641@gmail.com">mewtwo0641@gmail.com</a>> wrote:<br>
> >>>>><br>
> >>>>>> If I recall correctly, the default physics engine was switched to<br>
> >>>>>> BulletSim some time ago although I can't recall when. Assuming recent code<br>
> >>>>>> is being used and also assuming the physics engine hadn't been switched<br>
> >>>>>> from default I would venture to say that BulletSim is likely being used,<br>
> >>>>>> but, that is just a guess on my part based on what I've seen and<br>
> >>>>>> experimented with myself; I have no idea what setup OSGrid is using since<br>
> >>>>>> it has been a while since I've ran a sim connected there.<br>
> >>>>>><br>
> >>>>>> I haven't had a chance to test this myself on BulletSim but I have<br>
> >>>>>> noticed some slight quirkiness with cast ray on some surfaces (especially<br>
> >>>>>> angled prims). I've not given it a full run on tests as I haven't used the<br>
> >>>>>> cast ray functions all that much in my scripting.<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> On 2/25/2014 10:48 AM, Handy Low wrote:<br>
> >>>>>><br>
> >>>>>>> Gwyneth Llewelyn <gwyneth.llewelyn <at> <a href="http://gwynethllewelyn.net" target="_blank">gwynethllewelyn.net</a>> writes:<br>
> >>>>>>><br>
> >>>>>>> Hi Handy,<br>
> >>>>>>>><br>
> >>>>>>>> Just for the sake of completeness, did you test with ODE or<br>
> >>>>>>>> BulletSim? I<br>
> >>>>>>>><br>
> >>>>>>> believe the implementation might be<br>
> >>>>>>><br>
> >>>>>>>> slightly different (or, then again, it's just my not-so-precise<br>
> >>>>>>>> testing).<br>
> >>>>>>>><br>
> >>>>>>>> Thanks,<br>
> >>>>>>>><br>
> >>>>>>>> - Gwyn<br>
> >>>>>>>><br>
> >>>>>>>> On 25/02/2014, at 16:09, Handy Low wrote:<br>
> >>>>>>>><br>
> >>>>>>>> Currently it seems that the OpenSim implementation of llCastRay()<br>
> >>>>>>>>> gives<br>
> >>>>>>>>> coordinates on a target object that lie on the bounding box of the<br>
> >>>>>>>>><br>
> >>>>>>>> object<br>
> >>>>>>><br>
> >>>>>>>> rather than on the face of the prim itself.<br>
> >>>>>>>>><br>
> >>>>>>>>> For example, casting a ray at a pair of linked cubes in OpenSim<br>
> >>>>>>>>> will<br>
> >>>>>>>>><br>
> >>>>>>>> generate<br>
> >>>>>>><br>
> >>>>>>>> coordinates that lie on the cuboid bounding box that constrains both<br>
> >>>>>>>>><br>
> >>>>>>>> cubes.<br>
> >>>>>>><br>
> >>>>>>>> Likewise, casting a ray at a sphere will generate a point on the<br>
> >>>>>>>>><br>
> >>>>>>>> sphere's<br>
> >>>>>>><br>
> >>>>>>>> cubic bounding box.<br>
> >>>>>>>>><br>
> >>>>>>>>> In SL, the same tests will both return points on the prim surfaces.<br>
> >>>>>>>>><br>
> >>>>>>>>> Is this expected behaviour?<br>
> >>>>>>>>><br>
> >>>>>>>>> Thanks<br>
> >>>>>>>>><br>
> >>>>>>>> Thanks to Michael and Gwen for the fast replies.<br>
> >>>>>>><br>
> >>>>>>> Off the top of my head, I don't know which physics engine they were<br>
> >>>>>>> using,<br>
> >>>>>>> or how I can find out - the tests I've been doing have been in OSGrid<br>
> >>>>>>> (Sandbox Plaza) and in Kitely, if that's any help.<br>
> >>>>>>><br>
> >>>>>>> --<br>
> >>>>>>> Handy<br>
> >>>>>>><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>
> >>>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> --<br>
> >>>>>> OpenSim: 10 Region Standalone on 0.7.6 Dev<br>
> >>>>>> Physics: Open Dynamics Engine<br>
> >>>>>> OS: Windows 7 (x64)<br>
> >>>>>> CPU: AMD Phenom II X4 840 3.2 GHz<br>
> >>>>>> Memory: 11 GB DDR3<br>
> >>>>>> Database: MySQL 5.1.63 (x64)<br>
> >>>>>><br>
> >>>>>><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>
> >>>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> --<br>
> >>>>> 'Consider how the lilies grow. They do not labor or spin.'<br>
> >>>>> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research<br>
> >>>>> Associate Professor*, Idaho State University, Pocatello, ID 83209<br>
> >>>>> Tel: <a href="tel:208-240-0040" value="+12082400040">208-240-0040</a><br>
> >>>>> LinkedIn <<a href="http://www.linkedin.com/in/rameshramloll" target="_blank">http://www.linkedin.com/in/rameshramloll</a>>, DeepSemaphore LLC<<a href="http://www.deepsemaphore.com" target="_blank">http://www.deepsemaphore.com</a>>,<br>
> >>>>> RezMela <<a href="http://www.rezmela.com" target="_blank">http://www.rezmela.com</a>>, Google+ profile<<a href="https://plus.google.com/103652369558830540272/about" target="_blank">https://plus.google.com/103652369558830540272/about</a>><br>
> >>>>><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>
> >>>>><br>
> >>>><br>
> >>>><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>
> >>>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> --<br>
> >>> ===================================<br>
> >>> <a href="http://osgrid.org/" target="_blank">http://osgrid.org/</a><br>
> >>> <a href="http://simhost.com" target="_blank">http://simhost.com</a><br>
> >>> <a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br>
> >>><br>
> >>><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>
> >>><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> 'Consider how the lilies grow. They do not labor or spin.'<br>
> >> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research<br>
> >> Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel:<br>
> >> <a href="tel:208-240-0040" value="+12082400040">208-240-0040</a><br>
> >> LinkedIn <<a href="http://www.linkedin.com/in/rameshramloll" target="_blank">http://www.linkedin.com/in/rameshramloll</a>>, DeepSemaphore LLC<<a href="http://www.deepsemaphore.com" target="_blank">http://www.deepsemaphore.com</a>>,<br>
> >> RezMela <<a href="http://www.rezmela.com" target="_blank">http://www.rezmela.com</a>>, Google+ profile<<a href="https://plus.google.com/103652369558830540272/about" target="_blank">https://plus.google.com/103652369558830540272/about</a>><br>
> >><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>
> >><br>
> ><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>
> ><br>
<span class="HOEnZb"><font color="#888888">--<br>
Handy Low<br>
<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>
</font></span></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>