I am a big trek fan and I want to make a simulation where some of the planets and starships of the trek universe can be explored.
Creation of realistic looking planets generally involve loading large textures and even larger heightmaps and applying the heightmaps to a flat terrain. Its possible to do this for an engine written from scratch :
Since the heightmaps are very large they would need to be loaded in the background and applied to the user visible portion of the heightmap. So to what extent does the unreal engine support dynamic deformation of the terrain mesh at runtime from C++ ? I would also need to generate sphere meshes and sphere patches at runtime and bind textures to them, so is this supported ?
For starships especially the Galaxy class ships, the entire ship cannot be loaded all at once as its too big. I would probably need to dynamically load sections of the ship at runtime. Is this possible to do in unreal and what are these dynamically loadable sections called in unreal ?
You might want to check that out i’m sure it’d be pretty useful to you. Also for planets this could be replicated in a few different ways actually. I remember a very long time ago working with the OGRE3D Engine and an old friend had created a ‘rounded’ planet with proper camera controls. So yes, it is more then possible to create this with Unreal Engine 4.
So basically to answer your question; yeah that’s all more then possible. You might want to take a look at Space Engine here http://en.spaceengine.org/ and look at the problems that they have encountered. I can promise you one thing; a proper space game is going to take ALOT of memory to run.
Just a word of caution from someone who played around with stuff like this for a couple of years, like any complicated project the question is not whether or not it can be done. The question is how long will it take you to do it, which in turn of course is determined by the resources you have at your disposal (i.e. one or more people with experience working in advanced mathematics and programming).
It’s not uncommon to hear people talking about having spent more than a year working on normal game projects, and it’s not uncommon to hear people who’ve been working on full sized planet simulation in game engines talking about having spent five or more years working on their framework. So I’d say that’d be the question you’d want to ask yourself: sure you’d like to have a game with full sized planets in it (who wouldn’t?) but is it worth spending 5 (or probably more) years of your life working long hours around your existing job to achieve that?
The other thing to be aware of is that getting full sized planetary terrain is really just the first layer in a simulated environment. What about foliage? Will your planet be a bare moon? What about the next planet? Is your universe a universe of moons? Even with foliage implemented, do you have the same environmental theme (sometimes referred to as a biome) planet wide? What about the next planet? Is it just one forest planet after another? What about weather? Day night cycles etc etc. Let’s say you get all that sorted, what about cities? who wants to wander around uninhabited planets? What about crowds? What about roads? What about traffic? And hey, while we’re at it, what about gameplay?
Not trying to be harsh, just trying to give you a bit of a peek at what a deep deep deep rabbit hole it is when you start on a journey to learn how to make procedural planets
I suppose the last thing I should mention though is that even though I didn’t really get very far in my journey before I pulled back to more conventional aspirations, I gained enormous amounts of experience in working in low level 3D and procedural generation C++ stuff and had an absolute ball doing it! So by all means, go for it. Just be aware that it’ll almost certainly take much much much much much longer than you’re expecting here at the start