Thanks Dahlia! That level of detail provides a lot of insight into this issue.
Thanks for that part which you did implement, some functionality is always better than none ;) Also thank you for your willingness to support those who might move the work forward. Cheers! James On Feb 26, 2014 3:43 PM, "Dahlia Trimble" <dahliatrim...@gmail.com> 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 >> > > > _______________________________________________ > 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
