There is a problem with the globe aware pawn where it only orients the camera to the surface of the earth, and it doesn’t orient the pawn itself. You can do a simple test of this where you create a floating pawn, then parent a cone to it so that the cone is pointing up. Then fly around the world and you will see the cone rotate. This introduces many unintended affects, but this is especially problematic in VR where the camera and the motion controllers for the hands need to be decoupled.
this is the same setup but I’ve only moved very far to the left (mouse wheel up, hold down ‘a’)
If you conduct this test yourself, you will also see that there is an additional problem where the mouse movement only moves the camera’s yaw and not the whole pawn’s yaw. This means that out of the box, in VR you have to move the mouse to line up the camera’s yaw with the pawn’s.
The floating pawn sets itself to an identity rotation wrt the Unreal coordinate space on BeginPlay and does not ever change it’s own rotation throughout play. This was seemingly necessary in order to utilize the controller while still maintaining the desired camera up direction around the globe. The controller + the current up-direction together directly drive the camera, as you noticed.
We ran into very messy issues when allowing the pawn itself to deviate from an identity rotation; somehow the controller’s rotational freedom would partially degenerate. If you have ideas for maintaining the globe-awareness of the floating pawn while simultaneously allowing for a coupled rotation between the pawn and the controller, feel free to experiment with the GlobeAwareDefaultPawn class (the C++ parent class of FloatingPawn).
Meanwhile, we have active plans to bring improvements to the default camera experience in Cesium for Unreal and we will be taking this issue as well as others into consideration!
@Nithin_Pranesh , it sounds like you are running into the same gimbal lock issues I’ve been butting my head up against I am all ears as to how you guys might consider solving it. It feels like (at least for what I’m trying to do) always maintaining a Y-down towards the center of the earth might be the most prudent solution, since that probably ties in best with what users are trying to do. Not maintaining a y-down means always having to calculate gravity relative to earth center as well, which can get messy.
I am not sure how best to make that work though, since it requires rotational rebasing which will throw off the sun-sky computations as well if not taken into account. I was considering building a player controller that, instead of moving “forward” or “sideways” in space, would sit in one spot and rotate the planet underneath instead. I haven’t given enough thought on what other problems this might create.
Basically I had no issue setting the orientation of the floating pawn itself, but somehow the pawn’s orientation (if it was non-zero) would mess up the controller’s orientation. This would in turn mess up the calculated camera orientation, which uses the controller’s orientation and converts it from local-space (supposed to represent East-North-Up) to Unreal world space. Is there no issue when you set the rotation in that blueprint and then attempt to look around while possessing the pawn?
I feel like this issue is particular to a bug in GlobeAwareDefaultPawn (by extension this affects the FloatingPawn as well). However, the Y-down vs Earth-down may still be an annoying discrepancy for many other situations as well.
Your idea of keeping the player still while moving the world is exactly along the lines of the design principles we used for our georeferencing system. I know you saw this answer @mahalobay but for anyone else that may stumble on this, here is a longer discussion with more background and links.
Your specific idea however should still be somewhat possible! Here are a rough set of steps that may need to be involved:
Keep your player within a relatively small region (say 100x100km). The georeference origin should be set to the center of this region.
When the player reaches the end of the region, set the georeference origin to be where the player is. The new region to check should be centered exactly on the georeference.
Remember to have all your objects including the player be properly georeferenced so that they “survive” the georeference change.
The CesiumSunSky will “survive” the change as well as long as it is georeferenced too.
Since the player will then always be within ~100km of the georeference origin, the up-direction should be very close to correct. If you keep the player completely still and constantly move the georeference, it will likely lead to significant lag, so I think this moving grid approach is much more feasible.
@Nithin_Pranesh using the blueprint I posted above, I am able to go to the opposite side of the globe from the origin and still have the camera’s up and pawn’s up vectors be correct, and I’m not seeing anything abnormal when I look around. Since I’m not seeing what you’re seeing, there are a couple of things that come to mind that could be solving it on my end. The first thing is that it may be because I’m doing things in VR. The headset could be correcting the camera’s orientation, since the headset hijacks the camera. But even if I move the mouse to look around, it still doesn’t give me any unexpected behaviors. Also, the way I’m moving around the earth is not using WASD. I’m using a modified version of Unreal’s VR mechanics, where I “throw” a sphere really far away and then teleport to that spot. That, plus I scale up the floating pawn 6000 times, so that I’m a giant on the earth. It’s possible that the movement component could be doing something. But even when I try WASD movement, it seems good enough. In any case, when I look around, I don’t notice any problems, but again, mine hasn’t been seriously stress tested, so maybe your tests are more thorough than mine. I will post here if I run into any new behavior.
I like your suggestion about changing the georeference origin, I didn’t think about trying that. This would work for the VR approach I’m taking because I could just update it every time they teleport. I’ll keep mine as is though (unless if something else comes up), since it’s working well enough for me.
I just realized something. I’m not righting the orientation of the pawn itself, I’m righting the orientation of the capsule, which is the bottom most component. I’m honestly not sure what the difference is between righting the pawn and righting it’s lowest component, because my cone test passes when you right the capsule but don’t right the pawn. This is a more likely reason why I’m not seeing what you’re seeing. Someone more knowledgeable about Unreal would have to explain what the difference is if there is one, and if there is a difference, why the cone test is passing.
Hi.
I am too new to Unreal Engine. I can’t test myself, what I am about to say.
I watched the Google Earth Globe, turned and flipped it a bit.
I did this on my smartphone, my PC and in VR.
To me, it feels like, they had like a small sphere, in the exact center of the globe’s sphere.
When you touch the screen, you actually touch the small sphere, rotating it, and with it, the globe’s sphere is rotating in fixed position to the small sphere.
If I had more coding skills, I would create a small sphere in the exact center of the globe, fixed to the screens center, and grouped/fixed? with the globe.
I would then connect the touch up, down, left, right, with the small sphere, but keep the zoom gesture and function the same.
This should give the smooth experience of the Google Earth globe.
Please feel free to add to the issue if there are specific mechanics that you would like to see with this feature, or if you have any other suggestions regarding it.
I am all ears as to how you guys might consider solving it. It feels like (at least for what I’m trying to do) always maintaining a Y-down towards the center of the earth might be the most prudent solution, since that probably ties in best with what users are trying to do. Not maintaining a y-down means always having to calculate gravity relative to earth center as well, which can get messy.