I’ve not tried, but having worked on a shipped AAA title with spherical planets before and having a basic idea of what’s involved, I think you’ll probably struggle to do this via Blueprint, and probably still struggle to do this in C++ with a unmodified version of the engine.
This is a little bit outside of my area of expertise (I’m more of a Gameplay guy than Engine/Graphics, so my knowledge in these other areas is a bit high-level and might not be 100% up to date with the state of the art), but I can say that to tackle a game like this my feeling is that the best way is probably to spend a significant amount of effort modifying the terrain system in native code to support spherical planets.
You might even need to rewrite the terrain system from scratch, depending on how feasible it looks to make the existing code support spherical planets… There’s generally a lot of technical investigation that goes on before making a massive change to an engine like this, to see where it’s better to reuse, and where it’s better to just ditch it and rewrite from scratch. Sometimes a system just has so many in-built assumptions about how it will be used, that it’d be quicker to start from scratch than to reuse what’s there.
Terrain is a much better fit for this kind of thing than a mesh, because terrain is designed for exactly this kind of thing, it’s split into chunks that are separately LODed, so that when you’re close to the terrain the area right around you is very high-detail, but the terrain in the distance is rendered and processed at a more coarse level of detail. Meshes are usually built on the assumption that it’s one object that’s either close to you and finely detailed, or far away from you and rendered at a more coarse level of detail.
Objects placed on the terrain (including buildings) would be their own separate Actors/Blueprints, and ideally you’d want to stream them in and out as you move through the world, otherwise you’re going to waste a ton of CPU time processing actors that are miles away from you, and filling up available memory with assets that don’t need to be loaded. Also if you try to put everything in one Blueprint, my gut feeling is that you’re likely to start bumping against various hard-limits in the Blueprint system (I don’t know of any limits specifically other than general performance issues, but generally speaking it’s something that happens when you try to use systems in ways they weren’t designed for. Are there hard limits on the number of nodes in a Blueprint graph for example?).
Material-wise, my knowledge is probably a bit behind the state of the art as I don’t really deal with graphics/art assets much, but my understanding is that generally most games will use a single material for the terrain and blend between different textures based on things like terrain height and slope, to achieve different terrain types.
Another big problem you’d likely encounter with this kind of game, is that with a large world you’ll almost certainly start bumping up against the limits of floating point accuracy. Basically, the distance between consecutive floating point numbers gets larger and larger, as the value gets larger. This can manifest in all kinds of problems (both gameplay and visual) as you get further and further away from (0, 0, 0) in your coordinate system. A lot of games with massive worlds like this, make changes to their engine to support custom coordinate systems to get around this.
Personally, I’d be tempted to try and fake a lot of this. If your game supports being in space, and being on a planet then you could potentially have the planets just be less detailed meshes while in space. When you enter the atmosphere, you could have some kind of transition sequence where you fog up the screen as you fly through the cloud layer, and use that to hide the fact that you’re streaming in another level with flat terrain. You’d have to pull off some trickery if you want the world to be circumnavigable though (especially considering that teleporting from one end of the terrain to the other will likely incur a significant time to load in all assets to a high level of detail)
