Linden Vehicle Tutorial
| LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
Vehicles
Vehicles are a new feature now available for use through LSL. This chapter will cover the basics of how vehicles work, the terms used when describing vehicles, and a more thorough examination of the api available.
There are several ways to make scripted objects move themselves around. One way is to turn the object into a "vehicle". This feature is versatile enough to make things that slide, hover, fly, and float. Some of the behaviors that can be enabled are:
- deflection of linear and angular velocity to preferred axis of motion
- asymmetric linear and angular friction
- hovering over terrain/water or at a global height
- banking on turns
- linear and angular motor for push and turning
Overview
Each scripted object can have one vehicle behavior that is configurable through thellSetVehicleType, llSetVehicleFloatParam,llSetVehicleVectorParam,llSetVehicleRotationParam,llSetVehicleFlags, and llRemoveVehicleFlags library calls.
These script calls are described in more detail below, but the important thing to notice here is that the vehicle behavior has several parameters that can be adjusted to change how the vehicle handles. Depending on the values chosen the vehicle can veer like a boat in water, or ride like a sled on rails.
Setting the vehicle flags allow you to make exceptions to some default behaviors. Some of these flags only have an effect when certain behaviors are enabled. For example, the VEHICLE_FLAG_HOVER_WATER_ONLY will make the vehicle ignore the height of the terrain, however it only makes a difference if the vehicle is hovering.
Warnings
Vehicles are new in Second Life 1.1 and some of the details of their behavior may be changed as necessary to ensure stability and user safety. In particular, many of the limits and defaults described in the appendices will probably change and should not be relied upon in the long term.
It is not recommended that you mix vehicle behavior with some of the other script calls that provide impulse and forces to the object, especiallyllSetBuoyancy,llSetForce,llSetTorque, andllSetHoverHeight.
While the following methods probably don’t cause any instabilities, their behavior may conflict with vehicles and cause undesired and/or inconsistent results, so usellLookAt,llRotLookAt,llMoveToTarget, and llTargetOmega at your own risk.
If you think you have found a bug relating to how vehicle’s work, one way to submit the problem is to give a copy of the vehicle and script to Andrew Linden with comments or a notecard describing the problem. Please name all submissions "Bugged Vehicle XX" where XX are your Second Life initials. The vehicle and script will be examined at the earliest convenience.
Definitions
The terms "roll", "pitch", and "yaw" are often used to describe the modes of rotations that can happen to a airplane or boat. They correspond to rotations about the local x-, y-, and z-axis respectively. z-axis .
http://en.wikipedia.org/wiki/Tait-Bryan_angles
The right-hand-rule, often introduced in beginning physics courses, is used to define the direction of positive rotation about any axis. As an example of how to use the right hand rule, consider a positive rotation about the roll axis. To help visualize how such a rotation would move the airplane, place your right thumb parallel to the plane’s roll-axis such that the thumb points in the positive x-direction, then curl the four fingers into a fist. Your fingers will be pointing in the direction that the plane will spin.
http://en.wikipedia.org/wiki/Right_hand_rule
Many of the parameters that control a vehicle’s behavior are of the form:
VEHICLE_BEHAVIOR_TIMESCALE
A BEHAVIOR ’s "timescale" can usually be understood as the time for the behavior to push, twist, or otherwise affect the vehicle such that the difference between what it is doing, and what it is supposed to be doing, has been reduced to 1/e of what it was, where "e" is the natural exponent (approximately 2.718281828). In other words, it is the timescale for exponential decay toward full compliance to the desired behavior. When you want the vehicle to be very responsive use a short timescale of one second or less, and if you want to disable a behavior then set the timescale to a very large number like 300 (5 minutes) or more. Note, for stability reasons, there is usually a limit to how small a timescale is allowed to be, and is usually on the order of a tenth of a second. Setting a timescale to zero is safe and is always equivalent to setting it to its minimum. Any feature with a timescale can be effectively disabled by setting the timescale so large that it would take them all day to have any effect.
Setting the Vehicle Type
Before any vehicle parameters can be set the vehicle behavior must first be enabled. It is enabled by calling llSetVehicleType with any VEHICLE_TYPE_*, except VEHICLE_TYPE_NONE which will disable the vehicle. See the vehicle types constants section for currently available types. More types will be available soon.
Setting the vehicle type is necessary for enabling the vehicle behavior and sets all of the parameters to its default values. For each vehicle type listed we provide the corresponding equivalent code in long format. Is is important to realize that the defaults are not the optimal settings for any of these vehicle types and that they will definitely be changed in the future. Do not rely on these values to be constant until specified.
Should you want to make a unique or experimental vehicle you will still have to enable the vehicle behavior with one of the default types first, after which you will be able to change any of the parameters or flags within the allowed ranges.
Setting the vehicle type does not automatically take controls or otherwise move the object. However should you enable the vehicle behavior while the object is free to move and parked on a hill then it may start to slide away.
We’re looking for new and better default vehicle types. If you think you’ve found a set of parameters that make a better car, boat, or any other default type of vehicle then you may submit your proposed list of settings to Andrew Linden via a script or notecard.
Linear and Angular Deflection
A common feature of real vehicles is their tendency to move along "preferred axes of motion". That is, due to their wheels, wings, shape, or method of propulsion they tend to push or redirect themselves along axes that are static in the vehicle’s local frame. This general feature defines a class of vehicles and included in this category a common dart is a "vehicle": it has fins in the back such that if it were to tumble in the air it would eventually align itself to move point-forward -- we’ll call this alignment effect angular deflection.
A wheeled craft exhibits a different effect: when a skateboard is pushed in some direction it will tend to redirect the resultant motion along that which it is free to roll -- we’ll call this effect linear deflection.
So a typical Second Life vehicle is an object that exhibits linear and/or angular deflection along the "preferential axes of motion". The default preferential axes of motion are the local x- (at), y- (left), and z- (up) axes of the local frame of the vehicle’s root primitive. The deflection behaviors relate to the x-axis (at): linear deflection will tend to rotate its velocity until it points along it’s positive local x-axis while the angular deflection will tend to reorient the vehicle such that it’s x-axis points in the direction that it is moving. The other axes are relevant to vehicle behaviors that are described later, such as the vertical attractor which tries to keep a vehicle’s local z-axis pointed toward the world z-axis (up). The vehicle axes can be rotated relative to the object’s actual local axes by using the VEHICLE_REFERENCE_FRAME parameter, however that is an advanced feature and is covered in detail in a later section of these documents.
Depending on the vehicle it might be desirable to have lots of linear and/or angular delfection or not. The speed of the deflections are controlled by setting the relevant parameters using thellSetVehicleFloatParam script call.
Each variety of deflection has a "timescale" parameter that determines how quickly a full deflection happens.
Basically the timescale it the time coefficient for exponential decay toward full deflection. So, a vehicle that deflects quickly should have a small timescale. For instance, a typical dart might have a angular deflection timescale of a couple of seconds but a linear deflection of several seconds; it will tend to reorient itself before it changes direction. To set the deflection timescales of a dart you might use the lines below:
llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_TIMESCALE, 2.0); llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_TIMESCALE, 6.0);
Each variety of deflection has an "efficiency" parameter that is a slider between 0.0 and 1.0. Unlike the other efficiency parameter of other vehicle behaviors, the deflection efficiencies do not slide between "bouncy" and "damped", but instead slide from "no deflection whatsoever" (0.0) to "maximum deflection" (1.0). That is, they behave much like the deflection timescales, however they are normalized to the range between 0.0 and 1.0.
Moving the Vehicle
Once enabled, a vehicle can be pushed and rotated by external forces and/or from script calls such as llApplyImpulse, however linear and angular motors have been built in to make motion easier and smoother. Their directions can be set using thellSetVehicleVectorParam call. For example, to make the vehicle try to move at 5 meters/second along its local x-axis (the default look-at direction) you would put the following line in your script:
llSetVehicleVectorParam(VEHICLE_LINEAR_MOTOR_DIRECTION, <5, 0, 0>);
To prevent vehicles from moving too fast the magnitude of the linear motor is clamped to be no larger than about 30 meters/second. Note that this is clamped mostly because of limitations of the physics engine, and may be raised later when possible.
Setting the motor speed is not enough to enable all interesting vehicles. For example, some will want a car that immediately gets up to the speed they want, while others will want a boat that slowly climbs up to its maximum velocity. To control this effect you can use the VEHICLE_LINEAR_MOTOR_TIMESCALE parameter.
Basically the "timescale" of a motor is the time constant for the vehicle to exponentially accelerate toward its full speed.
What would happen if you were to accidentally set the vehicle’s linear velocity to maximum possible speed and then let go? It would run away and never stop, right? Not necessarily: an automatic "motor decay" has been built in such that all motors will gradually decrease their effectiveness after being set.
Each time the linear motor’s vector is set its "grip" immediately starts to decay exponentially with a timescale determined by the VEHICLE_LINEAR_MOTOR_DECAY_TIMESCALE, such that after enough time the motor ceases to have any effect. This decay timescale serves two purposes. First, since it cannot be set longer than 120 seconds, and is always enabled it gaurantees that a vehicle will not push itself about forever in the absence of active control (from keyboard commands or some logic loop in the script). Second, it can be used to push some vehicles around using a simple impulse model. That is, rather than setting the motor "on" or "off" depending on whether a particular key is pressed "down" or "up" the decay timescale can be set short and the motor can be set "on" whenever the key transitions from "up" to "down" and allowed to automatically decay.
Since the motor’s effectiveness is reset whenever the motor’s vector is set, then setting it to a vector of length zero is different from allowing it to decay completely. The first case will cause the vehicle to try to reach zero velocity, while the second will leave the motor impotent.
The two motor timescales have very similar names, but have different effects, so try not to get them confused.
- VEHICLE_LINEAR_MOTOR_TIMESCALE is the time for motor to "win", and
- VEHICLE_LINEAR_MOTOR_DECAY_TIMESCALE is the time for the motor’s "effectiveness" to decay
toward zero. If you set one when you think you are changing the other you will have frustrating results. Also, if the motor’s decay timescale is shorter than the regular timescale, then the effective magnitude of the motor vector will be diminished.
Steering the Vehicle
Much like the linear motor, there is also an angular motor that is always on, and whose direction and magnitude can be set. For example, to make a vehicle turn at 5 degrees/sec around it’s local z-axis (its up-axis) you might add the following lines to its script:
vector angular_velocity = <0, 0, 5 * PI / 180>; llSetVehicleVectorParam(VEHICLE_ANGULAR_MOTOR_DIRECTION, angular_velocity);
The magnitude of the angular motor is capped to be no more than two rotations per second (4*PI radians/sec).
Also like the linear motor it has an efficiency parameter, VEHICLE_ANGULAR_MOTOR_TIMESCALE, and a motor decay parameter, VEHICLE_ANGULAR_MOTOR_DECAY_TIMESCALE, which is set to themaximum possible value of 120 seconds by default.
When steering a vehicle you probably don’t want it to turn very far or for very long. One way to do it using the angular motor would be to leave the decay timescale long, enable a significant amount of angular friction (to quickly slow the vehicle down when the motor is turned off) then set the angular motor to a large vector on a key press, and set it to zero when the key is released. Another way to do it is to set the VEHICLE_ANGULAR_MOTOR_DECAY_TIMESCALE to a short value and push the vehicle about with a more impulsive method that sets the motor fast on a key press down (and optionally setting the motor to zero on a key up) relying on the automatic exponential decay of the motor’s effectiveness rather than a constant angular friction.
Setting the angular motor to zero magnitude is different from allowing it to decay. When the motor completely decays it no longer affects the motion of the vehicle, however setting it to zero will reset the "grip" of the vehicle and will make the vehicle try to achieve zero angular velocity.
For some vehicles it will be possible to use the "banking feature" to turn. "Banking" is what airplanes and motorcycles do when they turn. When a banking vehicle twists about its roll-axis there is a resultant spin around its yaw-axis. Banking is only available when using the "vertical attractor" which is described below.
The Vertical Attractor
Some vehicles, like boats, should always keep their up-side up. This can be done by enabling the "vertical attractor" behavior that springs the vehicle’s local z-axis to the world z-axis (a.k.a. "up"). To take advantage of this feature you would set the VEHICLE_VERTICAL_ATTRACTION_TIMESCALE to control the period of the spring frequency, and then set the VEHICLE_VERTICAL_ATTRACTION_EFFICIENCY to control the damping. An efficiency of 0.0 will cause the spring to wobble around its equilibrium, while an efficiency of 1.0 will cause the spring to reach it’s equilibrium with exponential decay.
llSetVehicleVectorParam(VEHICLE_VERTICAL_ATTRACTION_TIMESCALE, 4.0); llSetVehicleVectorParam(VEHICLE_VERTICAL_ATTRACTION_EFFICIENCY, 0.5);
The vertical attractor is disabled by setting its timescale to anything larger than 300 seconds.
Note that by default the vertical attractor will prevent the vehicle from diving and climbing. So, if you wanted to make a airplane you would probably want to unlock the attractor around the pitch axis by setting the VEHICLE_FLAG_LIMIT_ROLL_ONLY bit:
llSetVehicleFlags(VEHICLE_FLAG_LIMIT_ROLL_ONLY);
Banking
The vertical attractor feature must be enabled in order for the banking behavior to function. The way banking works is this: a rotation around the vehicle’s roll-axis will produce a angular velocity around the yaw-axis, causing the vehicle to turn. The magnitude of the yaw effect will be proportional to the
- VEHICLE_BANKING_COEF, the angle of the roll rotation, and sometimes the vehicle’s velocity along it’s
preferred axis of motion.
- The VEHICLE_BANKING_COEF can vary between -1 and +1. When it’s positive then any positive rotation (by
the right-hand rule) about the roll-axis will effect a (negative) torque around the yaw-axis, making it turn to the right -- that is the vehicle will lean into the turn, which is how real airplanes and motorcycle’s work. Negating the banking coefficient will make it so that the vehicle leans to the outside of the turn (not very "physical" but might allow interesting vehicles so why not?).
- The VEHICLE_BANKING_MIX is a fake (i.e. non-physical) parameter that is useful for making banking
vehicles do what you want rather than what the laws of physics allow. For example, consider a real motorcycle... it must be moving forward in order for it to turn while banking, however video-game motorcycles are often configured to turn in place when at a dead stop -- because they’re often easier to control that way using the limited interface of the keyboard or game controller. The VEHICLE_BANKING_MIX enables combinations of both realistic and non-realistic banking by fuctioning as a slider between a banking that is correspondingly totally static (0.0) and totally dynamic (1.0). By "static" we mean that the banking effect depends only on the vehicle’s rotation about it’s roll-axis compared to "dynamic" where the banking is also proportional to it’s velocity along it’s roll-axis. Finding the best value of the "mixture" will probably require trial and error.
The time it takes for the banking behavior to defeat a pre-existing angular velocity about the world z-axis is determined by the VEHICLE_BANKING_TIMESCALE. So if you want the vehicle to bank quickly then give it a banking timescale of about a second or less, otherwise you can make a sluggish vehicle by giving it a timescale of several seconds.
Friction Timescales
VEHICLE_LINEAR_FRICTION_TIMESCALE is a vector parameter that defines the timescales for the vehicle to come to a complete stop along the three local axes of the vehicle’s reference frame. The timescale along each axis is independent of the others. For example, a sliding ground car would probably have very little friction along its x- and z-axes (so it can easily slide forward and fall down) while there would usually significant friction along its y-axis:
llSetVehicleVectorParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, <1000, 1000, 3>);
Remember that a longer timescale corresponds to a weaker friction, hence to effectively disable all linear friction you would set all of the timescales to large values.
Setting the linear friction as a scalar is allowed, and has the effect of setting all of the timescales to the same value. Both code snippets below are equivalent, and both make friction negligible:
// set all linear friction timescales to 1000 llSetVehicleVectorParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, <1000, 1000, 1000>); // same as above, but fewer characters llSetVehicleFloatParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, 1000);
/VEHICLE_ANGULAR_FRICTION_TIMESCALE is also a vector parameter that defines the timescales for the vehicle to stop rotating about the x-, y-, and z-axes, and are set and disabled in the same way as the linear friction.
Buoyancy
The vehicle has a built-in buoyancy feature that is independent of thellSetBuoyancy call. It is recommended that the two buoyancies do not mix! To make a vehicle buoyant, set the VEHICLE_BUOYANCY parameter to something between 0.0 (no buoyancy whatsoever) to 1.0 (full anti-gravity).
The buoyancy behavior is independent of hover, however in order for hover to work without a large offset of the VEHICLE_HOVER_HEIGHT, the VEHICLE_BUOYANCY should be set to 1.0.
It is not recommended that you mix vehicle buoyancy with thellSetBuoyancy script call. It would probably cause the object to fly up into space.
Hover
The hover behavior is enabled by setting the VEHICLE_HOVER_TIMESCALE to a value less than 300 seconds; larger timescales totally disable it. Most vehicles will work best with short hover timescales of a few seconds or less. The shorter the timescale, the faster the vehicle will slave to is target height. Note, that if the values of VEHICLE_LINEAR_FRICTION_TIMESCALE may affect the speed of the hover.
Hover is independent of buoyancy, however the VEHICLE_BUOYANCY should be set to 1.0, otherwise the vehicle will not lift itself off of the ground until the VEHICLE_HOVER_HEIGHT is made large enough to counter the acceleration of gravity, and the vehicle will never float all the way to its target height.
The VEHICLE_HOVER_EFFICIENCY can be thought of as a slider between bouncy (0.0) and smoothed (1.0).
When in the bouncy range the vehicle will tend to hover a little lower than its target height and the VEHICLE_HOVER_TIMESCALE will be approximately the oscillation period of the bounce (the real period will tend to be a little longer than the timescale).
For performance reasons, until improvements are made to the Second Life physics engine the vehicles can only hover over the terrain and water, so they will not be able to hover above objects made out of primitives, such as bridges and houses. By default the hover behavior will float over terrain and water, however this can be changed by setting some flags:
If you wanted to make a boat you should set the VEHICLE_HOVER_WATER_ONLY flag, or if you wanted to drive a hover tank under water you would use the VEHICLE_HOVER_TERRAIN_ONLY flag instead. Finally, if you wanted to make a submarine or a balloon you would use the VEHICLE_HOVER_GLOBAL_HEIGHT.
Note that the flags are independent of each other and that setting two contradictory flags will have undefined behavor. The flags are set using the script callllSetVehicleFlags().
The VEHICLE_HOVER_HEIGHT determines how high the vehicle will hover over the terrain and/or water, or the global height, and has a maximum value of 100 meters. Note that for hovering purposes the "center" of the vehicle is its "center of mass" which is not always obvious to the untrained eye, and it changes when avatar’s sit on the vehicle.
Reference Frame
The vehicle relies on the x- (at), y- (left), and z- (up) axes in order to figure out which way it preferres to move and which end is up. By default these axes are identical to the local axes of the root primitive of the object, however this means that the vehicle’s root primitive must, by default, be oriented to agree with the designed at, left, and up axes of the vehicle. But, what if the vehicle object was already pre-built with the root primitive in some non-trivial orientation relative to where the vehicle as a whole should move? This is where the
VEHICLE_REFERENCE_FRAME parameter becomes useful; the vehicle’s axes can be arbitrarily reoriented by setting this parameter.
As an example, suppose you had built a rocket out of a big cylinder, a cone for the nose, and some stretched cut boxes for the fins, then linked them all together with the cylinder as the root primitive. Ideally the rocket would move nose-first, however the cylinder’s axis of symmetry is its local z-axis while the default "at-axis" of the vehicle, the axis it will want to deflect to forward under angular deflection, is the local x-axis and points out from the curved surface of the cylinder. The script code below will rotate the vehicle’s axes such that the local z-axis becomes the "at-axis" and the local negative x-axis becomes the "up-axis":
// rotate the vehicle frame -PI/2 about the local y-axis (left-axis) rotation rot =llEuler2Rot(0, PI/2, 0); llSetVehicleRotationParam(VEHICLE_REFERENCE_FRAME, rot);
Another example of how the reference frame parameter could be used is to consider flying craft that uses the vertical attractor for stability during flying but wants to use VTOL (vertical takeoff and landing). During flight the craft’s dorsal axis should point up, but during landing its nose-axis should be up. To land the vehicle: while the vertical attractor is in effect, rotate the existing VEHICLE_REFERENCE_FRAME by +PI/2 about the left-axis, then the vehicle will pitch up such that it’s nose points toward the sky. The vehicle could be allowed to fall to the landing pad under friction, or a decreasing hover effect.