[Opensim-dev] TimerEvent to slow, do/while faster.

[Dahlia Trimble]

There's a setting which can be added to the [XEngine] section of the
OpenSim.ini file:
MinTimerInterval = 0.5

Note that if you have high speed timers and you do scene updates with them,
you will likely overflow queues in many places and cause all sorts of
problems. I seem to not have too many problems  with it set at 0.1 and with
just a couple scripts with timers that fast.

Note also that doing scene updates (moving objects) sends at least one
packet to each client connected to the sim and you really never want to
send updates faster than they can be displayed. If you send 100 packets per
second to each viewer, and most viewers are running about 30 FPS, you are
sending 70 scene updates to each viewer that cant even be displayed. If
your goal is smooth motion this will probably work against you as you will
likely have a lot of packet loss and the lazy send queues in llClientView
will send the state of the prim when the packet is sent, not as it was when
the timer event occurred, which means you could get a bunch of packets in a
row that send the same position. So, in essence, you are making the sim do
more work and probably causing instability in many areas while not
accomplishing your desired goal.

Using not_at_target() is probably the best event as it likely wouldn't send
any updates any faster than they can change in the simulator. I suspect
even using not_at_target could cause issues when lots of clients are in the
sim and/or lots of prims are moving/changing at the same time.

Also be aware that if you are changing the shape of prims, it's probably
best to make them phantom while doing many quick shape changes in a row,
otherwise the code which creates physics shapes may not be able to keep up
and you could run into memory problems as each shape is stored.

Hopefully eventually OpenSimulator will have implemented
llSetKeyFrameMotion() which would be a much more efficient way of doing
smoothly moving objects.


On Tue, Jul 17, 2012 at 5:05 PM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:

> not_at_target is currently triggered through the main scene rather than in
> the aync lsl command thread.  So it will fire at least every 1/11 of a
> second.  For some reason, the target check is also performed at
> SceneObjectGroup.**ScheduleGroupForUpdate() so it may fire even more
> often.
>
> Looking briefly at the web, sources only mention that not_at_target may
> fire multiple times before reaching a target. They say nothing about the
> periodicity of such firing.
>
>
> On 18/07/12 00:45, R.Gunther wrote:
>
>> On 2012-07-18 01:31, Justin Clark-Casey wrote:
>>
>>> If you want to increase timer resolution the current thing to do would
>>> be to change
>>>
>>> cmdHandlerThreadCycleSleepms = 100;
>>> Intressting, then i get the question why it seems the event "
>>> not_at_target" seems to have o restriction.
>>>
>> with that function i always get some sort if filled query. not_at_target
>> can fire at the same speed as do/while
>> It looks like its getting faster called then processed. i think
>> "timerevent" is right now to slow and "not_at_target"
>> is way to fast and seems to require lots of lsl time.
>>
>> The whole event triggering is sometimes tricky.
>>
>> ------
>>
>>  in AsyncCommandManager.**ReadConfig().  It appears that configurability
>>> was disabled almost 4 years ago for reasons
>>> unknown.
>>>
>>> The fact that it's 100 means that you can never get timers that fire
>>> less than 100ms apart.  Moreover, timers are tied
>>> into the general AsyncCommandManager.**DoOneCmdHandlerPass(), which
>>> performs operations for listeners, sensors and
>>> dataserver events as well as timers.  So the resolution will be even
>>> less accurate.  At some point I think it may be
>>> good to do some of these in separate threads to reduce the variability
>>> of performance.
>>>
>>> However, even if these issues were to go away, the timer events would
>>> still have to be fired through the event
>>> mechanism.  I'm not sure how efficient firing lots of timers is, or what
>>> impact it would have on other scripts in the
>>> region.
>>>
>>> On 16/07/12 15:13, R.Gunther wrote:
>>>
>>>> I work on some project that move prims.
>>>> Right now i do it with small do/while loop. thats the fastest way to
>>>> move a prim smooth.
>>>> But have technical some problems.
>>>>
>>>> If i move the prim with timer event. and i have set it to 0.01 because
>>>> its anyway not seems todo much below 0.5
>>>> not sure whats the lowest working setting. And thats also the problem.
>>>> the object moves way slower != smooth compared to
>>>> do/while loop.
>>>> Would be nice if there's option to speed the timer event up. But need
>>>> to agree i dont know the effects.
>>>>
>>>> A timer thats doing lets say 0.01 sounds better then a do/while loopt
>>>> thats running 20 meters with steps of 0.5 meters.
>>>> would be nice if the timers where a bit faster. But maby i make a
>>>> thinking error to.  Still dont see why i cant get the
>>>> same result with both ways.
>>>>
>>>> ______________________________**_________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>
>>>>
>>>
>>>
>>
>> ______________________________**_________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org/blog
> http://twitter.com/justincc
>
>
> ______________________________**_________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20120718/668f5142/attachment-0001.html>