Wind and Rotations

So I must apologize for (A) having gotten distracted from the combat-system scripting by thinking about the details of sailboat physics, and (B) posting some stuff here that is really just for me, but I thought it might someday be useful to someone else to, and besides this was a handy place to jot it down.

There are an annoying number of ways to write down rotations and directions and things in LSL, and different parts of the word want different ones. (And this is just, for the moment, talking about rotations in two dimensions!)

For instance, llWind() returns a vector representing the wind direction. Wind is (I believe!) always flat (parallel to the ground) in SL, so we can ignore Z. But what exactly are X and Y?

Well, Rule 1 (which I always forget and have to try out again) is that X is East and Y is North. So if for instance I am standing at 117, 119, 117 in Hughes Rise, on the walkway in the Park, and I walk one meter due North, I’ll be at 117, 120, 117. See how Y got bigger? And if I walk one meter due West from there, toward the stairs, I’ll be at 116, 120, 117; X got smaller.

So if llWind returns < 5, 0, 0 > for instance, that means the wind is blowing at five meters per second toward the East (and therefore is called a West wind, ’cause winds are called by where they are coming from, just to be confusing).

Now say you have a sail, and you want to know the angle between the sail and the wind. Well, the sail’s trim is represented as a rotation, which can be represented in LSL either as an actual rotation object (which has four components, corresponding to the four components of the corresponding quaternion, where a quaternion is of course an element of a four-dimensional associative normed division algebra over the real numbers), which is mathematically wonderful but not too useful for actually thinking about, or as a three-element vector, each element representing a rotation about the corresponding axis.

So for instance if your sail is flat in the X dimension, it will be facing head-on to winds coming from the east or west. If you then rotate it ninety degrees (which is a rotation of pi/2, or PI_BY_TWO, in radians) about the Z axis (the up-and-down one), it will be facing head-on to winds coming from the north or south.

To represent a rotation of pi/2 radians as a vector in LSL, we write < 0, 0, PI_BY_TWO >. Now the fun part! If I know the X and Y parts of the wind speed from llWind, and I have the rotation of my sail as a rotation about the Z axis, how do I figure out the angle at which the wind is hitting my sail?

Now I pause to think and experiment a little, so as to have an answer to write down in the next paragraphs. :)

Well, first of all notice that by using a symmetrical sail and a rotation of pi/2, I’ve sort of cheated; in particular, I didn’t have to figure out whether rotations are clockwise or counterclockwise (anticlockwise). This is probably obvious to smart people of various kinds, but I can never remember it (some Right Hand Rule or something is probably involved) so I have done the experiment and will write down Rule 2: Rotations are counterclockwise, or, to be precise and therefore meaningful, if you’re looking down at something that is not rotated, and you rotate it positively about the Z axis, it moves around anticlockwise.

This surprised me. :)

It makes sense, though, if we think back to like Trig 101 or whatever that was; X is East (i.e. to the right on the map), and Y is North (upward on the map), which is just how the graphs were all done on the board, and if you start out with a line running from the origin to < 1,0 >, say, and “rotate it” by some small angle theta, it goes up a bit into th’ ol’ First Quadrant there, which means it’s moved anticlockwise.

(Whoever designed clocks must have skipped that class or something.)

So we can represent wind direction as a rotation-about-Z by drawing it on the board there using the X and Y that we got from llWind(), and straightforwardly figure out what angle we would have to rotate that origin-to-1,0 line through to get it there, and it turns out to be (unless I’m wrong) llAtan2(Y,X); that is, the angle whose tangent is y over x.

So we have two rotation amounts, the amount that our sail’s been rotated and the amount that the wind’s been “rotated”, and we can just subtract them from each other to get the angle between them. If they’ve been rotated the same, the difference is zero, and our sail is getting (basically) all of the benefit of the wind. If they are ninety degrees apart, the sail is edge-on to the wind, and getting no benefit at all. Because we suspect there is probably something trigonometric going on here, we will note that llCos(0) is 1.0, and llCos(PI/2) is 0.0, and decide that we can do, say:


vector wind = llWind(ZERO_VECTOR); // The wind right here
float windrotz = llAtan2(wind.y,wind.x);
vector sailrot = llRot2Euler(llGetLocalRot());
float sailrotz = sailrot.z;
float rot_difference = windrotz - sailrotz;
float wind_effect_on_sail = llCos(rot_difference);


and so wind_effect_on_sail will be 1 if the wind’s blowing right onto the sale, will be 0 if the wind is blowing edge-on onto the sail (luffing!), and will be inbetween in between. (It will also be negative, I think, if the wind is blowing on the wrong side of the sail, but I haven’t thought about that yet.)

And some similar calculation can be used to get the angle between the sail and the hull (or, really, the keel), to figure out how much of the wind’s effect on the sail then contributes to the forward motion of the boat. But that’s a little later. :)

More Phunny Physics

As I’ve mentioned before, having actual physics (with gravity and friction and collisions and stuff) in a virtual world (especially one with dynamic and unpredictable content) is really hard, and Second Life has compromised by having just enough physics to make some common things (falling, driving vehicles) work well enough to make us happy, and leaving much of the rest of the physics pretty strange and random. So except for AVs and vehicles and a couple of other narrow examples, very little of what we see in SL is actually subject to physical law.

It occurred to me the other day that one fun physical thing to make would be a simple chain. So I did.

“Look,” I am saying to myself up in my unwalled sky-laboratory, “I have made a chain of rings!”

The top chain in the picture is nonphysical, so it stays just where it’s put, floating there. The other four are physical, and they swing freely.

A few days later:

“Egad,” I say to myself, “the physical rings are gone! How can this be? Where have they gotten to? Perhaps I should have done this experiment in a ground-level laboratory that had walls!”

I get out a hoverdisc and an object-scanner, both of my own devising, and go ring-hunting. I find the first one quickly:

It is sitting down below my sky-laboratory, right next to the 100m flagpole that leads up to it, hovering motionless in the air, and no longer physical. Don’t know how it managed to get detached, or what could have turned off the physical bit.

I continued hunting, and two of the others were also non-physical and also in midair, somewhat lower down, apparently embedded in a neighbor’s banline wall.

I eventually found the last one, maybe 100m away horizontally, lying on the ground on someone else’s parcel, still physical.

Very very odd!

I have nothing very profound to say about this, except that one should obviously not expect things held together by mere physics to stay together, even if they are (for instance) a set of linked solid rings. I don’t know how long it took them to uncouple, or what did it. They were as far as I know not subject to wind pressure, nor were they set to “allow anyone to move” which might have allowed a passerby to give a good stiff yank. Although I suppose someone simply flying into them at high speed could have imparted enough energy to defeat physics engine and unlink the rings.

Should have left a videocamera going…

Phunny Physics

The other evening I wanted to make something simple and interesting, and it occurred to me that I really don’t know much about SL physics, so I thought I’d build a simple physical experiment: a sand-pile maker:

(Mad Photoshop Skillz used to fade the non-essential things like me and the rest of the Hughes Rise Park in the image.)

The blue thing there sits aways off the ground and every few seconds drops a little decimeter-sized cube; over time this forms a pile. If I had done this in a parcel with lots and lots of prims available, I could have let it drop a few hundred, to see what happens. But even after only a few dozen, the pile is noteworthy:

Note that it’s a rather flat pile, and most especially note that some (many) of the blocks are sort of floating in midair. This isn’t an action shot of the pile collapsing, catching cubes as they bounce around or anything like that; this is the static state of the pile after I turned off the dropper. So the floating is a tad unexpected.

It turns out that the SL physics engine is quite approximate. When figuring out physical interactions, it will get things more or less accurate to the tenth of a meter, but not any finer than that. Meaning that a physical decimeter cube may act as though it’s anywhere up to twice as big as it is; in this case by hovering suspended in the air, because the physics engine thinks that it’s resting on the ones below it, or close enough anyway.

SL physics is wonky in a number of other ways, due to this and other approximations. (For instance if you slam a physical object into a wall fast enough, it will pass right through a good fraction of the time.) Why don’t we Residents notice this more? Two reasons occur to me.

First, the vast (vast) majority of things in SL (AVs not included) aren’t physical! Prims are subject to the full laws of physics (such as they are) only if a particular box in the editing control is checked. And prims with that box checked are always falling over or sliding away or generally misbehaving, so creators don’t check that box without good reason. Prims without that box checked are non-physical, and stay wherever the heck they’re put (which is why my sandpile maker can just sit there in midair, and why we think nothing of seeing an informational sign sitting placidly half a meter off the ground with no visible support, and why skyboxes don’t need expensive anti-gravity generators).

Non-physical prims do serve the useful purpose of blocking vision (unless they’re transparent) and blocking the motion of AVs and physical objects (unless they’re phantom), but mostly the laws of physics ignore them. They can interpenetrate each other, sit in midair without support, never fall over on their own, etc.

Second, the most common physical objects that we do encounter are vehicles. Boats and cars and motorcycles and balloons and so on are usually physical, but they’re a rather special kind of physical object governed by one or more scripts that use the special vehicle-related scripting verbs. These verbs are designed specifically for the special case of vehicles, and they go some ways toward hiding the wonkiness of the underlying physics by making specifically vehicle-like operations work more or less as expected (sometimes definitely less, as anyone who’s done much vehicle driving knows).

Why is the physics engine wonky in this way, so that we have to be protected by living in a largely non-physics world where most of the physical things that we use are specially scripted to be vehicles? Why not just have a consistent laws of physics that everything obeys? The answer is that simulating physics is really really hard. The RL universe cheats by using massively parallel hardware; LL can’t afford that kind of compute power. Some other virtual worlds (WoW, Lively) have no notion of physics at all as far as I can tell, except in the degenerate sense that stuff stays where it’s put.

It’ll be interesting to see how this aspect of VWs plays out in the future. Will we see VWs with more and more powerful and “realistic” (or creatively unrealistic) physics engines, and will the laws of physics come to govern more of the virtual stuff that we work with? Or will this kind of physics remain a sort of a curiosity, turnable on for special cases (like vehicles or cannonballs), but off most of the time, because the physics that we really want in our VWs is a simple physics where things stay pretty much wherever they’re put?

(If you know of any virtual worlds that have more or different physics, do post in the comments! I know Torque has some, which are also pretty wonky, and I think some of the other game engines have pretty sophisticated ones, but I don’t know the details.)

And just for completeness, here’s a picture of me swimming with some otters in Firespire (I think it is):

Wheeeee!