[Opensim-dev] TimerEvent to slow, do/while faster.
Justin Clark-Casey
jjustincc at googlemail.com
Wed Jul 18 23:56:54 UTC 2012
Good point about MinTimerInterval - I wasn't aware of that.
So timers can't be less than 500 ms unless you change that parameter, and even then you couldn't get below 100ms without
starting to tweak things in code.
On 18/07/12 20:02, Dahlia Trimble wrote:
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
More information about the Opensim-dev
mailing list