couple more lsl calls

float llGetVolume() - returns the volume of the object
float llGetDensity() - all though this could be done with float llGetMass()/llGetVolume().
float llGetInertia() - this call would return the rotational inertia about the objects center of mass
vector llRotationalVelocity() - determines the angular velocities about each axis

now why do i want all these? well i am trying to do a transposeRotation function, and i can determine the angular accelerations needed to get from one angle to another, but that doesn't tell me the torque. and the simplest way to determine the torque is inertia*angular_acceleration.

Does llGetTorque() not do what you need?

next you're going to want llGetQuantumState()

Here ya go phil

float llGetQuantumState()
{
    return llFrand(1);
}

no. torque is akin to force, so if we knew the inertia we could determine the angular acceleration, like if we know the force and the mass we can determine the linear acceleration, but we cannot determine the angular velocity unless we know more, like its initial angular velocity, and the time that the angular acceleration(caused by a torque) was applied, just like we need to know the initial linear velocity and the time the acceleration(caused by a force) was applied to determine the final velocity of an object.

these equations assume constant angular acceleration.

theta(final) = theta(intial) + angular_velocity(intial)*time + 1/2*angular_acceleration*time^2

angular_velocity(final)^2 = angular_velocity(intial)^2 + 2*angular_acceleration(theta(final) - theta(intial))

angular_velocity(final) = angular_velocity(intial) + angular_acceleration*time

sum_of_the_torques = rotational_inertia * angular_acceleration

rotational_inertia = sum_of (mass * radius^2)

if they can give me the quantum state... then i might be able to script up a blackhole, and hold the all the sims ransom! MUHAHAHAHA... heh oops, better just stick with the inertia and angular velocity

Nada says:

The lsl reference says:

It sounded like you wanted those to find the torque, and lsl offers a method for getting the torque, with that standard less than helpful documentation. So I asked. I know how to calculate torque (I was 1 class away from a minor in physics. ), but the easier way than inertia*angular_acceleration is a straight linden library call that does it all for you. hehehe

What exactly is this transpose rotation thing supposed to do? Create an equal rotation in the opposite direction?

heh sorry, bad wording on my part. let me clarify.

the function i am writing will smoothly rotate an object from one orientation to another, using a llSetTorque. It does this by calculating the angular acceleration needed to get half the theta in half the time. So I have angular acceleration, and now i need to compute that into the necessary torque (this is where the confusion began). So to compute the torque, i need the inertia of the oject i am trying to rotate(if it were just a circular disk it wouldn't be a problem).

I have a transposeVector one written already, that determines the distance you want to travel, calculates the force to get you half the distance in half the time, applies this force, waits half the time, and then applies the inverse of the force for half the time. So I am doing the same thing for the rotations.

llGetVolume() -- how is this one useful?

llGetDensity() -- uh... right now all objects have the same density. Variable density probably won't be in until we move to Havok 2.0, which will be a convenient point for doing density right.

llGetInertia() -- the inertia is actually a tensor (3x3 matrix). Sorry, there is no matrix type currently in LSL yet. In your math above you assume the inertia is just a collection of point masses at known radii from your axis of rotation, however if that assumption fails and you try to use it to control an non-symmetrical object that is obeying true rigid-body-dyanmics you will end up with... uh... unstable tumbling (trust me... I've been there).

llAngularVelocity() -- (note the name change might be useful, however what you want to use it for sounds like nitty-gritty physics magic that we were hoping to make uneccessary by providing some calls that do most of the magic for you like llRotLookAt(). Unfortunately we probably haven't provided all of the basic methods yet. But we want to... especially since it will empower those users who don't know how to or don't want to do the physical details (the vast majority of them).


Finally, running loops in the scripting language that are supposed to provide rapid control of an object is... uh... problematic. The scripts run asynchronously with the physics engine, so you don't have high resolution control of when the next line of the script is going to execute. So making the scrpt do all of the movement details will only work reliably if the timescale of the operation is rather long (i.e. the object is moving very sssslllloooowwwlllyyy).

Ok, so here is an idea that may work for you... however it also works best on a slow timescale. Excactly how slow is not clear to me yet... I'd have to actually try it. Also it only works for "physical" objects that are free to move.

Use llRotLookAt(), but provide a large value or "tau"... start with about 5 seconds then try making it tighter until it gets jerky. T'au is the timescale for the critically damped motion to get to 1/e of its initial displacement.

Then, write a script with a looping timer that moves the target rotation from where you are to where you want to be in even steps. Since the object is following the target rotation with a slow response its rotational motion will be filtered smooth even though the jumping of the target is not.

For extra points you could do some dynamic tweaking of the "tau" to get more immediate response at the beginning and end of the motion.

well llGetVolume would have made it so i could have figured out the density by doing llGetMass/llGetVolume, rather than

vector dim = llGetScale();
density = llGetMass()/(dim.x*dim.y*dim.z);

and i was using the density to ultimately calculate the inertia of my test object.

ok so i will hold off on the rotation by torque, and see what i can come up with using the llRotLookAt method.

and yes, the llAngularVelocity() was for nitty gritty physics calculations, what can i say, i want it all now!

so basically what you are telling me is that i have to wait, but i don't want to . I have written a transpose vector script that works perfectly about 3/4 of the time, the other 1/4 of the time, the first force isn't applied, so when it applies the second it just ends up going the opposite direction. I think i have some fail-safes that will help keep this from happening, i will have to test them tonight.


Thanks andrew!

I've noticed that time interval thing while working on the tracking turrets for the arena game and was wondering if that was just lag or I was doing something wrong, if I tried anything lower than a second or two it didn't seem to work consistently at all, fantastic info thanks

heh, well andrew, i goofed on one of the calls. we already have a llGetAngluarVelocity... llGetOmega... i was helping some one with an llTargetOmega script, when it hit me, 'Duh, i feel mildly retarded!" so i saw doug and told him about it, he then preceded to make some snide comment about physics people, heh, followed by this:


anyways, so i change my request to a renaming of said library call. and i blame my ignorance on the zen like quality of the manual. Jake, i will get you some stuff by the end of the week to put into the chm file(and one of them is going to be llGetOmega haha).