Any possibility to create a big open world in Unity (50 km diameter)?

Any possibility to create a big open world in Unity (50 km diameter)? Currently eith the distance from the center more than 5 kn objects start trembling

 

You can make a world as large as you want. The issue is that the floats in the vector3's used for an object's position lose accuracy the larger they get, as they start dropping decimal places. Then it all depends on what size the objects are that you're looking at, as the smaller something is the more the jitter becomes apparent.

There's some alternative techniques for doing large worlds still though, such as moving the whole world periodically so the player's camera is still close to 0,0,0.

 

Moving the whole world is possible for a relatively simple world (like Kerbal Space Program).

We have a complivated world with many objects and complicated layers. Will be very expensive from computation point of view. Need to find another solution.

If a solution out of box does not exist - perhaps any ideas how to "upgrade" Unity

 

The only possible solution in Unity right now is moving the whole world periodically so the player's position is close to 0,0,0. There are no known plans for upgrading Unity in this aspect.

If most objects are children of a few root objects, then modifying the transform for those root objects would be enough. This would translate everything, even the children rigidbodies.

 

I've not worked on such system yet, but I assumed this would cause all sorts of problems. Here are a few issues that come to my mind:

• Physics of simulated RigidBodies with useGravity=true
• TrailRenderer
• Moving baked collision?
• Moving static MeshRenderers?
  
• ParticleSystem with world-space simulation
• What about Renderer motion vectors?
• All sorts of entities that move in space from point A to B, suddenly have a different target position. NavMeshAgent?
  
• Performance issues when moving thousands of objects?

Have you implement such system already? What kind of issues can one expect?

 

Look at World Streamer in the Asset Store -- it's designed for this.

 

I also recall a thread conversation (they are usually fun to read) between @neginfinity and @Arowx on this subject. I think @neginfinity posted sample code of a space flight or so.

 

If this is so then how the games like Osiris: New dawn have been done? Big complicated open world - and Unity

 

I have never done this but as @Edy suggested a few root objects, that you parent your world objects to should do the trick. Basically once the camera exceeds a boundary, you reset it and then switch the parent objects so it remains seamless?

 

Surely they do shift the origin periodically. No magic involved, there's nothing else we can do about the floating point precision limits. Most probably they have some component attached to their Transforms for keeping the position in double precision. This way the precise position wouldn't get lost in objects that are currently far from the origin.

If you have all your scene hierarchy as children of a single root object, then it moving the root object would be enough for shifting the origin.

 

Although origin shifting will work for your main (central) character, physically based distant objects will still suffer with precision issues, sadly. Here's how KSP solves these types of issues;

Also, for periodically shifting Rigidbodies you probably want to use the rigidbody.position property instead. See Rigidbody.position

 

Perhaps not the best queston to ask in this forum - still, do you think that UE suits the task better, as streaming/multitasking/etc. is much better with UE?

 

I do the world shifting thing in one of my games like Edy said and it works great. There are something like 40-50 Unity terrains all set as children of one empty game object. I just move that terrain parent and the player vehicle parent object once the player has moved something like 1-4km (I forget the setting now, but it's in that ballpark). Colliders in my case weren't an issue.

The expensive part is moving particles which needs to be done individually for each particle. The terrains and everything else were nothing in comparison.

 

Because it's simply not as expensive as you seem to believe it is. For starters, you don't move the entire world every single frame. You move it when the player character has reached a certain distance from the origin point.

Unreal engine uses origin shifting. If you want to avoid that you need to choose an engine that uses 64-bit floating points under the hood. Just keep in mind that most processors and graphics cards are slower with 64-bit math. CPUs only take twice as long to process them, but GPUs currently take 32 times longer.

Additionally you'll have to code your own physics solution because PhysX is restricted to 32-bit math.

 

There's a lot of ways to handle this. If the game is singleplayer, it is much easier.

I have a link in my signature for open world resources. It is a bit sparse, but I welcome others to contribute so we can build upon it.

I am too busy to really help or invest any time explaining how it can be done or how it should be done.

For the most part if you want a seamless world, you'll want to stream it in & out as the player moves.

Just off the top of my head...for distance viewing, you can have each gameobject or object type with a tag/enum, and enable based on distance.

So a player would have two or more proximity detectors. One for far LOD objects and one for closer stuff.

Load terrain & big objects with far LOD using the farther proximity detector. Load the remaining objects when closer or update LOD. (I am not knowledgable of 3D graphics, but that is the jist).

You'd likely want to keep the player at 0,0,0 and move the world instead of the player - Futurama Ship style.

But I realize none of that is very helpful since you need all the details & a programmer paid to do the work. Sorry I cant be of more help.

Anyway, check out my signature. The asset store is always great sometimes, so check the reviews of world streamers there as a cheaper alternative. I cant refer you to them tho.

I created my own open world game but it was multiplayer and I ended up tossing out streaming in exchange for smaller levels (but they are still loaded/unloaded, as up to 4 large locations can br active at once. So it streams enormous chunks at a time, but isnt performant since it doesnt need to be and clients have prediction.) So the easiest way for me was to change the design to make the world smaller, in big chunks, but still streamable / huge.

So sometimes cutting the scope or instancing content with good design patching the holes can turn out great, like it did for me.

Like I said though there are so many ways you could handle this stuff.

You'll likely want to use alot of asynchronous loading of assets, asset bundles, and/or caching.