This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Understanding Vehicle Scripting
#1
This info is intended for understanding how physcally moving objects & Vehicles work in Opensim ore SL

It is not the goal to hold a programming course.
 

What you need for scripting can be found in the Secondlife Wiki- 
"http://wiki.secondlife.com/wiki/LSL_Portal" however, guidance on understanding is lacking. I am now trying to close this gap here.


Basics of the drive and control principle:
 
In Opensim / SL there is no real physics that realistically moves a vehicle. You have to make sure that this vehicle behaves like this.
 
Examples:

- There is no real friction and grip: an open-sim tire of a car does not exert any lateral force in the curve to keep the vehicle on track.
- There is no real buoyancy in the water: A boat sinks to the bottom of the Sim or another obstacle if you do not prevent this in the script using appropriate motor parameters.

These are only 2 examples, but they show the dilemma when you want to build something that is mobile, flying, etc. quickly.
 
Since there is no friction, you do not need rolling tires to minimize them. A changeover if you come from the real world.
For Opensim, a prime cube roughly shaped like a collision is sufficient for the movement.
This is just as versatile as the tampons described in television advertising 20 years ago. It can be used for riding, swimming, car & boating, flying, ...
 
root prim:

This throw represents the (mostly transparent) root prim of all vehicles. This contains the driving scripts, animations and much more.
What you see against it is a linked mesh. This is only for the optics and is urgently to be set to phantom via script.

In this context, it is imperative to point out the absolute minimization of the collision-carrying physics shell if you want to create a well controllable high-performance vehicle. 
Whoever gets by with a cube with slanted front surfaces is the best choice here.

Since movement is counted as pushing a cube on the surface, it is important that the edges do not get caught. As a result, most forms of physics look like a sled.
Now let's take a look at the movement of this "Prim Cube" vehicle:
 
MOVE:

- Physical objects are periodically supplied with impulses that are supposed to bring about a desired movement.
The best way to describe this is with an impulse force that can be exercised in 6 different directions. Every force knows possible 2 directions.
 
VECTOR FORCES:

First there are the 3 vector forces in the Cartesian coordinate system - i.e. X, Y, Z axis. These act as vectors related to the orientation of the vehicle.
Since each vector can be positive, zero, or negative, 6 forces (each related to the orientation of the vehicle) can be generated:
The vector forces are displayed on the 
LINEAR MOTOR.
All of these vector forces only act as a parallel displacement of the vehicle (object) without causing rotation.
 
vector LinearMotor = <Linearmotor.x, Linearmotor.y, Linearmotor.z>;
 
Longitudinal force: Linearmotor.x - Executes a movement in the object axis
- Forward acceleration pulse (Linearmotor.x> 0)
- Brake pulse backwards (linear motor.x <0)
Use as a propulsion engine for every vehicle.
 
If you want to stop by the way, you should pass Linearmotor.x = 0 to the vehicle several times. This takes longer, but does not lead to reversing.
 
Lateral force: Linearmotor.y - Performs a lateral shift across the object axis
- Shift momentum to the left
- Shift momentum to the right
Application: Locomotive transfer platform, the locomotive is moved across the rail to the next siding.
 
But first you have to be clear about the real movement of the vehicle to be built.
For example, an airplane does not fly to the left, but rolls over the longitudinal axis (AngularMotor.x) and then gives thrust on the Z axis (AngularMotor.z).
If you also lift the nose of the jet slightly (AngularMotor.y) then it looks realistic.
A car, on the other hand, would only be turned on the AngularMotor.z axis, because the road is a solid surface.
However, if I use a linear motor, I can simulate the side insertion of a load with a forklift.
 
Rising force: Linearmotor.z - Performs a parallel shift in the height axis of the object.
- Impulse to gain height
- Impulse to lose height
Application for example for an elevator.
 
Exercise of linear vector force:
Whenever the following command is called in the script, the vehicle is supplied with vector power:

llSetVehicleVectorParam (VEHICLE_LINEAR_MOTOR_DIRECTION, <longitudinal force, lateral force, increasing force>);
or in previous notation:

llSetVehicleVectorParam (VEHICLE_LINEAR_MOTOR_DIRECTION, <Linearmotor.x, Linearmotor.y, Linearmotor.z>);

After that, there is a steady decline in forces. If the forces are not refreshed too often, the vehicle stops.

Conversely, calling the impulse routines too often is also harmful because the script load increases. Depending on the vehicle, every 1 second should be sufficient. 
If the vehicle is not moving, the power should be increased. The goal is a vehicle that responds well to steering commands and generates as little load as possible.

So that a pulse does not lead to jerky acceleration, there is a damping mechanism for how quickly the vehicle reacts to the pulse.
The best way to imagine this is with inertia braking when accelerating. Nevertheless, the set maximum speed will be reached at some point.
The speed that can be achieved depends on the power and frequency of the call.


ROTATION FORCES: 
 
In contrast, the 
ANGULAR MOTOR is used to describe the rotational forces.
This also has 3 parameters, each of which can be positive, zero, or negative.
 
The angular motor describes the impulse in 3 rotation axes in order to trigger a corresponding rotary movement.
 
Rotation transverse to the longitudinal direction:
AngularMotor.x - Rotates left or right to the direction of the object.
Application: list of a boat. Lateral swaying of a board on which one is running.
 
Rotation in the longitudinal axis:
AngularMotor.y - Performs a rotating movement of the object that can be recognized as diving or surfacing.
Application: Raise airplane nose for climbing, or lower tip of a snowboard when going downhill.
 
AngularMotor.z - Rotates an object to the right or left that is perceived as steering a car. The car turns with it.
Application: typical steering of a vehicle bound to the ground.


Provides the vehicle with rotary movement:
llSetVehicleVectorParam (VEHICLE_ANGULAR_MOTOR_DIRECTION, AngularMotor);

Or in another writing for better understanding:
llSetVehicleVectorParam (VEHICLE_ANGULAR_MOTOR_DIRECTION, <Angularmotor.x, Angularmotor.y, Angularmotor.z>;
 
The same applies to linear vectors here: there is an adjustable damping until the force acts, and an adjustable after-effect period until the force has dropped to 0.
 
An important learning goal with physics engines is that energy is consumed, and the stable idle state is automatically restored when the energy supply is interrupted.
 
 
 
Declaration AREA:
 
vector LinearMotor; // 
preferably global at top of the script
vector AngularMotor; // 
best locally in the control section
 
Caution it is essential for the vehicle where the declaration is made.
If it occurs globally at the beginning of the script, energy can be "retained" and used as residual energy the next time the key is evaluated.
This enables real starting and stopping without abrupt acceleration.

The LinearMotor call belongs to motor-driven vehicles with the same period. The timer section is best suited.
 
On the other hand, this behavior is often undesirable during steering movements.
Here I recommend the declaration of the Angular Motor directly in the "control" section.
This acts like an automatic steering wheel reset to statically straight ahead.
The AngularMotor call therefore belongs in the control routine so that it only occurs when the steering is actually in motion.
 
All of these recommendations apply to the “normal case”. there are reasons to do it differently in individual cases.
 
Have fun
 
Tron
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste