[Opensim-users] llCastRay and object shapes

Wed Feb 26 13:26:06 UTC 2014

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20140226/129272bd/attachment.html>