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 <[email protected]> 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 < > > [email protected]> 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" <[email protected]> > 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 < > > >> [email protected]> 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 < > > >>> [email protected]> 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 < > [email protected] > > >>>> > 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 <[email protected]> > 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 > > >>>>>>> [email protected] > > >>>>>>> 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 > > >>>>>> [email protected] > > >>>>>> 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 > > >>>>> [email protected] > > >>>>> https://lists.berlios.de/mailman/listinfo/opensim-users > > >>>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Opensim-users mailing list > > >>>> [email protected] > > >>>> https://lists.berlios.de/mailman/listinfo/opensim-users > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> =================================== > > >>> http://osgrid.org/ > > >>> http://simhost.com > > >>> http://twitter.com/jstallings2 > > >>> > > >>> > > >>> _______________________________________________ > > >>> Opensim-users mailing list > > >>> [email protected] > > >>> 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 > > >> [email protected] > > >> https://lists.berlios.de/mailman/listinfo/opensim-users > > >> > > > > > > _______________________________________________ > > > Opensim-users mailing list > > > [email protected] > > > https://lists.berlios.de/mailman/listinfo/opensim-users > > > > -- > Handy Low > > _______________________________________________ > Opensim-users mailing list > [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
