We’re building a Space Sim and were hoping to present a real sense of scale but are quickly running in to a set of limitations that normal optimizations don’t seem to address for a large scale environment, with a very large draw distance.
i.e. For an FPS, I could reduce the draw distance, add in Fog, buildings that would hide things and help Occlusion Culling etc. However in a space sim, if I use fog and have a short draw distance then very large items such as planets start to just pop in - so you would see a skybox with a nebular and then suddenly not see the nebular and instead see a planet.
What are some of the techniques that I should look in to?
have a camera for the stuff near the player and another camera for the stuff farther away. then “scale” the objects to match the visual size for players distance.
you could also render the planets into a texture and alsways use them as impostors.
what optimizations do you already have?
in general this is a huge undertaking and since space is almost empty why bother the player with this “boringness”?. games should be fun und thus remove the unfun parts of reality. and if you present the player an unrealistic game (ftl travel, unlimited energy, gravity on ships) why must the space be realistic?
The issue with using a second camera for the player, is that I still want those objects to be traveled to. So we have a large asteroid, 100,000 units across and want the player to be able to land on it.
We’ve implemented a return to origin type system, so the universe moves around as the player fly’s.
I don’t have many optimizations in place; really looking for some ideas on how to make stuff become deactivated when out of view and keep the scene filling full of life at the same time.
You could just make a lot of smaller scenes/levels and use asynchronous additive loading, this would be a significant improvement to performance but it would also be difficult to setup. (Not really the loading part, but the unloading part would be)
Yep space games are all about faking everything. I would setup each element as its own mini scene with its own camera all combined for the player in the proper order (like how weapon cameras work in a FPS).
So you’d have a celestial objects scene with planets and such all fairly close together with their own camera. Work out the distances to a consistent ratio to Unity units something like 1AU = 1 Unity meter. As the player moves towards a planet the celestial object camera also moves towards the planet at whatever speed the player is moving / your ratio.
Since you’ll want to have an LOD system for something that big anyway when the player gets close enough to your celestial object hide it in its own celestial object camera and smoothly pop in your close up version in the player’s own camera so they can interact with it.
Faking it is especially the only option if you want to use any physics at all. Unity physics wig out completely at large scales plus you have the float precision problem.
the second camera is intended for those far away objects which spoil your far clipping plane. have the fcp maybe 10k units away and render everything beyond that with another camera which has ncp 10k and fcp 1 million or whatever. so you have precision for close objects which you can actually see (ships, asteroids) and imprecision at far away objects (planets, sun) does not matter as they are few and rarely overlap. when you approach an object nothing prevents you from putting it into near camera. for really landing on it you may require a solution like Planetary Terrain or Etherea.
i have never tried such a system but why bother with such large scales anyway? i would prefer a hierarchical approach. when stars are lightyears away from each other you don’t need the precision of meters between them as the player cheats the distance anyway by some form of jumpdrive or ftl travel. so you can savely have the distance between stars measured in lightyears and don’t care about imprecision in the km’s range.
same for the internals of a system. measure them in au. the player does not gain anything by displaying them a incredible large number of km’s presented.
so use a hierarchy of scales where you just interpret different positions in a different way depending on what it holds. this way you always have a local coordinate system embedded in higher level systems and you must not move everything as it doesnt matter.
Thanks, I hadn’t seen Etherea1 before. The scale on the demo looks really good.
I find the Floating Point issues can be noticeable about 6000 units from origin. So even for a small ship, if a player wants to fly in a single direction for 5 mins they can get the shaking effects introduced. In terms of large distance traveled - I agree with the FTL type approach. Would be rather boring if they needed to wait 3 weeks of real time to get some where
I’l have to have a look at that. Ideally I’m still toying with the you-can-land-on-the-planet idea. So I’ve been hesitant to introduce a second camera to handle these further objects.
I guess I was struggling with objects that are large but not huge. Like a space station or large destroyer. The object needs to be visible from about 3000 units but can still be visible from further away; so if I was to hide it at 3K it would look like it’s popping in or out of existence.
Maybe have a third camera that only renders massive close objects, so if you have a massive 3km big starship, and your camera viewpoint is very close and needs to see up to 3km, have a dedicated camera that has a very long distance far clipping plane, that can render the whole ship, and limit it to only objects on a specific layer. Move the close massive objects to that layer and voila.
You simply activate/deactivate the “real scale” objects based on a distance threshold.
At 100,000 units, the asteroid is a scaled down version, for example 1/1000, meaning that from a render perspective, it is only 100 units away, which is well within what far clip plane can handle.
When the player gets within lets say 10,000 units of the object, you start rendering the real scale object and stop rendering the scaled down object (and you can do that in a progressive way to smooth the visual transition). I would also recommend putting the scaled universe in a separate physics scene that you can use to perform spatial queries.
Guys, this thread is over TEN YEARS OLD. Don’t necro-post. There are many other threads about “large world” coordinate challenges which will have more timely ideas, discussions, issues and other contributions. Or start your own.
As above, please do not necropost on these forums. Please create your own thread to start-up your own discussions. Threads as old as these tend to have outdated information, especially when referring to API and features.
