Vector value limits

I'm slowly coming up against script memory limits in a project... one section that seams bloated is for clamping values in a vector, and another for wrapping around values.

Is there a more efficient way of doing these two limits/wrap arounds?

if (pose_offset.x > 5.0) pose_offset.x = 5.0;
else if (pose_offset.x < -5.0) pose_offset.x = -5.0;
if (pose_offset.y > 5.0) pose_offset.y = 5.0;
else if (pose_offset.y < -5.0) pose_offset.y = -5.0;
if (pose_offset.z > 5.0) pose_offset.z = 5.0;
else if (pose_offset.z < -5.0) pose_offset.z = -5.0;



pose_rot = <llRound(pose_rot.x * 10), llRound(pose_rot.y * 10), llRound(pose_rot.z * 10)> / 10;
if (pose_rot.x > 180.0) pose_rot.x -= 360.0;
else if (pose_rot.x <= -180.0) pose_rot.x += 360.0;
if (pose_rot.y > 180.0) pose_rot.y -= 360.0;
else if (pose_rot.y <= -180.0) pose_rot.y += 360.0;
if (pose_rot.z > 180.0) pose_rot.z -= 360.0;
else if (pose_rot.z <= -180.0) pose_rot.z += 360.0;

yes


ETA:
wrapping versions should use the modulus operator when possible, which may require a shift before and after to get a lower bound of 0 while doing calculation. I'll add it to the TODO list for the above page

I'll take a look!

Yeh, I had planned on using mod, but there was something it did, and I can't remember... I think it gave me 180 and -180, and just to be picky, I didn't want -180.

although for reference... SL will correctly wrap out of range degrees. so 450 will still yield 90 inworld.

unfortunately you can't use modulus with floats in SL (only a few languages allow that), which is why I said IF possible... conversion to integers would probably cost you more when dealing with vectors.

Yeh, the -180 to 180 is more of a display/export issue than an application of the value issue.

Looking at the logic of the other, I can use something similar to the clamp routine to wrap around... using the assumption that I'll never be more than 10 degrees over or under -180/180, I don't have to worry about doing a mod.

How come there is no min/max functions for integers and/or floats? I know about the one for list statistics but that's pretty limited. There are lots of times where min/max functions would be very helpful when not working with lists.

For example, in this case:

pose_offset.x = llMax(-5.0,llMin(pose_offset.x, 5.0))

Or did I miss it somewhere? I've needed this often.

nope, you didn't miss it. and actually the lists stats functions were added in the last batch of additions. there are ways to do it (if you know your likely overage, underage amounts, you can compress the range with division, and llFloor, or llCeil outside values, but you loose accuracy on floats)

BTW, if your range clamping doesn't have to be exactly what you're doing, consider using llVecNorm().

That is, if (5,5,5) is a relatively arbitrary limit, and the limit doesn't need to be a cube dimensionally, you can use this:

float LIMIT = 5.;
if (llVecMag(myvec) > LIMIT) {
myvec = LIMIT * llVecNorm(myvec);
}

This isn't what you asked for, but might be a substitute.

I don't think that going to work quite so well in capping/wrapping individual elements (in this case degrees)

Right: the OP mentions both clamping and wrapping. Using vector magnitude wouldn't do quite what's wanted for wrapping, and may or may not do what's wanted for clamping. It definitely isn't clamping individual values, as asked. But sometimes, we don't think of other possibilities and our questions are narrower than our problems.

For wrapping a Euler intended for inworld display, where the value to be wrapped won't ever be more than 360 degrees past the limit, this works...

vec_rot += <vec_rot.x > 180) * -360 + (vec_rot.x <= -180) * 360,
(vec_rot.y > 180) * -360 + (vec_rot.y <= -180) * 360,
(vec_rot.z > 180) * -360 + (vec_rot.z <= -180) * 360>;

I never thought of using the TRUE/FALSE evaluation as a multiplier in equations like these.

Void, should I fear the warnings about the clamp routine not working reliably in Mono for the example you referenced?

no, it's just llGetFreeMemory that is inconsistent... the clamp functions themselves run just fine... maybe I'll rewrite that note to be more clear.

How about this:

myvec = llRot2Euler(llEuler2Rot(myvec * DEG_TO_RADIANS)) * RADIANS_TO_DEG;

Probably slower, but might be smaller. Unfortunately, you'd also get the nonintuitive flipping that we see when rotating prims while watching the numbers in the build panel. Also, the ranges would be (-180, +180] rather than [0, 360).

you can cheat the ranges by subtracting out degrees before and adding them after

Lear, that is what I originally had, but I can't quite remember why I dropped that. I know there was a little error accumulated, but nothing that a simple rounding routine couldn't clear up.... I think I may go back and try it again just to see what it was that I didn't like.