The movement script I wrote is a physics simulator I developed to see how well the Inworldz grid and its new scripting engine would perform. The vehicle operates without physics, as physics for objects is turned off presently. One angular motor and three linear axis motors are simulated. They each have inertia and friction effects. Gravitational force (including terminal velocity) is simulated as well as simulated land collisions. The terrain following logic is a damped collision effect with feed forward to prevent sampling jitter. Generally, the timer loop ends when delta V in all axes drop below a small threshold. The script uses zero processor resources when the vehicle stops. The computations are performed under a timer event, which in the demo was running at nominally 20 events per second. If the computations under the timer event take too long, the next timer event is shortened (the debug logic shows this happens rarely). Force inputs to the simulated physics model are applied by standard control events, so up to 15 changes per second can occur.
All in all, this script results in an extremely smooth, efficient and realistic physics-like vehicle. I have to give credit to the amazingly fast phlox implementation of the LSL scripting engine. This byte-code VM script engine outperforms SL mono by major amount and without any of the region crossing side effects.
I updated the script to become a 3-axis angular and linear movement motor. It’s programmable so it is capable of a wide range of behaviors. It works very well up to 64 prims. Above that the compute load increases noticbly. Still, I tested it with a 255 prim vehicle and it worked far better in Inworldz than in SL.
About the region crossings. These were true crossing in that data has to be handed off across the 256x256m region instances. I was impressed how quickly the handoffs occured since I think all the data is sent across as XML, a rather wordy way to do that.
the spelling is correct on the email acct. I want to bring in a vendor which I hold in Sl can you help me in finding out how it is done. I have seen some business from SL here and I think its a good thing to help InWorld to get better known. Thanks for your time. I hope to hear from you.
6 comments
No ping yet
Boudica Destiny says:
July 26, 2011 at 2:56 pm (UTC 0)
Sweet!!! Watching him drive in circles at high speed over the sim-crossing was amazing! Not even a blink of slow down….. Awesome!!
Boudica
Balpien Hammerer says:
October 25, 2011 at 3:04 pm (UTC 0)
The movement script I wrote is a physics simulator I developed to see how well the Inworldz grid and its new scripting engine would perform. The vehicle operates without physics, as physics for objects is turned off presently. One angular motor and three linear axis motors are simulated. They each have inertia and friction effects. Gravitational force (including terminal velocity) is simulated as well as simulated land collisions. The terrain following logic is a damped collision effect with feed forward to prevent sampling jitter. Generally, the timer loop ends when delta V in all axes drop below a small threshold. The script uses zero processor resources when the vehicle stops. The computations are performed under a timer event, which in the demo was running at nominally 20 events per second. If the computations under the timer event take too long, the next timer event is shortened (the debug logic shows this happens rarely). Force inputs to the simulated physics model are applied by standard control events, so up to 15 changes per second can occur.
All in all, this script results in an extremely smooth, efficient and realistic physics-like vehicle. I have to give credit to the amazingly fast phlox implementation of the LSL scripting engine. This byte-code VM script engine outperforms SL mono by major amount and without any of the region crossing side effects.
I updated the script to become a 3-axis angular and linear movement motor. It’s programmable so it is capable of a wide range of behaviors. It works very well up to 64 prims. Above that the compute load increases noticbly. Still, I tested it with a 255 prim vehicle and it worked far better in Inworldz than in SL.
About the region crossings. These were true crossing in that data has to be handed off across the 256x256m region instances. I was impressed how quickly the handoffs occured since I think all the data is sent across as XML, a rather wordy way to do that.
Sack says:
February 27, 2012 at 3:18 pm (UTC 0)
Its a megaregion!
admin says:
February 27, 2012 at 4:06 pm (UTC 0)
No.
These are two separate regions running in different processes. All script state and object state is being transferred between the two processes.
InWorldz source code doesn’t even contain megaregion support.
Balpien Hammerer says:
February 27, 2012 at 5:38 pm (UTC 0)
Sack, no, it was not a megaregion. Thisi is the inworldz grid which has no crappy megaregion support. Yes, 256x256m regions only.
Thomas SilverWood says:
January 28, 2013 at 4:18 pm (UTC 0)
the spelling is correct on the email acct. I want to bring in a vendor which I hold in Sl can you help me in finding out how it is done. I have seen some business from SL here and I think its a good thing to help InWorld to get better known. Thanks for your time. I hope to hear from you.
Thomas SilverWood