[SOLVED] Best way to implement dynamic skybox?

I would like a skybox with the following properties:

• Sun and moon that move across the sky
  
• Colour that can vary over time
• Texture that can vary over time (e.g. clouds during the day, stars at night)
  
• Distant land texture at the horizon (as seen here)

Here are the options I have considered:

Procedural Skybox
This is somewhat configurable in terms of colour, and comes with a moving sun, but does not support a texture or a moon.

Texture / Cubemap
This allows a sky texture and can be tinted different colours, but I believe it is essentially static; I can't see a way to translate or transition between textures, and the sun and moon would be in fixed positions.

Physical GameObjects
I could add physical objects to the world to represent the sun, moon, clouds, etc., but this comes with a whole host of problems, e.g. requiring a very distant camera clipping plane, objects becoming obscured by fog, objects intersecting distant geometry, etc.

Custom Shader
I imagine a custom shader could take care of all of these requirements, but this is likely to be a last resort for me since it is currently far beyond my skill level.

So, how do people typically solve these problems? Is this an accurate summary, or have I missed anything?

 

No, it doesn't come with a whole host of problmes.

You can either use two camera setup and set skyboxx on separate set of layers used by the camera... or you can utilize shader rendering order.
https://docs.unity3d.com/Manual/SL-SubShaderTags.html

Setting object tag to "Background" will make it render before anything else, and if it doesn't write into zbuffer, it won't obscure anything that is rendered after it.

Your entire skybox can be 1 meter large sphere centered around camera. The idea is to make sure it doesn't affect depth buffer so the rest of the scene can be rendered normally.

 

By using one of sky/weather packages from the Asset Store, which have already everything you listed.

 

Like neginfinity said, just use a second camera. You can create incredible skyboxes just by adding objects and particle effects in front of it. Trying to make one shader render an entire dynamic background is just adding a ton of unnecessary complexity.

 

Thanks, this is exactly what I was looking for! Using 2 cameras and making the various sky components into physical GameObjects has solved all my problems.

Very valid suggestion, but I am still curious to understand how these things work, and I learn a lot more by implementing it for myself.

 

This is just a lazy and uncreative answer to the question. The assets in Asset Store are also created by people, and OP wants the technique to learn. You should tell about that and not just suggest to use premade stuffs.

 

BTW the examen image is daggerfall unity, which is open source and accessible on github as a unity project, you can probably use that to learn.

 

I downloaded and messed around with daggerfall unity project a while ago, I suggest you don't -- everything is spawned at runtime from disk, scene view doesn't work for the game without going in-game, and a host of other weird unusual workflows.

Not what you might be used to for a unity project.
Also, No scenes.

 

Good to know. But you made more interested now, because I'm slowly evolving towards "weird workflow", like I have a need to reimplement my own scene manager due to limitations I'm bumping into lol.

 

Those "weird unusual workflows" make perfect sense given the use case. My understanding is that they haven't recreated the Daggerfall content, they've made a Unity app which can load and run that content. I also vaguely recall that Daggerfall heavily uses procedural generation. So editing stuff as typical Unity scenes likely wouldn't make sense - it's all just data fed into algos, and the whole point of the project was to use data which already existed and thus requires little (or ideally no) editing.

 

It's offline and baked.

Also level design (dungeon) has a very convoluted system of module that actually have many structure (of the same type, a single structure can contain many "room" or "corridor") that aren't necessarily connected in the final map, all to save space by grouping similar stuff together and reusing them (ie rotate to align the relevant one to the active one used in the map). Old games do wild wild stuff as optimization.