Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

help... efficient vector handling

Kafka Potato
Registered User
Join date: 23 Mar 2006
Posts: 17
12-25-2006 09:11
I'm trying to figure out something efficient for this problem ...
the situation is I will have a vector and I want to take 4 actions based on movement vector. It's actually fairly simplified, the vector will only have one no zero component and only on the x and y axis. Basically, it'll be a north, south, east, or west vector of some magnitude.
ie:
<0.5,0.0,0.0>
<0.0,-0.2,0.0>

never:
<0.2,-0.3,0.0>

now there's a fairly straightforward set of if else's, dealing with the x and y components of the vector.. but it just strikes me as too ugly ;)

Anyone found a more clever trick for this?

Thanks
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
12-25-2006 09:24
I would probably need some more details on your application, as the problem you are describing doesn't quite congeal in my head. :)

Is it a storage representation problem, or a code efficiency (or elegance) problem?
Kafka Potato
Registered User
Join date: 23 Mar 2006
Posts: 17
more specifics
12-25-2006 10:02
Ok, it's a code efficiency problem.

Storage isn't an issue.

but the vector will represent a cardinal direction... North, south... etc. of varying magnitude

I have to make a decision based on the cardinality of the direction. Either the x or the y component of the vector will be non zero, the z will always be zero.

I'm trying to figure out if there is a better way for making that decision.

The simple solution seems:

x != 0
then if x >0

else

hopefully where this is leading is clear now...

The full problem is determining if an object collided with something directly in it's path (when I would like to change it's direction) or if it just side swiped something, in which case, I want to maintain it's current trajectory and ignore it) determining that is a fairly simple comparison of the magnitude of the difference in postion in x and y of the collision and comparing that to the current direction of force (ok there is a bit of a precision problem when the object is struck close the the center.. but that's ok for my purposes). For some reason... I keep feeling there is a more efficient method to determine my current direction and make the decision rather than the comparison of individual x and y components of the force vector.


In plain english... if I am travelling north and strike something to the east of me, I want to keep traveling north. If I strike something to the north of me, while I'm travelling north I want to change directions.

the thing I am trying to make more efficient is the decision tree based on what direction I'm traveling and I'm hoping that there is a better way to determine that, than by breaking out and comparing the individual x and y components of the vector.
Kafka Potato
Registered User
Join date: 23 Mar 2006
Posts: 17
one last point
12-25-2006 10:41
I should make clear my real goal is efficiency... I have found that is lsl, what seems elegant is frequently not very efficient. I'm entirely content to accept that the if/then else's I have are the most efficeint... But i'd really like to have something to compare it to.
Seifert Surface
Mathematician
Join date: 14 Jun 2005
Posts: 912
12-25-2006 11:37
I would look at something like this:
CODE

vector a = llVecNorm(their_pos - my_pos);
vector b = llVecNorm(my_vel);
float c = a * b;

The condition you're looking for is colliding with something in the direction you're travelling, which means that a and b are in the same direction. Since the dot product of two unit vectors is the cosine of the angle between them, you can check this by seeing if c > 0.707, because 0.707 is approximately cos(45 degrees).
_____________________
-Seifert Surface
2G!tGLf 2nLt9cG
Kafka Potato
Registered User
Join date: 23 Mar 2006
Posts: 17
this helps a lot
12-25-2006 13:53
Well.... the solution isn't quite that simple :P but that is due to the geometry of the object colliding. But, thanks for the vector functions. I wasn't familiar with them and hadn't thought to go that route(obvious in hindsight), and I think they will simplify things a bit. I was under the impression that these math calls were expensive... so I'll have to test for overall speed.

Thanks a lot.
Seifert Surface
Mathematician
Join date: 14 Jun 2005
Posts: 912
12-25-2006 14:03
In terms of speed, I think the perceived wisdom is to use as few LSL calls as possible. If there's a way to do something with the built in functions, rather than writing your own in LSL it's probably going to be faster.
_____________________
-Seifert Surface
2G!tGLf 2nLt9cG