[Opensim-users] Information on the number of sensors that an opensim region can support

[Michael Emory Cerquoni]

llVolumeDetect is completely unreliable in Bulletsim currently, i would not
try using it to much if your running Bullet.

On Thu, Oct 16, 2014 at 4:13 PM, Dr Ramesh Ramloll <r.ramloll at gmail.com>
wrote:

> Physics unfortunately does not work as well as we hoped regarding
> collision detection ... so trying to find work arounds. For e.g. if a
> projectile is moving beyond a certain speed, the physics frame delay may be
> too large and collsions are missed. So far we seem to have had better
> results with sensors (only time and further testing will tell)
>
> On Thu, Oct 16, 2014 at 4:06 PM, Mic Bowman <cmickeyb at gmail.com> wrote:
>
>> Depending on your requirements... you can use llVolumeDetect() & check
>> for collisions. That uses the physics acceleration structures.
>>
>> --mic
>>
>>
>> On Thu, Oct 16, 2014 at 12:49 PM, Dr Ramesh Ramloll <r.ramloll at gmail.com>
>> wrote:
>>
>>> Thanks Dahlia, you provided us with a good tip here ... "Keep in mind
>>> that specifying a scan with a key or using llGetObjectDetails with a known
>>> key is likely far more efficient than doing arbitrary scans."
>>> Thank YOU
>>> Ramesh
>>>
>>> On Thu, Oct 16, 2014 at 3:46 PM, Dahlia Trimble <dahliatrimble at gmail.com
>>> > wrote:
>>>
>>>> Sensors are fairly expensive and inefficient as unless you specify a
>>>> scan with a given key, they must do a linear search of all of the specified
>>>> entity types in the scene (region). In other words, if you ask for avatars
>>>> in an area, it must test all avatars in the region, or if you ask for
>>>> objects it must test all of the objects. These searches also require
>>>> exclusive access to the region entities, so only one can happen at a time
>>>> and anything else that needs access must wait (physics, avatar movement,
>>>> etc.). Therefore adding many sensors doing frequent scans will eventually
>>>> degrade sim performance and could have a cascading effect. I'm not aware of
>>>> any numeric limit; it would depend on how many objects and avatars are in
>>>> the region and how powerful the machine is the sim is running on and how
>>>> busy it is doing other things. I'd think testing this would be difficult as
>>>> you may run into a situation where it appears to work fine when you are
>>>> building/testing but then performs poorly or even fails when there are many
>>>> avatars in the region. Lacking any known limit but with these concepts in
>>>> mind, I guess you'll just have to try adding as many as you need and see
>>>> when something breaks. Keep in mind that specifying a scan with a key or
>>>> using llGetObjectDetails with a known key is likely far more efficient than
>>>> doing arbitrary scans.
>>>>
>>>> Unfortunately OpenSimulator currently lacks any means of doing
>>>> efficient spatial queries. This is something I've brought up in development
>>>> meetings a few times but the idea has never really caught on.
>>>>
>>>> Good luck with your project :)
>>>>
>>>> On Thu, Oct 16, 2014 at 11:21 AM, Dr Ramesh Ramloll <
>>>> r.ramloll at gmail.com> wrote:
>>>>
>>>>> Hello there,
>>>>> Is there some information about any limit on the number of sensors
>>>>> that an opensim region can support by default?
>>>>> We are planning to use many sensors at one time, some even attached to
>>>>> vehicles and projectiles, are there anything we should be especially
>>>>> careful about regarding their use in this manner?
>>>>> Thanks
>>>>> Ramesh
>>>>> --
>>>>> 'Consider how the lilies grow. They do not labor or spin.'
>>>>> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research
>>>>> Associate Professor*, Idaho State University, Pocatello, ID 83209
>>>>> Tel: 208-240-0040
>>>>> LinkedIn <http://www.linkedin.com/in/rameshramloll>, DeepSemaphore LLC
>>>>> <http://www.deepsemaphore.com>, RezMela <http://www.rezmela.com>, Google+
>>>>> profile <https://plus.google.com/103652369558830540272/about>
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-users mailing list
>>>>> Opensim-users at opensimulator.org
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Opensim-users mailing list
>>>> Opensim-users at opensimulator.org
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>>
>>>>
>>>
>>>
>>> --
>>> 'Consider how the lilies grow. They do not labor or spin.'
>>> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research
>>> Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel:
>>> 208-240-0040
>>> LinkedIn <http://www.linkedin.com/in/rameshramloll>, DeepSemaphore LLC
>>> <http://www.deepsemaphore.com>, RezMela <http://www.rezmela.com>, Google+
>>> profile <https://plus.google.com/103652369558830540272/about>
>>>
>>> _______________________________________________
>>> Opensim-users mailing list
>>> Opensim-users at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>
>>>
>>
>> _______________________________________________
>> Opensim-users mailing list
>> Opensim-users at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>
>>
>
>
> --
> 'Consider how the lilies grow. They do not labor or spin.'
> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research
> Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel:
> 208-240-0040
> LinkedIn <http://www.linkedin.com/in/rameshramloll>, DeepSemaphore LLC
> <http://www.deepsemaphore.com>, RezMela <http://www.rezmela.com>, Google+
> profile <https://plus.google.com/103652369558830540272/about>
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
>


-- 
Michael Emory Cerquoni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20141016/fca0baa8/attachment.html>