3d Skybox System (+huge world float imprecision workaround) FILES

I've been playing around with a 3d skybox setup lately. I haven't polished out all the rough edges yet but I wanted to share what I've got so far to let people have a play and give any feedback and suggestions.

One limitation with Unity is that it doesn't handle extremely far distances very well. Just from a rendering perspective - shadows fade out very early, and then the camera clipping plane itself cuts off very far geometry. But not only that, if you ever want the player to travel to very far off areas, floating point imprecision becomes a problem. You'll notice that if you take a character very very far away from the origin,  the vertices don't behave themselves very well, physics starts acting up and the world generally breaks down.

A fix for the rendering side of things is using synchronised scaled cameras that are composited together, one for the close up gameplay view, and one or more for the background (and super far background if you want to do realistically scaled planets for example). Now I don't mean the camera's transform is scaled, but rather that it's movement is scaled relative to the camera that it is matching.

The second 'background' camera is usually looking at a miniature version of the background, far distance terrain, or a 3d skybox (actual geometry of the far distant terrain, just much smaller) - this can be hidden from the main camera via layer render culling. This 'background' camera renders the background behind the main camera, and it matches the movement of the main camera, especially the rotation. But when it comes to translation, the movement is scaled relative to the scale difference that you're trying to imply. If the main camera moves forward 1 unit, the 'background' camera might only move forward 0.001 unit, if it's scale Factor was 0.001 for example. This gives a very convincing illusion that the miniature background is actually full sized.

(See the shadow of the planet on those planetary rings? 3d skybox magic!)

You can have a look at the included example scene for a way to set up the cameras, but a quick rundown is as follows:

The system I've setup so far allows you to use as many layered cameras as you want, and you synchronise them with the "ScaledReferenceEntity" script. Each camera has to have a parent object which is the coordinate frame of reference for that scaled layer. Each parent object must have a "ScaledCoordinateReferenceFrame" script on it. That is where you set the Scale Factor to determine how everything will synchronise.

So a basic setup might be. Create an empty parent gameobject, put a  ScaledCoordinateReferenceFrame component on it, and leave the ScaleFactor at 1. This is the normally scaled gameplay reference frame. All your normal gameplay gameobjects will be children of this object, including your player and camera.

Then, somewhere else in the scene, create another empty gameobject, with another  ScaledCoordinateReferenceFrame component on it, and this time set the ScaleFactor to some small amount. Try different numbers and see what looks right for you. This will be your background frame of reference. You'll also want to create a camera as a child of this background object.

On both cameras, the main one and the background one, add ScaledReferenceEntity components. They should automatically find their Parent Reference Frame (the parent object with the  ScaledCoordinateReferenceFrame component on it), but if not, simply drag and drop those in.

Then on any of the cameras, drag and drop the other camera into the LinkedReferenceEntities List. And then afterwards hit the "SETUP Share Linked Entity" button. This will synchronise the two transforms on the two cameras, so that they move relative to their Parent Reference Frame ScaleFactor.

Finally, you'll want to set the Depth on the main camera to be higher than the depth on the background camera, and set the main cameras Clear Flags to "Depth Only". You can also set the Culling Mask to only show layers of the geometry that is appropriate for that camera - so for example, background miniature terrain can live on a layer that only the background camera can see.

Now make sure you tick "Update Continuously" on the script, and now whenever you move one of the cameras, the other camera will move according, even when you're not in play mode. Only one of the cameras can be the "Master" at any one time, and the script will detect which one is currently selected and make that the master, but if you're in Play Mode, you'll have to set the Master manually by calling SetAsUpdateMaster() on the ScaledReferenceEntity script. Usually you'll just want to leave the main camera as the Master, but if you want to do a super fast flying movement to another planet you might want to set the background camera as the Master for the duration of that movement.

You can also use this component to synchronise other objects, not just cameras. For example, you might have a large explorable Spaceship level in your main play space, but also have a miniature (low LoD) version of the Spaceship for you backgound camera, when you're far away from it. Pop the ScaledReferenceEntity script on both versions, and sync them up by adding one of them to the LinkedReferenceEntities List and then pressing "SETUP Share Linked Entity". With Update Continuously checked, the two spaceships will be synchronised, so if you approach the background one, as you get closer and the proper ship enters the main cameras clipping plane, it will be in exactly the right place. You can also leave Update Continuously off, and just hit the "Update Linked Entities" button once to position them in the right place - remember, whichever one is the Master (which ever one is currently selected) will force it's position on the *other* ones. Rotate and Position (scaled via ScaleFactor) are automatically synched, but you can also check the "Update Scale" toggle to also make these match, relative to the delta of the two ScaleFactor values.

So, that's how we get around Unity's very limited shadow and geometry draw distances.

(Here I've added a dither dissolve to the Terrain and Water Shader to blend better when it approaches the clipping plane of the main camera - this could also be done better as a post processing effect to composite the cameras together)

FINALLY, the other problem I mentioned was Float Imprecision. To get around this, we need to regularly recenter the player and main camera back to the origin. The Scaled Coordinate Reference Frame script has this built in as an optional feature. Simply tick "Recentre to Origin" on your main (ScaleFactor 1) reference frame, and choose a transform that you want to keep close to the origin, either the player (if the camera follows it automatically) or the perhaps the main Camera. Set a Recentre Distance, which will trigger a recentering whenever the player goes beyond that distance, and also populate the Offsettable Transforms List with the parent transforms of objects you want to be offset whenever the player is recentered.

When the player is put back to the origin, all the geometry around them has to be offset so that it looks like it doesn't move. If you have all your world geometry as child objects of a "environment" gameobject, you could put this environment in the Offsettable Transforms list, and it would be offset appropriately.

The World Reentering part of the system is still pretty bare bones - there's a lot more I'd want to do to it to make it production ready, but it functions well enough as an example of a way to approach the problem. One issue when moving the player in the Editor is that while you are clicking and dragging, you can't actually trigger a recenter without issues, as the Editor overrides the position of whatever you're dragging, which can cause a cascade of recentering attempts. To get around this for now, I simply force a deselect when the a recentering occurs. I need to figure out a better solution to this.

I think that just about covers everything. The system is pretty rough and barebones still, but I hope some people can find it useful. With a bit of tweaking I'm sure it can be used to create a realistically scaled Solar System where you can seamlessly fly to the moon, 380,000 km away, land, and walk around, without having any float imprecision and still being able to look back at the earth and see it properly.

If you have any questions or suggestions please let me know! Thanks again for all the support.

PS: There's also an atmosphere shader in there I'm playing with in the skybox, and some other half baked shaders that are in various levels of completion.