Direction actor is facing in relation to another actors direction?
Chunkypixels
Member Posts: 1,114
Hi...
Looking for a bit of help/suggestions from the math guys 
I need to work out the formula/logic for working out the direction an enemy actor is facing, in relation to the direction the player actor is facing. (diagram attached)
In the diagram, theres 3 examples. Ive shown the rough directions everything is facing, and the rough direction that the enemy is located at compared to the player.
Ive added what I think (rough visual estimate) the direction the enemy is facing in relation to the direction the player is facing in the light grey text, based on the premise that if the player is looking directly at the enemy, and the enemy is facing/moving (towards the player 270), (away 90), (to the Left 180), (to Right 0).
Im using the data from the actors on an overhead map to generate the positions and rotations of actors in a mock 3D viewport, so need to work it out so I can get the actors in the viewport to generate the correct image for the objects rotation.
So Im trying to work out the math/formula/logic to give me the Figure in grey.... if any of that makes sense
Any help/suggestions would be appreciated... cheers
Comments
If you have two arbitrary angles, you aren't going to be able to come up with an equation to satisfy all possible values. But taking a specific example, such as Player:115, Enemy:340, you would figure out the relative direction by taking the player's facing direction and subtracting to get to 0/360 and then subtracting to get to 340. So the enemy's facing direction would be 115-115-20. But I doubt that hopes much... so maybe I misunderstood? Are you looking for a vector angle that averages their facing directions?
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
@tatiang ...I have vehicles moving around on an overhead map, that can be moving in any direction in relation to each other. Im rendering out a mock 3D viewport, based on whats in the area in front of the player (green) vehicle... marked out by the green lines.
I know when an enemy is within a certain distance, what direction it is from the player, and what direction it is moving in, related to the overhead scene. I need to work out the direction the enemy is facing, once it enters into the angle of the viewport, so that I can update the graphics in the 3D viewport to show the image of the vehicle in its correct rotation.
My math aint great... especially at 5am... so looking for suggestions for me to try out later in the day once I've had some sleep
Maybe I could do with some more diagrams to help explain what I'm trying to achieve?
Red - Green + 90 gives you close to what you want.
180
315
65
but that's probably not right since it doesn't include enemies relative position.
but then i tried
((Red - Blue) - (Green - Blue) + 90) % 360
which also gives 180, 315, 65 with angle of player to enemy included in equation but it cancels out since - Blue -- Blue is the same as - Blue + Blue which
so yeah
Red - Green + 90 is what i am settled on.
This will only give you angle of how to draw enemy, you probably have other rules to determine to draw enemy or not right?
@tintran ...could it be that simple? Does seem to work in the examples given
I'll have to give it some testing later...
I think it is that simple
because if your hero was looking at 0 angle, and the enemy is looking at 0, you want to draw his butt so you want 90 degrees to be the answer. That's why that 90 is added on there.
Then the rest is just figuring out the difference between where enemy is facing and where you're facing.
or you could try (Red - Blue + 90) % 360
This is made a little more confusing by the fact that both the enemy and the player have differing reference points for 0°, if they both had the same reference point then they'd both be facing the same direction when at the same angle, but as described when the player is looking directly at the enemy, and the enemy is facing to right, the enemy is at 0° - so the enemy is offset from the players rotational reference point by -90°.
But anyhow, (red+90)-green will give you the correct angle for the enemy's rotation (red), you then need to subtract the vectorToAngle between the two to account for the (pseudo) rotation as the enemy moves left and right across the players view. Hope that makes sense !
I am pretty sure it's (Red - Blue + 90) % 360.
As you can see from diagrams below,
The top 3 diagrams show your hero rotating, but enemy is facing 90(Red). The blue (angle to enemy) is 0 in all 3. 90-0+90 = 180 in all 3 which is correct since you should see the left side of enemy in all 3 cases.
The bottom 3 diagrams shows your hero rotating, but enemy is facing 90(Red). The blue (angle to enemy) is 90. 90-90+90 = 90 in all 3 which is correct since you should see the back side of enemy in all 3 cases.
@Socks is right, after you subtract the vectorToAngle between the two to account for the (pseudo) rotation as the enemy moves left and right across the players view, the Green cancels out...and you're left with Red - Blue + 90
Thanks for the input guys... You've given me a good basis to play and experiment with. @Socks is right, that it needs the additional vectortoangle to adjust for the point of view as the enemy moves across the field of view, but really appreciate your input and additional diagrams @tintran.
And yup... I think I over complicated things with having the enemy rotation starting with the 90 degree offset, rather than just have it start with the same offset as the player. This was down to how I'd rendered out the views of the tanks... But really, looking at it now, I can re-order the sequence to make it less confusing.
The value of good input, and a good sleep to help see things a little clearer
Thanks again guys.
With additional vectortoangle to adjust for the point of view as the enemy moves across the field of view
I had
Red - Green + 90 - (Blue - Green)
with -(Blue - Green) being the adjustment.
But then Green cancels because --Green is a +Green.
That's why i arrived at Red - Blue + 90
I made a quick visual calculator to help work this out . . .
You can move the arrows by clicking in the middle and dragging, you can rotate them by clicking on either end (the tip or the base) and rotating, the green arrow displays V2A and rotation, the red arrow shows rotation.
Nice one @Socks.
I took your demo and added the angle of (Red - Blue + 90)%360 and gives the purple number (what the player should be seeing of the red actor).
Also from this demo, I learned something new...getting access to other actors in the scene which i didn't know previously.
That's perfect !
Nice job, works really well. I suspect the actual angle of the actor (the V2A offset for the NME's position in the player's field of view) might have to be done by eye rather than mathematically, as the maths assumes a perfect, distortion free, fish eye angle of view, but I suspect that is just a case of dividing the V2A offset), so maybe when the NME is at the far edge of your field of view (left or right) it is not quite at 45° to the player (assuming an actual real world 0°), I suspect this might need to be toned down a little, you're effectively choosing your camera lens / F.O.V here.
Yeah, it can be very useful not having to go through attributes and just directly referencing an actor in the scene, it's also the only way to gain access to things like camera attributes during run time.
Yeah before learning this whenever i made an actor follow another actor i had to constrain x and y game attributes then constrain self.x and self.y of my follow dude to these game attributes..and it also introduced lag follow effect if you move the original actor really fast. you can see the follow dude trailing behind sometimes... I'd imagine getting direct access should not introduce lagging effect.
It's said to help somewhat . . . . but the thing that will really cause (and cure) lag is layer order, GS scans the layers (counterintuitively) from bottom to top, so if you have - for example 30 layers - and you have Actor A on layer 10 and Actor B on layer 9 (layer number going from 1 at the bottom to 30 at the top) - and Actor B needs to follow Actor A, then Actor A's location is read - but is not passed to Actor B until GS scans through layer 11, 12, 13, 14 . . . 28, 29, 30, 1, 2, 3 . . 7, 8 and finally back around to 9, at which point Actor B can get hold of Actor A's location data, the result of this is noticeable lag, the solution in this situation would simply be to move Actor A one layer below Actor B, so it can pass it's location data directly upwards to Actor B, making the communication between the two instant and snappy.
great to know for future references....
I just notice you went PRO @Socks yeh, we don't lose you. Congrats!
@Socks Whao! Socks Pro? What hath God wrought!