llCastRay and object shapes

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

llCastRay and object shapes

Handy Low
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

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Michael Emory Cerquoni
This is currently the level of functionality one should expect from OpenSimulator raycasting functions, it would be nice to eventually make this work better so we can use it on cut and hollowed shapes and get much better accuracy.


On Tue, Feb 25, 2014 at 11:09 AM, Handy Low <[hidden email]> 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

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users



--
Michael Emory Cerquoni

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Gwyneth Llewelyn
In reply to this post by Handy Low
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
>
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-users

_______________________________________________
Opensim-users mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Handy Low
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
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Chris M
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
> [hidden email]
> 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
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Dr Ramesh Ramloll
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Dahlia Trimble
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

James Stallings II
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users



--

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Dr Ramesh Ramloll
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users



--

_______________________________________________
Opensim-users mailing list
[hidden email]
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

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

James Stallings II

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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users



--

_______________________________________________
Opensim-users mailing list
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Dahlia Trimble
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users



--

_______________________________________________
Opensim-users mailing list
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

James Stallings II

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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users



--

_______________________________________________
Opensim-users mailing list
[hidden email]
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: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Handy Low
In reply to this post by Dahlia Trimble
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 <
> [hidden email]> 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" <[hidden email]> 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 <
> >> [hidden email]> 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 <
> >>> [hidden email]> 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 <[hidden email]
> >>>> > 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 <[hidden email]> 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
> >>>>>>> [hidden email]
> >>>>>>> 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
> >>>>>> [hidden email]
> >>>>>> 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
> >>>>> [hidden email]
> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Opensim-users mailing list
> >>>> [hidden email]
> >>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> ===================================
> >>> http://osgrid.org/
> >>> http://simhost.com
> >>> http://twitter.com/jstallings2
> >>>
> >>>
> >>> _______________________________________________
> >>> Opensim-users mailing list
> >>> [hidden email]
> >>> 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
> >> [hidden email]
> >> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>
> >
> > _______________________________________________
> > Opensim-users mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/opensim-users
> >
--
Handy Low

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Gwyneth Llewelyn
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 <[hidden email]> 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 <
> [hidden email]> 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" <[hidden email]> 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 <
> >> [hidden email]> 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 <
> >>> [hidden email]> 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 <[hidden email]
> >>>> > 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 <[hidden email]> 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
> >>>>>>> [hidden email]
> >>>>>>> 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
> >>>>>> [hidden email]
> >>>>>> 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: <a href="tel:208-240-0040" value="+12082400040">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
> >>>>> [hidden email]
> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Opensim-users mailing list
> >>>> [hidden email]
> >>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> ===================================
> >>> http://osgrid.org/
> >>> http://simhost.com
> >>> http://twitter.com/jstallings2
> >>>
> >>>
> >>> _______________________________________________
> >>> Opensim-users mailing list
> >>> [hidden email]
> >>> 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:
> >> <a href="tel:208-240-0040" value="+12082400040">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
> >> [hidden email]
> >> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>
> >
> > _______________________________________________
> > Opensim-users mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/opensim-users
> >
--
Handy Low

_______________________________________________
Opensim-users mailing list
[hidden email]
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
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Handy Low
Hi Gwyn (sorry for misspelling your name up-thread)

One thing I've discovered through testing is that the size of the
projectile also makes a difference. If I increase the length of my
bullets to a metre or two in the direction of travel, they fire the
collision events every time (at least so far in my testing). The
bullets do need to be that actual length too - "cheats" like
path-cutting and slicing to hide the size will reduce the detection
rate again.

The workaround that I favour involves firing two bullets - a normal,
small one and a long, invisible one - the target object can use a
collision filter by name to avoid detecting both.

I was wondering if that workaround would help in your case - make the
attachment large (at least in the appropriate direction) but partly
invisible?

Gwyneth Llewelyn wrote:

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

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Gwyneth Llewelyn
Hi Handy,

Interesting — 'size matters' :-) Actually, I suspected that a small attachment might have some issues, so I've been consistently using huge transparent attachments (boxes or spheres... or even pyramids, which sort of 'flare out' in the direction that is more interesting, as you suggest) which completely encloses a normal-sized avatar (so they would have a volume of at least 2 x 2 x 2 m).

However, as much as I understand the underlying code — which is not much — this shouldn't actually make any difference. Per SL specifications, an attachment detecting collisions will not detect collisions *with the attached prim's bounding box* but *with the avatar's bounding box*. This is a major difference between detecting collisions inside prims — when they're attached, collisions *by the avatar* are passed to the scripts *inside the attached prim*. When they're unattached, the physics engine uses the prim's bounding box. Actually, the code dealing with collisions with attachments is in there! There are a lot of interesting checks at the avatar-collision level (both at the abstraction level but even further down on the interface with the physics engine) to see if llVolumeDetect() has been called or not, if an avatar has a scripted attachment that has signaled the simulator to receive collision events, and so forth. A *lot* of work has been put into this, and, as far as I can understand the very convoluted way this is supposed to work, the algorithm seems to be conceptually sound. What I mean is that every time an avatar collides with 'something' (and, again, notice that this will be a check made using the avatar's bounding box, not the attachment's) there are, indeed, checks being done to see if the avatar has a scripted attachment and if it has registered itself to receive collision events. The code is there, it just doesn't work... most of the time. Just the fact that it DOES, indeed, work SOME of the time, tends to make me believe that there are some timing issues involved, of which I haven't been aware, and have no idea where to start looking for those timers. Maybe these low-level collision events have to be enqueued somehow, to avoid getting 'lost', and thus might need to be retrieved later at a much higher and more abstract level (e.g. the virtual machine running the LSL bytecode...). I have not the faintest clue on how this can be programmed.

I didn't wish to 'steal' the thread, but rather explain that the very tempting, but naive alternative to llCastRay() to detect where a bullet might hit an avatar is very tempting: get an avatar with lots of attachments, and try to detect those attachments with llCastRay()... or fire real, invisible bullets expecting the attachments (one per body part) to respond, depending on which one was hit, and feed that information to a central location... aye, all these are theoretical workarounds, but none of them will actually work. Following SL's inspiration, a collision event *of the avatar with something else* will be sent to *all* attachments simultaneously (or, in the case of OpenSim, to none at all...). Of course, when it works, you'll get some positioning information, and while this is not highly accurate, at least you could figure out if the avatar has been hit/detected/collided with something at the front, behind, sides, upper part, lower part, etc...

Well, it's such a pity that the few people who actually understand the very intricate and convoluted code are uninterested in collecting data about the environment and feeding it to LSL. For others, specially my case (I do research on intelligent agents...), this means that NPCs are blind as bats and, worse, do not even 'feel' anything when they bump into things :)

Ah, note that *some* collision information gets passed on to the viewer, because the viewer will need to know where to apply those neat special effects during a collision (playing sounds, showing some textures, etc.). Ironically, these work actually quite well, and even show up relatively accurately, but I have not the faintest idea on where those messages are being generated and how they're passed to the viewer! (As much as I've looked into libopenmetaverse, there seems to be little interest in getting those 'collision hints', since, well, most libopenmetaverse applications are text-base and do not pass visual clues back to the user...).

Sorry for the long rant. I'm actually in the middle of writing some things about OpenSimulator and why some crucial functionality is not only missing, but workarounds are next-to-impossible, and implementing the missing functionality — as time passes and OpenSimulator becomes more and more complex — take so much time. I envy the volunteers who managed to do those zillions of code in their spare time. It is the equivalent of several lifetimes to replicate that :) ... and a considerable amount of a lifetime just to understand enough of it to fix a tiny bug :)

Cheers,

        - Gwyn

On 27/02/2014, at 17:13, Handy Low wrote:

> Hi Gwyn (sorry for misspelling your name up-thread)
>
> One thing I've discovered through testing is that the size of the
> projectile also makes a difference. If I increase the length of my
> bullets to a metre or two in the direction of travel, they fire the
> collision events every time (at least so far in my testing). The
> bullets do need to be that actual length too - "cheats" like
> path-cutting and slicing to hide the size will reduce the detection
> rate again.
>
> The workaround that I favour involves firing two bullets - a normal,
> small one and a long, invisible one - the target object can use a
> collision filter by name to avoid detecting both.
>
> I was wondering if that workaround would help in your case - make the
> attachment large (at least in the appropriate direction) but partly
> invisible?
>
> Gwyneth Llewelyn wrote:
>
>> 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 <[hidden email]> 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 <
>>>> [hidden email]> 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" <[hidden email]>
>>> 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 <
>>>>>> [hidden email]> 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 <
>>>>>>> [hidden email]> 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 <
>>> [hidden email]
>>>>>>>>> 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 <[hidden email]>
>>> 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
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Opensim-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ===================================
>>>>>>> http://osgrid.org/
>>>>>>> http://simhost.com
>>>>>>> http://twitter.com/jstallings2
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Opensim-users mailing list
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-users mailing list
>>>>> [hidden email]
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>>>>
>>> --
>>> Handy Low
>>>
>>> _______________________________________________
>>> Opensim-users mailing list
>>> [hidden email]
>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>>
> --
> Handy Low
>
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-users

_______________________________________________
Opensim-users mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Handy Low
Oh, you certainly didn't steal the thread. All this is part of the
same investigation I'd been doing, even if attachments weren't on my
particular agenda at the moment.

And it's always seemed to me to be the nature of volunteer projects,
that quite understandably people usually work on what interests them.

Certainly I'm hugely grateful to all the volunteers and commercial
contributors alike who've made OpenSim what it is.

Gwyneth Llewelyn wrote:

> Hi Handy,
>
> Interesting — 'size matters' :-) Actually, I suspected that a small attachment might have some issues, so I've been consistently using huge transparent attachments (boxes or spheres... or even pyramids, which sort of 'flare out' in the direction that is more interesting, as you suggest) which completely encloses a normal-sized avatar (so they would have a volume of at least 2 x 2 x 2 m).
>
> However, as much as I understand the underlying code — which is not much — this shouldn't actually make any difference. Per SL specifications, an attachment detecting collisions will not detect collisions *with the attached prim's bounding box* but *with the avatar's bounding box*. This is a major difference between detecting collisions inside prims — when they're attached, collisions *by the avatar* are passed to the scripts *inside the attached prim*. When they're unattached, the physics engine uses the prim's bounding box. Actually, the code dealing with collisions with attachments is in there! There are a lot of interesting checks at the avatar-collision level (both at the abstraction level but even further down on the interface with the physics engine) to see if llVolumeDetect() has been called or not, if an avatar has a scripted attachment that has signaled the simulator to receive collision events, and so forth. A *lot* of work has been put into this, and, as far as I can
> understand the very convoluted way this is supposed to work, the algorithm seems to be conceptually sound. What I mean is that every time an avatar collides with 'something' (and, again, notice that this will be a check made using the avatar's bounding box, not the attachment's) there are, indeed, checks being done to see if the avatar has a scripted attachment and if it has registered itself to receive collision events. The code is there, it just doesn't work... most of the time. Just the fact that it DOES, indeed, work SOME of the time, tends to make me believe that there are some timing issues involved, of which I haven't been aware, and have no idea where to start looking for those timers. Maybe these low-level collision events have to be enqueued somehow, to avoid getting 'lost', and thus might need to be retrieved later at a much higher and more abstract level (e.g. the virtual machine running the LSL bytecode...). I have not the faintest clue on how this can be programmed.
>
> I didn't wish to 'steal' the thread, but rather explain that the very tempting, but naive alternative to llCastRay() to detect where a bullet might hit an avatar is very tempting: get an avatar with lots of attachments, and try to detect those attachments with llCastRay()... or fire real, invisible bullets expecting the attachments (one per body part) to respond, depending on which one was hit, and feed that information to a central location... aye, all these are theoretical workarounds, but none of them will actually work. Following SL's inspiration, a collision event *of the avatar with something else* will be sent to *all* attachments simultaneously (or, in the case of OpenSim, to none at all...). Of course, when it works, you'll get some positioning information, and while this is not highly accurate, at least you could figure out if the avatar has been hit/detected/collided with something at the front, behind, sides, upper part, lower part, etc...
>
> Well, it's such a pity that the few people who actually understand the very intricate and convoluted code are uninterested in collecting data about the environment and feeding it to LSL. For others, specially my case (I do research on intelligent agents...), this means that NPCs are blind as bats and, worse, do not even 'feel' anything when they bump into things :)
>
> Ah, note that *some* collision information gets passed on to the viewer, because the viewer will need to know where to apply those neat special effects during a collision (playing sounds, showing some textures, etc.). Ironically, these work actually quite well, and even show up relatively accurately, but I have not the faintest idea on where those messages are being generated and how they're passed to the viewer! (As much as I've looked into libopenmetaverse, there seems to be little interest in getting those 'collision hints', since, well, most libopenmetaverse applications are text-base and do not pass visual clues back to the user...).
>
> Sorry for the long rant. I'm actually in the middle of writing some things about OpenSimulator and why some crucial functionality is not only missing, but workarounds are next-to-impossible, and implementing the missing functionality — as time passes and OpenSimulator becomes more and more complex — take so much time. I envy the volunteers who managed to do those zillions of code in their spare time. It is the equivalent of several lifetimes to replicate that :) ... and a considerable amount of a lifetime just to understand enough of it to fix a tiny bug :)
>
> Cheers,
>
> - Gwyn
>
> On 27/02/2014, at 17:13, Handy Low wrote:
>
> > Hi Gwyn (sorry for misspelling your name up-thread)
> >
> > One thing I've discovered through testing is that the size of the
> > projectile also makes a difference. If I increase the length of my
> > bullets to a metre or two in the direction of travel, they fire the
> > collision events every time (at least so far in my testing). The
> > bullets do need to be that actual length too - "cheats" like
> > path-cutting and slicing to hide the size will reduce the detection
> > rate again.
> >
> > The workaround that I favour involves firing two bullets - a normal,
> > small one and a long, invisible one - the target object can use a
> > collision filter by name to avoid detecting both.
> >
> > I was wondering if that workaround would help in your case - make the
> > attachment large (at least in the appropriate direction) but partly
> > invisible?
> >
> > Gwyneth Llewelyn wrote:
> >
> >> 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 <[hidden email]> 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 <
> >>>> [hidden email]> 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" <[hidden email]>
> >>> 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 <
> >>>>>> [hidden email]> 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 <
> >>>>>>> [hidden email]> 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 <
> >>> [hidden email]
> >>>>>>>>> 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 <[hidden email]>
> >>> 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
> >>>>>>>>>>> [hidden email]
> >>>>>>>>>>> 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
> >>>>>>>>>> [hidden email]
> >>>>>>>>>> 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
> >>>>>>>>> [hidden email]
> >>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Opensim-users mailing list
> >>>>>>>> [hidden email]
> >>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> ===================================
> >>>>>>> http://osgrid.org/
> >>>>>>> http://simhost.com
> >>>>>>> http://twitter.com/jstallings2
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Opensim-users mailing list
> >>>>>>> [hidden email]
> >>>>>>> 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
> >>>>>> [hidden email]
> >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Opensim-users mailing list
> >>>>> [hidden email]
> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>>>
> >>> --
> >>> Handy Low
> >>>
> >>> _______________________________________________
> >>> Opensim-users mailing list
> >>> [hidden email]
> >>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >>>
> > --
> > Handy Low
> >
> > _______________________________________________
> > Opensim-users mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/opensim-users
--
Handy Low

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Teravus Ovares
Just a note...   it's probably nothing..   however..  a bit of history
on llcastray in OpenSimulator....  I wrote the obb collision detection
being used for llcastray currently.   It wasn't actually intended to
be used in llcastray...  it was intended to be used to raycast against
objects when rezzing cubes and objects.  It was also designed to
handle things like 'duplicate on ray'.    Anyway... .   Melanie_T
thought that the system needed a physics independent implementation of
llcastray and so made use of the OBB raycast that is used for rezzing
for llcastray.    That said, there are now physics interface APIs that
can be used to replace the physics independent llcastray method being
used now.  The physics layer needs to set a property for if it can
handle raycast requests to true and it needs to implement that part of
the OpenSimulator physics API.

For more information, go to the bottom of this file:
https://github.com/nebadon2025/opensimulator/blob/master/OpenSim/Region/Physics/Manager/PhysicsScene.cs

Best Regards

Teravus

On Fri, Feb 28, 2014 at 3:36 PM, Handy Low <[hidden email]> wrote:

> Oh, you certainly didn't steal the thread. All this is part of the
> same investigation I'd been doing, even if attachments weren't on my
> particular agenda at the moment.
>
> And it's always seemed to me to be the nature of volunteer projects,
> that quite understandably people usually work on what interests them.
>
> Certainly I'm hugely grateful to all the volunteers and commercial
> contributors alike who've made OpenSim what it is.
>
> Gwyneth Llewelyn wrote:
>
>> Hi Handy,
>>
>> Interesting -- 'size matters' :-) Actually, I suspected that a small attachment might have some issues, so I've been consistently using huge transparent attachments (boxes or spheres... or even pyramids, which sort of 'flare out' in the direction that is more interesting, as you suggest) which completely encloses a normal-sized avatar (so they would have a volume of at least 2 x 2 x 2 m).
>>
>> However, as much as I understand the underlying code -- which is not much -- this shouldn't actually make any difference. Per SL specifications, an attachment detecting collisions will not detect collisions *with the attached prim's bounding box* but *with the avatar's bounding box*. This is a major difference between detecting collisions inside prims -- when they're attached, collisions *by the avatar* are passed to the scripts *inside the attached prim*. When they're unattached, the physics engine uses the prim's bounding box. Actually, the code dealing with collisions with attachments is in there! There are a lot of interesting checks at the avatar-collision level (both at the abstraction level but even further down on the interface with the physics engine) to see if llVolumeDetect() has been called or not, if an avatar has a scripted attachment that has signaled the simulator to receive collision events, and so forth. A *lot* of work has been put into this, and, as far
  as I can
>> understand the very convoluted way this is supposed to work, the algorithm seems to be conceptually sound. What I mean is that every time an avatar collides with 'something' (and, again, notice that this will be a check made using the avatar's bounding box, not the attachment's) there are, indeed, checks being done to see if the avatar has a scripted attachment and if it has registered itself to receive collision events. The code is there, it just doesn't work... most of the time. Just the fact that it DOES, indeed, work SOME of the time, tends to make me believe that there are some timing issues involved, of which I haven't been aware, and have no idea where to start looking for those timers. Maybe these low-level collision events have to be enqueued somehow, to avoid getting 'lost', and thus might need to be retrieved later at a much higher and more abstract level (e.g. the virtual machine running the LSL bytecode...). I have not the faintest clue on how this can be prog
 rammed.

>>
>> I didn't wish to 'steal' the thread, but rather explain that the very tempting, but naive alternative to llCastRay() to detect where a bullet might hit an avatar is very tempting: get an avatar with lots of attachments, and try to detect those attachments with llCastRay()... or fire real, invisible bullets expecting the attachments (one per body part) to respond, depending on which one was hit, and feed that information to a central location... aye, all these are theoretical workarounds, but none of them will actually work. Following SL's inspiration, a collision event *of the avatar with something else* will be sent to *all* attachments simultaneously (or, in the case of OpenSim, to none at all...). Of course, when it works, you'll get some positioning information, and while this is not highly accurate, at least you could figure out if the avatar has been hit/detected/collided with something at the front, behind, sides, upper part, lower part, etc...
>>
>> Well, it's such a pity that the few people who actually understand the very intricate and convoluted code are uninterested in collecting data about the environment and feeding it to LSL. For others, specially my case (I do research on intelligent agents...), this means that NPCs are blind as bats and, worse, do not even 'feel' anything when they bump into things :)
>>
>> Ah, note that *some* collision information gets passed on to the viewer, because the viewer will need to know where to apply those neat special effects during a collision (playing sounds, showing some textures, etc.). Ironically, these work actually quite well, and even show up relatively accurately, but I have not the faintest idea on where those messages are being generated and how they're passed to the viewer! (As much as I've looked into libopenmetaverse, there seems to be little interest in getting those 'collision hints', since, well, most libopenmetaverse applications are text-base and do not pass visual clues back to the user...).
>>
>> Sorry for the long rant. I'm actually in the middle of writing some things about OpenSimulator and why some crucial functionality is not only missing, but workarounds are next-to-impossible, and implementing the missing functionality -- as time passes and OpenSimulator becomes more and more complex -- take so much time. I envy the volunteers who managed to do those zillions of code in their spare time. It is the equivalent of several lifetimes to replicate that :) ... and a considerable amount of a lifetime just to understand enough of it to fix a tiny bug :)
>>
>> Cheers,
>>
>>       - Gwyn
>>
>> On 27/02/2014, at 17:13, Handy Low wrote:
>>
>> > Hi Gwyn (sorry for misspelling your name up-thread)
>> >
>> > One thing I've discovered through testing is that the size of the
>> > projectile also makes a difference. If I increase the length of my
>> > bullets to a metre or two in the direction of travel, they fire the
>> > collision events every time (at least so far in my testing). The
>> > bullets do need to be that actual length too - "cheats" like
>> > path-cutting and slicing to hide the size will reduce the detection
>> > rate again.
>> >
>> > The workaround that I favour involves firing two bullets - a normal,
>> > small one and a long, invisible one - the target object can use a
>> > collision filter by name to avoid detecting both.
>> >
>> > I was wondering if that workaround would help in your case - make the
>> > attachment large (at least in the appropriate direction) but partly
>> > invisible?
>> >
>> > Gwyneth Llewelyn wrote:
>> >
>> >> 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 <[hidden email]> 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 <
>> >>>> [hidden email]> 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" <[hidden email]>
>> >>> 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 <
>> >>>>>> [hidden email]> 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 <
>> >>>>>>> [hidden email]> 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 <
>> >>> [hidden email]
>> >>>>>>>>> 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 <[hidden email]>
>> >>> 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
>> >>>>>>>>>>> [hidden email]
>> >>>>>>>>>>> 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
>> >>>>>>>>>> [hidden email]
>> >>>>>>>>>> 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
>> >>>>>>>>> [hidden email]
>> >>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> Opensim-users mailing list
>> >>>>>>>> [hidden email]
>> >>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> ===================================
>> >>>>>>> http://osgrid.org/
>> >>>>>>> http://simhost.com
>> >>>>>>> http://twitter.com/jstallings2
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> Opensim-users mailing list
>> >>>>>>> [hidden email]
>> >>>>>>> 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
>> >>>>>> [hidden email]
>> >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>> >>>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Opensim-users mailing list
>> >>>>> [hidden email]
>> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
>> >>>>>
>> >>> --
>> >>> Handy Low
>> >>>
>> >>> _______________________________________________
>> >>> Opensim-users mailing list
>> >>> [hidden email]
>> >>> https://lists.berlios.de/mailman/listinfo/opensim-users
>> >>>
>> > --
>> > Handy Low
>> >
>> > _______________________________________________
>> > Opensim-users mailing list
>> > [hidden email]
>> > https://lists.berlios.de/mailman/listinfo/opensim-users
> --
> Handy Low
>
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-users
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: llCastRay and object shapes

Handy Low
Thanks - that's a very interesting and useful background, and explains
a lot about the current implementation.

And I can certainly understand the desire for the raycasting to be
independent of the physics engine for OpenSim.

Teravus Ovares wrote:

> Just a note...   it's probably nothing..   however..  a bit of history
> on llcastray in OpenSimulator....  I wrote the obb collision detection
> being used for llcastray currently.   It wasn't actually intended to
> be used in llcastray...  it was intended to be used to raycast against
> objects when rezzing cubes and objects.  It was also designed to
> handle things like 'duplicate on ray'.    Anyway... .   Melanie_T
> thought that the system needed a physics independent implementation of
> llcastray and so made use of the OBB raycast that is used for rezzing
> for llcastray.    That said, there are now physics interface APIs that
> can be used to replace the physics independent llcastray method being
> used now.  The physics layer needs to set a property for if it can
> handle raycast requests to true and it needs to implement that part of
> the OpenSimulator physics API.
>
> For more information, go to the bottom of this file:
> https://github.com/nebadon2025/opensimulator/blob/master/OpenSim/Region/Physics/Manager/PhysicsScene.cs
>
> Best Regards
>
> Teravus
>
> On Fri, Feb 28, 2014 at 3:36 PM, Handy Low <[hidden email]> wrote:
> > Oh, you certainly didn't steal the thread. All this is part of the
> > same investigation I'd been doing, even if attachments weren't on my
> > particular agenda at the moment.
> >
> > And it's always seemed to me to be the nature of volunteer projects,
> > that quite understandably people usually work on what interests them.
> >
> > Certainly I'm hugely grateful to all the volunteers and commercial
> > contributors alike who've made OpenSim what it is.
> >
> > Gwyneth Llewelyn wrote:
> >
> >> Hi Handy,
> >>
> >> Interesting -- 'size matters' :-) Actually, I suspected that a small attachment might have some issues, so I've been consistently using huge transparent attachments (boxes or spheres... or even pyramids, which sort of 'flare out' in the direction that is more interesting, as you suggest) which completely encloses a normal-sized avatar (so they would have a volume of at least 2 x 2 x 2 m).
> >>
> >> However, as much as I understand the underlying code -- which is not much -- this shouldn't actually make any difference. Per SL specifications, an attachment detecting collisions will not detect collisions *with the attached prim's bounding box* but *with the avatar's bounding box*. This is a major difference between detecting collisions inside prims -- when they're attached, collisions *by the avatar* are passed to the scripts *inside the attached prim*. When they're unattached, the physics engine uses the prim's bounding box. Actually, the code dealing with collisions with attachments is in there! There are a lot of interesting checks at the avatar-collision level (both at the abstraction level but even further down on the interface with the physics engine) to see if llVolumeDetect()
>   has been called or not, if an avatar has a scripted attachment that has signaled the simulator to receive collision events, and so forth. A *lot* of work has been put into this, and, as far
>   as I can
> >> understand the very convoluted way this is supposed to work, the algorithm seems to be conceptually sound. What I mean is that every time an avatar collides with 'something' (and, again, notice that this will be a check made using the avatar's bounding box, not the attachment's) there are, indeed, checks being done to see if the avatar has a scripted attachment and if it has registered itself to receive collision events. The code is there, it just doesn't work... most of the time. Just the fact that it DOES, indeed, work SOME of the time, tends to make me believe that there are some timing issues involved, of which I haven't been aware, and have no idea where to start looking for those timers. Maybe these low-level collision events have to be enqueued somehow, to avoid getting 'lost', a
>  nd thus might need to be retrieved later at a much higher and more abstract level (e.g. the virtual machine running the LSL bytecode...). I have not the faintest clue on how this can be prog
>  rammed.
> >>
> >> I didn't wish to 'steal' the thread, but rather explain that the very tempting, but naive alternative to llCastRay() to detect where a bullet might hit an avatar is very tempting: get an avatar with lots of attachments, and try to detect those attachments with llCastRay()... or fire real, invisible bullets expecting the attachments (one per body part) to respond, depending on which one was hit, and feed that information to a central location... aye, all these are theoretical workarounds, but none of them will actually work. Following SL's inspiration, a collision event *of the avatar with something else* will be sent to *all* attachments simultaneously (or, in the case of OpenSim, to none at all...). Of course, when it works, you'll get some positioning information, and while this is no
>  t highly accurate, at least you could figure out if the avatar has been hit/detected/collided with something at the front, behind, sides, upper part, lower part, etc...
> >>
> >> Well, it's such a pity that the few people who actually understand the very intricate and convoluted code are uninterested in collecting data about the environment and feeding it to LSL. For others, specially my case (I do research on intelligent agents...), this means that NPCs are blind as bats and, worse, do not even 'feel' anything when they bump into things :)
> >>
> >> Ah, note that *some* collision information gets passed on to the viewer, because the viewer will need to know where to apply those neat special effects during a collision (playing sounds, showing some textures, etc.). Ironically, these work actually quite well, and even show up relatively accurately, but I have not the faintest idea on where those messages are being generated and how they're passed to the viewer! (As much as I've looked into libopenmetaverse, there seems to be little interest in getting those 'collision hints', since, well, most libopenmetaverse applications are text-base and do not pass visual clues back to the user...).
> >>
> >> Sorry for the long rant. I'm actually in the middle of writing some things about OpenSimulator and why some crucial functionality is not only missing, but workarounds are next-to-impossible, and implementing the missing functionality -- as time passes and OpenSimulator becomes more and more complex -- take so much time. I envy the volunteers who managed to do those zillions of code in their spare time. It is the equivalent of several lifetimes to replicate that :) ... and a considerable amount of a lifetime just to understand enough of it to fix a tiny bug :)
> >>
> >> Cheers,
> >>
> >>       - Gwyn
> >>
> >> On 27/02/2014, at 17:13, Handy Low wrote:
> >>
> >> > Hi Gwyn (sorry for misspelling your name up-thread)
> >> >
> >> > One thing I've discovered through testing is that the size of the
> >> > projectile also makes a difference. If I increase the length of my
> >> > bullets to a metre or two in the direction of travel, they fire the
> >> > collision events every time (at least so far in my testing). The
> >> > bullets do need to be that actual length too - "cheats" like
> >> > path-cutting and slicing to hide the size will reduce the detection
> >> > rate again.
> >> >
> >> > The workaround that I favour involves firing two bullets - a normal,
> >> > small one and a long, invisible one - the target object can use a
> >> > collision filter by name to avoid detecting both.
> >> >
> >> > I was wondering if that workaround would help in your case - make the
> >> > attachment large (at least in the appropriate direction) but partly
> >> > invisible?
> >> >
> >> > Gwyneth Llewelyn wrote:
> >> >
> >> >> 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 <[hidden email]> 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 <
> >> >>>> [hidden email]> 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" <[hidden email]>
> >> >>> 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 <
> >> >>>>>> [hidden email]> 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 <
> >> >>>>>>> [hidden email]> 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 <
> >> >>> [hidden email]
> >> >>>>>>>>> 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 <[hidden email]>
> >> >>> 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
> >> >>>>>>>>>>> [hidden email]
> >> >>>>>>>>>>> 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
> >> >>>>>>>>>> [hidden email]
> >> >>>>>>>>>> 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
> >> >>>>>>>>> [hidden email]
> >> >>>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> _______________________________________________
> >> >>>>>>>> Opensim-users mailing list
> >> >>>>>>>> [hidden email]
> >> >>>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> ===================================
> >> >>>>>>> http://osgrid.org/
> >> >>>>>>> http://simhost.com
> >> >>>>>>> http://twitter.com/jstallings2
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> _______________________________________________
> >> >>>>>>> Opensim-users mailing list
> >> >>>>>>> [hidden email]
> >> >>>>>>> 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
> >> >>>>>> [hidden email]
> >> >>>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >> >>>>>>
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> Opensim-users mailing list
> >> >>>>> [hidden email]
> >> >>>>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >> >>>>>
> >> >>> --
> >> >>> Handy Low
> >> >>>
> >> >>> _______________________________________________
> >> >>> Opensim-users mailing list
> >> >>> [hidden email]
> >> >>> https://lists.berlios.de/mailman/listinfo/opensim-users
> >> >>>
> >> > --
> >> > Handy Low
> >> >
> >> > _______________________________________________
> >> > Opensim-users mailing list
> >> > [hidden email]
> >> > https://lists.berlios.de/mailman/listinfo/opensim-users
> > --
> > Handy Low
> >
> > _______________________________________________
> > Opensim-users mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/opensim-users
--
Handy Low

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users