Hi guys, thanks for the release! It is most awesome and I had a stupendous time “flying” from Denver to LA the other night
I’m running into a global issue and wanted to ask and see if future releases would address these issues or if I should roll my own code to address this.
So it looks like everything is keyed off of the Georeference origin - the tiles then get generated from this origin and therefore, gravity and sunsky work correctly. This is fine and dandy until I try to travel from, say, LA to London. If my georeference origin is LA, London is now literally on the edge of the planet and I can’t actually land on it - I fall off the side of the world, as it were.
I can think of a couple of solutions for this - one would be to consistently ping direction to the center of the planet and get a moving latlong that I can then lerp in order to keep the planet under me at all times. It would sort of be the rotational equivalent of ‘Keep World Origin Near Camera’, in a way… a ‘Keep Planet Under Me Always’ checkbox.
Would you guys think you would be implementing something like this in future builds?
Thanks for using our plugin! Our georeferencing system currently supports something very similar to your idea. Read from here to the end of our Placing Objects tutorial. We describe exactly the issue you are facing and explain some options we have provided to help you work around them. The follow up tutorial on georeferenced sublevels will allow you to build in multiple distant places like LA and Denver. When entering each of these sublevels the georeference origin is automatically set to the new location so that the world Y points to up with respect to the globe.
As described in the tutorials, objects can either be put in the sublevels or the global persistent level. Anything in the global level must be georeferenced with a CesiumGeoreferenceComponent. The reason is that, when entering a sublevel, the entire globe will shift to align to the new georeference origin and only properly “georeferenced” objects will follow that shift. Otherwise, as shown in the pictures here, the actor will appear somewhere completely different after the georeference origin is changed.
In your case, you may wish to have airports in LA and Denver as two separate georeferenced sublevels, each with a large number of Unreal assets and even physics with the proper gravity direction in each. In the global level, you may wish to have an airplane actor with a CesiumGeoreferenceComponent added to it. Now you should be able to fly from one airport to the other and have everything work well in both locations! If further adjustments to the georeference origin are necessary on the way in between sublevels, it should be possible to directly set the origin location to your current location through blueprint on the CesiumGeoreference actor.
Just a reiterated warning of course, that you should only change the georeference origin if all actors in the global level are georeferenced.
Is there a support page somewhere that details all the available functions and cesium-specific blueprint nodes that I can reference? I’ve gone through the quickstart and looked through the floating pawn and I’m trying to start putting together some submodules to make my pawn geo-aware. Specifically, at this moment, how i can convert from unreal xyz transform to lat-long-alt with regards to the referenced globe. I’ve been looking through the list of available commands on blueprints but it would be easier to maybe find and read some sort of reference page to determine exactly what i can use. Thanks!
I’m glad you found the functions you were looking for! We definitely should put up some documentation for the current API online, I will talk to the team about this. In the meanwhile, almost all of the useful functions exist in CesiumGeoreference, as you found already.
Wanted to let you know that your suggestion (in another thread I think) about reinitializing the origin worked! It’s currently janky and I can definitely see the planet shift as I reorientate, but that is probably because I’ve set the planet to reorient every 2 degrees of arc (which is a lot I guess). I will try smaller limits this week and see if I can smooth it out. What do you suppose the performance hit might be each time i modify the origin?
Happy to report though that I can take off from one location, fly around the planet and land halfway around the world!
Quick note - not sure if anyone has mentioned it, but from blueprints there is an option to set the (inaccurate) georeference origin value, but not an option to get it. I’m working around atm this by keeping a vector set variable on hand, but it might be good to be able to get the value eventually. Is this possibly because of the precision issue as well?
