[Opensim-users] llCastRay and object shapes

Thu Feb 27 02:20:02 UTC 2014

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.systems at 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.stallings at 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.ramloll at 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.stallings at 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 <
> > >>> dahliatrimble at 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.ramloll at 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 <mewtwo0641 at 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 at 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 at 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 at lists.berlios.de
> > >>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> > >>>>>
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> Opensim-users mailing list
> > >>>> Opensim-users at 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 at 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 at lists.berlios.de
> > >> https://lists.berlios.de/mailman/listinfo/opensim-users
> > >>
> > >
> > > _______________________________________________
> > > Opensim-users mailing list
> > > Opensim-users at lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/opensim-users
> > >
> --
> Handy Low
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20140227/90d0408e/attachment.html>