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.
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.
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.
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.
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.
