Using sphere trace I need help finding a rotation

So I have a seemingly simple issue but my maths skills are blocking me. I want my AI Pawns to each have an identical sphere trace just to trace for each other. When they overlap one another I need to use the overlapping location point to find a new rotation/ vector to rotate to, so they don’t crash into each other. I need them to sort of ‘mirror away from each other’ in both pitch and yaw, because my ai are flying pawns that behave similarly to a plane or jet (constantly moving at high speed in the direction of their forward vectors while rotating to essentially turn). There will be times in which the ai are aiming for the same goal location, in which they currently end up colliding with eachother. I’ve added a rough image of the desired behaviour I need to replicate on both axis, although unlike the image the AIs wont always come at each other from the exact same angle.
like I said I’m not great at maths, so how can I find the ideal point for my AI to rotate towards from just knowing the sphere trace overlapping point? I think I need to work out both the pitch and the yaw since they are flying and are not constrained to the same point on any of the axis when they overlap, but I still want them to head forward towards their goals.
Any help is greatly appreciated and if someone knows the answer, could you possibly show me an image of the node setup because I really do suck at maths so just telling me the maths might go over my head a bit!

So if understand this correctly, you want them to change coarse if sharing the same destination brings them too close together?

I don’t think a trace can pick up another trace,(as far as I know) so you could instead place an additional collision sphere(set to overlap all) ahead of your pawns. Then off the begin overlap event cast to it self. (the same pawn class) Off the cast success take the forward vector of the other pawn and add it to the world location of the current pawn and multiply it by a reasonable number of units. This will produce a location you can use as a temporary destination. Have it travel to this destination in the behavior tree and return to its objective afterwards.

Make sense? Do I have the right idea?

There is a problem with this, if the temporary destination is in the ground, tree, building etc you will have to adjust for that forcing the z value of the temporary destination to be >= the current height of your pawn might help. or making the z value of the forward vector absolute would also help.

Let me try to be a bit clearer, I meant the sphere traces would each trace for other pawns themselves, since my sphere traces will be exactly the same size (and somewhat large) they would go off simultaneously for each pawn while being large enough that pawns themselves will still have some distance between them.
I’ve already made my pawn able to navigate the world and avoid simple static and moving obstacles when possible, they just don’t avoid each well because I’m unsure as to how to get the ideal vector point so they go away from each other. I want both pawns to both change their trajectory (the rotation is rinterp to make it look more natural). So everything is implemented, they just don’t know where to rotate towards when they encounter each other.

If Pawn A and B were near each other headed to the same goal, and Pawn B’s trajectory led into A’s sphere from below it on left-hand side, the desired effect would be for both pawns to be triggered, Pawn A adjusting to go Up and Left and Pawn B Down and right, until both were no longer triggering the trace. As this is a tick check, an rinterp movement and they theoretically should trigger exactly the same time, they should both successfully turn away from each other and maybe even eventually travel parallel to each other due to constantly controlling the trajectory to be just out of each others sphere trace every tick, right? But how do I calculate what direction either should try to go in from the sphere impact points vector information?

Also, they could come together from some very odd angles depending on the path they had to navigate to reach other so a sphere trace centred on the pawns themselves seemed ideal for covering the complete 360 range of possibilities.

A simple trick you could do is to swap their velocities.

It should look like they are turning away from each other, but may not work when you have a low angle of collision.

So a sphere trace(as far as I know) isn’t a radial(360) calculation, its just linear.(like line trace but with some volume) That’s why I was a bit confused about your application of a sphere trace.

The the thing you are describing is yet another collision sphere, just this would be on you pawn and it would have a radius of what ever distance you wanted to begin to perform these calculations.

As HarryHighDef mentioned fundamentally your diagram suggests you want to do something like swap velocities. I suggest you do that if this seems too complicated or unnecessary.

Instead of swapping velocities I suggested swapping forward vectors and creating a temporary destination as this would allow your AI to path properly, Instead of turning on a dime and flying into a wall, it can execute a natural turn and still avoid obstacles.

So you could use a capsule collision that’s bigger than your pawn and extends forward(similar in principal to what I described initially) and this will allow your pawns to detect potential collisions no matter what. If your pawns do in fact behave like a plane then they don’t strafe or fly back wards, so you really just need to know if their paths intersect. If you make the volume of detection too large they will detect potential collision when the potential isn’t actually there.

You can move them in directions away from where they see each other, or a direction that’s an average of moving away and moving forward.(this will make the pawn turn away at a less extreme angle)

Then just multiply one of those by the distance you want them to stray before returning. If you randomize this a bit it will help them stabilize if having relatively parallel paths makes them oscillate as the oscillations will develop an offset in phase. They don’t actually have to go to this destination they just have to try to for what ever period of time(should have some randomization) you deem fit. It might be the amount of time it takes it to travel 10-15 meters for example.

Okay I think I understand what your saying a bit better now, I will give this a try and see what happens.
Currently my pawns already have a forward trace (as well as 6 other directional traces) being done to avoid walls and know which directions are ‘clear’ to turn towards that will take precedence over detecting pawns (sometimes a crash is a crash and can’t be avoided so the rare occasional pawn collision is preferable to a collision with the ‘world’ or unnatural behaviours to avoid crashes). Adding a new trace that ONLY looks for Pawns shouldn’t effect their current navigation of the world thankfully so it’s something I should be able to add without issues.
Also I can’t use velocities as my pawns don’t actually have any real velocity right now (I don’t think), the movement is completely done via tick adding a delta X location to a local offset based off speed calculations (which is easier to me personally while still achieving an effect that looks very similar to real velocity).
If this works I’ll mark it solved, if not I’ll let you know what happened or if I’ve missed something.
Thanks for the help.

Yes they would both turn. I’m just confused about how the sphere trace would work. Things that are in the path of the trace wouldn’t necessarily be a collision threat, and most threats wouldn’t show up a forward trace until they were already collided.

I’m pretty sure if you subtract “pawn location” from “other pawn location” instead, you can remove the “*-1” but it works either way.

Yeah, it’d be cool if it made realistic decisions and did still crash some times.

That hasn’t seemed to work for me. From print strings displaying the vector, it seems for some reason all the ‘temporary destinations’ are around the level origin point rather then near to the actors (who are quite far from the origin point when they begin their collision).

Okay it seems to be working now but I’ll need to do more tests as it’s hard to debug ‘real’ situations and I kind of just have to let the AI roam free until a situation occurs lol. It seems like that did the trick though so hopefully it’s working fine. Thanks again for the help!

Maybe this will work? I’m sorry, I don’t have an AI pawn class set up so I’m relying on you to debug.

OOOOPS, think you have to add the actor location of your pawn to all of that my bad. I always forget to do this when use traces and other stuff that requires forward vectors. I’m sorry man.

This is why the vector is so close to 0.

I’m so dumb, literally just last night I was screwing with a trace that kept ending at the origin of the world and I couldn’t figure out why… Then again I make the same mistake today, sorry for wasting your time I hope it works now.

This is the whole thing corrected.

Ok, so I really wanted to know if this works, and it does.

Though it’s not perfect, so the distance traveled is proportional to the angle of approach. So when they crash head on the temporary destination is pretty much right on top of the pawn.

I have created a version which does the math 100% correctly. There’s a lot of weird looking stuff that does the proper trig, just copy it. In case anyone is wondering why I didn’t just use angles, the answer is because the average of two rotations is always between 0-180 so it always basically points in one general direction.(more accurately they will tend toward one half of the world unless I set up a branch that checks all 3 angles for values over 180 than inverts them)

I tested it by setting up line traces to show you:
-where it was going
-where it would go if it went immediately away
-where it will go with this calculation