Rotation a prim with llTargetOmega ()
The rotation of a prim can happen in two ways: The more complex, we will discuss later, is based on command
llSetRot
(). The simplest
instead explained briefly here, is based on the function
llTargetOmega
().
- the carrier axis, showing the script around which axis to rotate the object (x, y, z). - the spinrate, which is the frequency with which the object will rotate (in radians per second). - the gain is the force that is given to spin: it is a value takes effect when the first is physical, and is set equal to 0 for non-physical prims). This type of rotation on items NOT physical, no overhead work on the server, in this case is called "client-side. What does it mean?
that the rotation is handled by the client, and then will not sync at all, each "detect" spin in a different way, nor will function as measured by
llGetRot
() (which returns the rotation of the prim) Let a cube, the following script: default
{
state_entry
()
{/ / llSay (0, "Hello, Avatar!");}
touch_start llTargetOmega (\u0026lt;0.0,0.0,1.0>, PI, 1.0);
}} This code will rotate an object on its axis Z (the vertical) at a rate of PI sec. PI is a value in radians (PI greek: 3.1415)
if we wanted to slow down or speed up the rotation?
We can act as a convenience to the radiant write 2 * PI (or TWO_PI) will increase by twice the speed. Instead, write the IP / 2 halve the speed. What happens if we give value to the carrier axis?? es. \u0026lt;2.0,0.5,1.0> .. tested on a simple cube!
0 comments:
Post a Comment