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 <[email protected] <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]> https://lists.berlios.de/__mailman/listinfo/opensim-dev <https://lists.berlios.de/mailman/listinfo/opensim-dev> _________________________________________________ Opensim-dev mailing list [email protected] <mailto:[email protected]> 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 [email protected] <mailto:[email protected]> https://lists.berlios.de/__mailman/listinfo/opensim-dev <https://lists.berlios.de/mailman/listinfo/opensim-dev> _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
-- Justin Clark-Casey (justincc) http://justincc.org/blog http://twitter.com/justincc _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
