<p dir="ltr">Thanks Dahlia!</p>
<p dir="ltr">That level of detail provides a lot of insight into this issue.</p>
<p dir="ltr">Thanks for that part which you did implement, some functionality is always better than none ;)</p>
<p dir="ltr">Also thank you for your willingness to support those who might move the work forward.</p>
<p dir="ltr">Cheers!<br>
James<br>
</p>
<div class="gmail_quote">On Feb 26, 2014 3:43 PM, "Dahlia Trimble" <<a href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>FWIW...<br><br></div>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.<br>
<br></div>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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 6:07 AM, James Stallings II <span dir="ltr"><<a href="mailto:james.stallings@gmail.com" target="_blank">james.stallings@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p>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.</p>
<p>My experience has been that some things are more difficult than others to accomplish; and OpenSim devs, despite myth and appearances, are human too ;) </p><p>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.<br>
</p><p>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.</p>
<p>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 ;)</p>
<p>In any case, don't let me slow your roll :)</p><p><br></p><p>Cheers</p><span><font color="#888888"><p>James</p></font></span><div><div><p><br></p>
<div class="gmail_quote">On Feb 26, 2014 7:26 AM, "Dr Ramesh Ramloll" <<a href="mailto:r.ramloll@gmail.com" target="_blank">r.ramloll@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi James,<div>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". </div>
<div>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.<br></div><div>Sorry for the rant man, when llCastRay works, we found some really beautiful things happening... </div>
<div>Ramesh</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 7:46 AM, James Stallings II <span dir="ltr"><<a href="mailto:james.stallings@gmail.com" target="_blank">james.stallings@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>
<br></div><div>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 ;)<div>
<br></div><div>Not to put too fine a point on it, but "...patches are welcome." For the rest of us, that translates as "Be patient."</div></div><div><br></div><div><br></div><div>Cheers!</div><div>James</div>
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 10:20 PM, Dahlia Trimble <span dir="ltr"><<a href="mailto:dahliatrimble@gmail.com" target="_blank">dahliatrimble@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 7:46 PM, Dr Ramesh Ramloll <span dir="ltr"><<a href="mailto:r.ramloll@gmail.com" target="_blank">r.ramloll@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>
Thanks</div><div>R</div></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Tue, Feb 25, 2014 at 12:00 PM, Chris <span dir="ltr"><<a href="mailto:mewtwo0641@gmail.com" target="_blank">mewtwo0641@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<div>
<div><br>
<br>
On 2/25/2014 10:48 AM, Handy Low wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Gwyneth Llewelyn <gwyneth.llewelyn <at> <a href="http://gwynethllewelyn.net" target="_blank">gwynethllewelyn.net</a>> writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Handy,<br>
<br>
Just for the sake of completeness, did you test with ODE or BulletSim? I<br>
</blockquote>
believe the implementation might be<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
slightly different (or, then again, it's just my not-so-precise testing).<br>
<br>
Thanks,<br>
<br>
- Gwyn<br>
<br>
On 25/02/2014, at 16:09, Handy Low wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Currently it seems that the OpenSim implementation of llCastRay() gives<br>
coordinates on a target object that lie on the bounding box of the<br>
</blockquote></blockquote>
object<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
rather than on the face of the prim itself.<br>
<br>
For example, casting a ray at a pair of linked cubes in OpenSim will<br>
</blockquote></blockquote>
generate<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
coordinates that lie on the cuboid bounding box that constrains both<br>
</blockquote></blockquote>
cubes.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Likewise, casting a ray at a sphere will generate a point on the<br>
</blockquote></blockquote>
sphere's<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
cubic bounding box.<br>
<br>
In SL, the same tests will both return points on the prim surfaces.<br>
<br>
Is this expected behaviour?<br>
<br>
Thanks<br>
</blockquote></blockquote>
Thanks to Michael and Gwen for the fast replies.<br>
<br>
Off the top of my head, I don't know which physics engine they were using,<br>
or how I can find out - the tests I've been doing have been in OSGrid<br>
(Sandbox Plaza) and in Kitely, if that's any help.<br>
<br>
--<br>
Handy<br>
<br>
______________________________<u></u>_________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-users</a><br>
</blockquote>
<br>
<br></div></div><span><font color="#888888">
-- <br>
OpenSim: 10 Region Standalone on 0.7.6 Dev<br>
Physics: Open Dynamics Engine<br>
OS: Windows 7 (x64)<br>
CPU: AMD Phenom II X4 840 3.2 GHz<br>
Memory: 11 GB DDR3<br>
Database: MySQL 5.1.63 (x64)</font></span><div><div><br>
<br>
______________________________<u></u>_________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div dir="ltr"><font color="#999999">'Consider how the lilies grow. They do not labor or spin.'</font><br>
<b>Rameshsharma Ramloll</b> PhD, CEO CTO DeepSemaphore LLC, Affiliate <i>Research Associate Professor</i>, Idaho State University, Pocatello, ID 83209 Tel: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040</a><br>
<div><a href="http://www.linkedin.com/in/rameshramloll" target="_blank">LinkedIn</a>, <a href="http://www.deepsemaphore.com" target="_blank">DeepSemaphore LLC</a>, <a href="http://www.rezmela.com" target="_blank">RezMela</a>, <a href="https://plus.google.com/103652369558830540272/about" target="_blank">Google+ profile</a></div>
</div>
</font></span></div>
<br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div dir="ltr">
===================================<div><a href="http://osgrid.org/" target="_blank">http://osgrid.org/</a><br><a href="http://simhost.com" target="_blank">http://simhost.com</a><br><a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br>
<br></div></div>
</div>
<br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">
<font color="#999999">'Consider how the lilies grow. They do not labor or spin.'</font><br><b>Rameshsharma Ramloll</b> PhD, CEO CTO DeepSemaphore LLC, Affiliate <i>Research Associate Professor</i>, Idaho State University, Pocatello, ID 83209 Tel: <a href="tel:208-240-0040" value="+12082400040" target="_blank">208-240-0040</a><br>
<div><a href="http://www.linkedin.com/in/rameshramloll" target="_blank">LinkedIn</a>, <a href="http://www.deepsemaphore.com" target="_blank">DeepSemaphore LLC</a>, <a href="http://www.rezmela.com" target="_blank">RezMela</a>, <a href="https://plus.google.com/103652369558830540272/about" target="_blank">Google+ profile</a></div>
</div>
</div>
<br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br></blockquote></div>
</div></div></div>
<br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br></blockquote></div><br></div>
<br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br></blockquote></div>