Angle Finding

I've got a whole new problem for y'all! One that I sincerely hope can be solved.
So... ever since my battle to fit the "Pythagorean Theorem" into analogue logic (doable but... clunky), I've been progressing with my 3D project.
Admittedly, using my Pythag chip wouldn't be a problem, it's what comes next that I didn't foresee.

You see, the use of the Pythag chip was to provide value for the distance my character was from an object in 3D space:

http://i1383.photobucket.com/albums/...pstjlls5hb.jpg

This could be done in the (x,y) plane without coords by using a tag-sensor (since they operate in radial space rather than Cartesian space).
But... in the (y,z) or (x,z) planes, tag-sensors can't work, since they don't detect depth.
For that reason, I needed an analogue layer-sensor to provide me with z-axis coords, so that I could satisfy a depth-wise pythag formula.
I've finally got all that junk... at the expense of piston triangles everywhere.

What I need now is a way to find angles for my triangles (which operate using pistons).
Currently, my triangle prototype's vertical leg has a "tag" on it's end, while the horizontal leg has a block that pivots using a "look-at rotator." The pivoting blocks angle, as it stares at the tag, provides me with what I need, but I need a way to do this without tags.

http://i1383.photobucket.com/albums/...psd9i1ssq7.jpg

I'm going to be emitting and destroying these triangles ad-nauseum, so I can't risk one's "tag" interfering with anothers "look-at rotator." The whole system must be self-contained with no tag signals floating about.

Mathematically you'd do this using SOH-CAH-TOA, but seeing as how LBP3 doesn't like math too much, I'd rather not spend the next couple of weeks finding a way to make it work.

So... any suggestions?

Alright, well... seeing as how this thread is a bit... desolate, I actually found the solution I wanted!
And it's from a feature I didn't understand until only 2 days ago: the "angle-ify" option in the "direction combiner" tool.

Say you have an object spinning at a constant speed, and that object has an angle sensor on it. That "angle sensor" outputs an interesting signal, that as far as functions are concerned, is just "x":

ƒ(x) = x

If you plug that "angle sensor's" output into both a "sin(x)" chip and a "cos(x)" chip, you get perfect sine/cosine waves as their outputs:

ƒ(x) = sin(x)
ƒ(x) = cos(x)

What the angle-ify tweak in the "direction combiner" can do is collapse both wave functions back into the original "angle sensor's" output.
Or in other words, it can perform the arcsin(x) and arccos(x) funtions (undoes Sine and Cosine).
I don'e quite know how it does this, but who am I to complain?
Anyway, I need this function to fulfill the whole SOH-CAH-TOA dealio:

ƒ(x) = arcsin(sin(x)) = x
ƒ(x) = arccos(cos(x)) = x

So... that's neat. I may be able to completely rid myself of those Pythag triangles I had in my Axis-3D demonstration. The only piece of that puzzle remaining is division:

Ø = arcsin( opp/hyp )
Ø = arccos( adj/hyp )

But that shouldn't be too troublesome. The issue with division in LBP3 is that if the numerator is greater than the denominator, the output will be greater than 100%.
But in this particular case, the hypotenuse is always greater than either the opposite or adjacent legs, and seeing as how it's always the hypotenuse in the denominator, I should be in the clear.

When I visited school I had my doubts about the use of the things that I had to learn, especially concerning mathematics. This is a proof that I've been wrong! :) I take my heaad off to you! :)
Thanks a nd many greetings, Jürgen^^

Quote:

---

Originally Posted by CuriousSack

When I visited school I had my doubts about the use of the things that I had to learn, especially concerning mathematics. This is a proof that I've been wrong! :) I take my heaad off to you! :)
Thanks a nd many greetings, Jürgen^^

---

There are infact lot's of cool things to learn that can serve impulsive creativity. Math is just one thing, but it is spread pretty broadly amongst fields. Coding is another big one, but I'm yet to learn much of that... maybe one day.

Anyways, I found that the exact function of the angle-ify option in the direction combiner is:

ƒ(a,b) = (arctan(a/b))/π ; a = top input, b = bottom input

In terms of x:

ƒ(x) = arctan(x) ; x = a/b :

http://www.rapidtables.com/math/trig...ctan-graph.png

So... that's exactly what I needed:

http://i1383.photobucket.com/albums/...psawwamg6c.jpg

Really neat! I have no idea if anyone else knew what the angle-ify option does. If someone did, they didn't do a very good job getting the word out.

On a side note, now that I know what the option does, it can actually be quite useful to even everyday creators. I might touch on it's potential another time... if ever.

This would be really great to see, how to use this function in the everyday's creating process! :) This is crying for a tutorial! :)

I think you know more coding than you think if you play LBP for the logic. At least you'd be able to pick up assembly pretty quickly.

Quote:

---

Originally Posted by Bonnell7

Really neat! I have no idea if anyone else knew what the angle-ify option does. If someone did, they didn't do a very good job getting the word out.

On a side note, now that I know what the option does, it can actually be quite useful to even everyday creators. I might touch on it's potential another time... if ever.

---

didn't realise this is the outcome you were after, all the math words through me off lol
been using angle-ify to translate analogue stick position to an angle for use with sackthing rotation and decoration disc rotation since it was first added to the game, but i agree it could have been better explained, quite handy once you know what it can do.

i also use it to rotate analogue stick controls based on an angle. i'm angle-ifying stick outputs, offsetting that angle with another angle, then splitting it back out to 2 signals, then scale both down based on the strength of the original signals