# How to set Globe Anchor Pitch/Roll/Yaw (heading). Blueprint or C++

I am trying to orient things in the cesium world space through the use of the Globe anchor. Previous to this I had been setting rotations direction to the actor. This was folly as if you get far from the ellipsoid center, those rotations do not match what one might expect on a spherical earth model.

So I am attempting to wrap my head around how to do this. I have incoming data, among which is an aircraft’s attitude.

This exists on the editor when placing an actor with a GlobeAnchor:

So I thought, cool, maybe such a function exists in Blueprint or C++. Well not as such. There is SetEastSouthUpRotation but it wants a quaternion.

I’m an older computer scientist and we really didn’t get into things like quaternions beyond they are a thing. Haven’t had to deal with it ever since 1990s. All that to say, I am weak in thinking in quaternions and matrices.

Anyway, is there some guidance on how to get from pitch, roll, yaw into one of these eastsouthup rotations? I tried clicking the function in the editor which then attempted to open a source file I do not have.

My latest attempts look like this:

Doesn’t seem to do anything. I’d expect to be upside down.

It is entirely possible I am approaching this problem from completely the wrong direction, too.

I looked at the flight tracker tutorial but it leaves the attitude adjustments as, in the words of Knuth, an exercise for the reader.

EDIT: The line to the target on set east south up rotation is also from the same instance of WorldAnchor. I just wedged this stuff in above what I had already.

Hi @BDelacroix,

It looks like Make from Euler does this in the source code: `UE::Math::TRotator<T>(Euler.Y, Euler.Z, Euler.X)`

Which translates to this constructor, `TRotator( T InPitch, T InYaw, T InRoll )`. So I just want to verify that you wanted the roll to be that value. Does changing the other values make a difference?

The math looks right so I’m not sure what the problem could be. I can experiment with it on my side and get back to you.

Thanks. Those numbers I just put in there to see anything happen at all.
I’m going to make this my focus on wednesday when I can look at it again. I wonder if a pitch of 180 does weird things. I first started with 45 but that did nothing, too.

I’m going to also look to see if anything downstream is messing with rotations.

Update:
I have modified my attempts to finally meet success. I feel this is still wasteful as I am snaping to east south up and then reapplying my attitude rotations, but it works. I did have something downstream that was messing with rotations in my earlier picture. The C++ function for collecting data was messing around with rotations.

Anyway, cut that out and just send everything to the one spawn function to rule them all:
Here is the pertinent part.

Short description:
move the actor to the position desired by lat,lon,h.
snap the actor to southeastup
Make a quaternion rotation from euler values.
Get the new southeastuprotation (this will be “straight and level”)
Add the converted euler rotation to the new southeastup (by add we mean multiply because that’s how you add quaternions)
Stuff that new rotation into the component’s seteastsouthuprotation().

I’m fairly sure there is a way to maybe determine a difference in angles rather than normalize everything to straight and level and then apply the full rotation, but I don’t know what that is right now.

Doing this in C++ would be much the same as the function names are the same or very similar to the blueprint node names.

Hi @BDelacroix,

Thanks for sharing an update! Just wondering, does toggling the globe anchor’s Adjust Orientation For Globe When Moving setting make a difference? When this is true, the globe anchor automatically accounts for the new up-vector as its object moves, so I wonder if this affects the rotation that you’re trying to apply.

Ah yes. That works for things I am controlling directly with UE. The thing about these objects I am talking about is they are spawned in from outside data (our own control software) through a json file.
Early on I had an airplane under direct control with UE and flew from florida to new mexico to be sure that it constantly adjusted “up” for me which it did.

Now that said, we do this a bit weird. Basically we are teleporting our objects around every 0.1 seconds. So they have no velocity and constantly get a “move to lat lon” command followed by the attitude telemetry of pitch, roll and heading. I mean it looks like the objects are flying, but you can see the slow data rate. As the jets would be changing pitch roll and yaw I needed to adjust that pitch, roll and yaw in relation to the “up” that the globe anchor does for us. This was especially visible when spawning things in far from the chosen ellipsoid center. You get the sideways view (or upside down if in Tibet).

Anyway, short answer. Adjust orientation when moving works fine. We just aren’t “moving” using the system. Unless I misunderstand when the adjustment gets to see movement.

Hi @BDelacroix, thanks for your patience.

The Adjust Orientation For Globe When Moving setting should account for the magnitude of the movement, I’d believe. In other words, it’s not required to be incremental or smooth movement. So using `MoveToEarthCenteredEarthFixedPosition`, even with a far-away location should apply an adjustment rotation, based on the change in surface normal.

The snapping to East-South-Up seems redundant, that’s why I’m still puzzled about this. I can’t tell what was going wrong in your original post. Were you applying rotation after movement? I may open a Github issue for this just to look deeper and confirm this is an arithmetic problem.

I am setting orientation after the move.
The order of operations is I take the incoming position and move to lat/lon then I apply the euler rotation for pitch, roll and heading (which is yaw - 90 degrees).
If I remember tomorrow, I can get a bigger picture of the spawn function.

Hope this works. The update function is a bit big to take a tiny screen shot of so I used this blueprint share site.

Hey @BDelacroix,

I know it’s been a while since I responded to this—is this still an issue for you? (Needing to use East South Up to get the correct orientation, I mean.)

I haven’t had a chance to really test this until now, but your script looks good to me. I’ve recreated it in a sample level, and I’m just using the glTF duck model placed around the world + a `CesiumGlobeAnchor`. I’m keeping the CesiumGeoreference fixed in San Francisco and am moving it across the United States, and even to Australia. Wherever I move it, the orientation still looks correct to me, regardless of whether I use the Snap to East South Up node. So I’m not sure where the error is being introduced.

Do you have a specific example of incorrect rotation? For example, a location + rotation, expected vs. actual? Any numbers and screenshots would help.

Once I had it working I didn’t really look back at it. I’ll try to remember to experiment more to see what can be paired down.
When you say move, you mean moving with the engine once spawned? I had no trouble with a local control move of objects once spawned. They stayed oriented as advertised.
This issue only occurs on initial spawning.

For instance. I’d spawn an interest point (its just a camera with an icon that shows on the view screen). My center point is in northwest florida. I spawn this interest point camera in central illinois and it does appear the correct place, but the camera is a bit sideways due to the earth curve.

The stuff I did in the screen shot is what finally had that not happening anymore.

Now, in general, the aircraft we are tracking are fed from an outside source and I get gps position and euler angles for attitude. So my thinking was as follows:

Spawn the object (0,0,0), move it to the gps coordinates through the world anchor. Then rotate to the given euler angles. Except I have to make those into a quaternion. I don’t want that angle added to current, I want it as an absolute set of angles.
So I straighten the object out to the normal, then apply the full rotation.

We are doing something a bit weird in that I am just teleporting the objects around rather than letting UE move them using physics or just adding to the object’s directional vectors. As such, I’m not really “moving” the objects. That might just be a matter of semantics, though. It causes some challenges but it is what we have to work with.

I’ll see what I can scrounge up if you want to pursue this. For all I know, I’ll cut out some of it and it will “magically” start working.

If I am understanding correctly, you are suggesting that the snap to east up is not needed?

Ok so this morning I removed the snap to east south up and because of that the get east south up rotation along with the multiply and it appears to be working as intended even now.

I can only guess then that the c++ portion I removed around the same time that was downstream from this was further messing with orientation of the objects.

I like simpler anyway. Going to leave it like this for a while to be certain. Thank you.

1 Like

Hi @BDelacroix, sorry that I missed your earlier posts.

Yes, I meant to suggest that the Snap To East South Up was not needed, as long as the Adjust Orientation For Globe When Moving flag is true on the CesiumGlobeAnchor. This setting should apply even if the “movement” is not smooth, e.g., if you teleport from one side of the globe to another.

I was concerned that, because you had to use the Snap To East South Up Blueprint, that you had encountered a bug with CesiumGlobeAnchor. But, I’m glad you were able to get it working! Thank you for sharing your process + updates with your success!

1 Like

Is there any way like I am getting Location and attitude(Yaw, Roll, Pitch) Data from external software for many aircraft then this solution works and if I have to do without any change in global Anchor ??

Hi @ronak-tank,

You should be able to retrieve the yaw / roll / pitch data from an external source, and plug it into the Cesium Globe Anchor for the correct orientation. I’m not sure why you want to do this without changing the globe anchor – could you explain?

@janine My Questions are

1. Can We Define or attach Cesium Globe Anchor in C++ Pawn class if yes then how ?
2. Data which are coming from external world Pitch, Yaw, Roll so if we just do like in this blueprint [External World Rotation in Globe Anchor posted by milansoliya | blueprintUE | PasteBin For Unreal Engine] it will work??, currently it is not working for me?
(External World Rotation in Globe Anchor posted by milansoliya | blueprintUE | PasteBin For Unreal Engine)

Hello.
Using an external source of position and attitude data is exactly what I had been doing. That project was unexpectedly put on “hold” but I’m still trying to convince the bosses to un hold it. Especially since its been getting good feedback from users who viewed the demo. That’s out of my hands, though.

Anyway, yes you can do this, but not sure why you’d want to set the aircraft attitude outside of the global anchor. The anchor adjusts for you so that “up” is up no matter where you are around the world else you have to do that yourself and its not trivial.

You can attach a cesium globe anchor in c++. I did exactly that to begin with. The project evolved, though to where I didn’t need it in c++ anymore. I’ll keep looking but unfortunately I don’t have that source available anymore.
It involved the proper include and attaching in the constructor. Sorry I have been away from the UE stuff for long enough to have forgotten the details of that.

As to the external data part. Here is my blueprint function that works with external data. The geoparm structure is just a convenient struct to hold the position and rotational data. In my case, our simulator gives us the absolute angles of pitch, roll and yaw so I don’t have to figure out any differentials.

My project is using json files pumped in from a middle ware between our simulator and the UE project and the json processor fills the parm struct. The important part is, it contains lat, lon, height, pitch, roll, yaw. I do have to turn yaw into heading. All of that is on the right end of the blueprint function starting at Get Attitude Rotator.

Get Attitude Rotator is just a convenience function that pulls the pitch, roll, yaw out of the struct and gives it back to me as an UE rotator.

1 Like

For your external attitude data, make sure you’re accurately converting Euler angles to quaternions before applying them to the `SetEastSouthUpRotation`. The conversion needs to be precise to align correctly with the globe anchor’s orientation. If the data still doesn’t seem to work, try simplifying the problem by testing with static values or using debug prints to track the transformation process. This might help isolate where things are going awry.