(Experiments) Spherical Worlds in Unity tests.

I've run a few experiments in a past few days looking for the better ways to create spherical subdivision that can used for spherical worlds in unity. I've put it into a gist which is here:

https://gist.github.com/NegInfinity/b0ceca81324b68c2eaecde93f0dc0dd2

Spoiler

All information is in the gist, but I've copied some of it here:

What is it?:
It is a quick test made while investigating possibility
of making sperical worlds in unity.

How do I use it?:
Add an empty into the scene, add GlobeVisualizer to it.
You'll see a wireframe, if you want a mesh, hit "Play"
in editor. No warranties whatsoever.

Related materials:

• Creating Spherical Worlds (sap 0251) (spore developers)
• https://en.wikipedia.org/wiki/Quadrilateralized_spherical_cube
• COMPARISON OF SPHERICAL CUBE MAP PROJECTIONS USED IN PLANET-SIZED TERRAIN RENDERING Aleksandar M. Dimitrijevi´c, Martin Lambers and Dejan D. Ranˇci´c
• https://acko.net/blog/making-worlds-1-of-spheres-and-cubes/

Details?
I've tried tetrahedra and basic cube using normalized lerp, and slerp.
I originally hoped that I can get away with using a tetrahedra-based map, because
it can be wrapped nicely into a texture, but the distortion is significant,
whether it is normalized lerp or slerp.

Conclusion?

• The simplest way to store spherical data would be using spore dev method, where they simply used cubemaps. The advantage is that it is fast and GPU accelerated. The disadvantage is distortion, which is the worst among all possibilities presented in "comparison" paper.
• The most decent way of storing data seems to be ASC projection ("Adjusted Sphere Cube"), as it is equal area and does not waste too many texels. Dealing with it requires atan, sin and cos, but with modern gpu horsepower this should not be a problem, even if you do it per-pixel. Plus you can always do a lookup.
• It seems that that there's no point in tryign to directly use map faces in some sort of "flat" overland view, like acko's author is trying to do and it would be better to generate "flat" overland view dynamically by sampling the map.
• Thinking about it more, for many things it would be erasonable to use lat/long coordinates, and convert them to whatever is necessary when needed. It is also possible to use the cubemap for landscape data and t hen use whatever for the map itself.
• It seems that if the planet is sufficiently large, the best idea would be to treat things like cities as "anchoret" flat or mostly flat regions. The terrain of the region could be generated from cubic map data, but while the player is within the region, for all practical purposes, it would be a standard flat world.

 

I'm on the same boat, have you tried octahedra mapping? I'm planning to use the two hemi octahedra for convenience which I dubbed the pillow sphere. Octahedra map have minimal distortion, simpler math, have squares footprint that map to a texture nicely. I have been using the full one in shader as a replacement for cubemap.

My concern was to create procedural circulation, that meant easy query of the grid neighbor, while maintaining gameplay distance metric. The double hemisphere varient only have 4 poles and 4 edges. Crossing edge and pole, was being a big deal because that mean sudden shift on coordinates system, the hemi varient makes it rather trivial, there is 2 contiguous edges, that allow "wrapping", and one trivial conversion for the "shifting" one. The map get easily unroll to square side by side on the "wrapping" edges. The computational bonus is that once you have calculated one hemisphere, the other is the negative of one component.

 

I know you're talking about spheres, but I've been really into the idea of ring worlds lately. It's still makes for an interesting world (i argue moreso than a sphere) but the math and tiling is a lot simpler because it only wraps on one axis. All the usual grid methods still work the same. You just sprinkle a bit of simple math to convert from a position in the ring-world to a position in the flat-world (as if the ring were unrolled to be one long flat world).

 

Well, this is similar to capped Equirectangular projection ( https://en.wikipedia.org/wiki/Equirectangular_projection ) except you're doing it on the inner side of the globe. The idea is to keep usable latitudes close to equator, and forbid approaching poles. I think Empyrion did it the same way.

Something similar happens in Dyson Sphere. In Dyson sphere they cover planet in "grid strips" which attempt to maintain same cell size. Widest strip circles around equator, when you move towards poles, strips become narrower. When you stand on strip boundaries, called "tropic lines" this happens:

Spoiler

Buildings are placed strictly at grid line intersection, and this sort of design means two drawbacks:
Factory blueprints cannot cross tropic lines (because grid coordinates change), and additionally something that is buildable at equator probably isn't goign to be buildable close to poles. Because cells are smaller, and buildings starts to collide when placed.

Speaking of spherical worlds, we also have rimworld with spherical planet, but they use basic geodesic grid, meaning hexagonal grid with 12 pentagons on it. It works in rimworld, because when you enter a hexagonal cell, it produces square local map.

 

The Sphere Cubes do seem the way to create good geometry and map on textures.
But making a game based on spherical worlds seems like making a lot of extra work for yourself, also I am not convinced the gameplay really works, because you can not get a clear view of much of the play area (any 2d map might help but would be distorted).
I feel like space games should use Flash Gordon (film) style flat worlds on floating rocks!

 

Well, I looked into it, because I was interested in LARGE spherical planets and not "baby planets", like in Spore or Dyson Sphere.

We have an example of large planet being used in videogames, and that's... X-Plane 11. They have life-sized Earth (which means getting anywhere takes eternity even in a jet). There also used to be life-sized mars in it, but something happened to it. However, they're not using sphere cube, because at some point it was impossible to fly over poles, meaning they used some of the standard map projection loaded as sectors.

Regarding 2d maps, it feels like the best idea is to construct them on demand from spherical data. It is not difficult these days.

And regarding gameplay.... it is not possible to make a huge planet with insane detail, so in a large scale world you'd be dealing with a lot of "hubs" placed at coordinates, and between the hubs it'll be pseudorandom generation.

 

Not really worried about this being in General, but if you want it moved, poke me later.

 

Nah, this is fine, but thanks for your concern.

 

Also just some other point for octahedra map with two hemi.

1. The math is simple, therefore no float precision issue like the sphere cube with adjusted deformation (I know, I tried). Which is why I shifted.

2. The pole corner tiles degenerate into relative triangle, you can fuse both them into a square rather simply (basically the two touching corner would be treated as the same), and it makes a lot of transition over the pole way simpler.

 

Interesting.

Spoiler

However, with cubemap you won't have mipmapping problems. Meanwhile octahedra map seems to require this:

Spoiler

 

Unless you try to do custom cubemap, and you will have to stitch the 0.5 pixel offset yourself. Static sky, a mobile game from unity 4 Era had to do it. I choose it for shader because I was making an atlas, and the target didn't support cubemap array.

But in the context of planet tiling, I don't see it has a problem. I suffered a great deal with the usual sphere cube. I actually do all computations in 2d and translate back and forth when needed, so the coordinate stay consistent for some basic querying. Transition to negative hemisphere is equivalent to a mirroring, while I don't do it, you can probably "recycle" just a single hemisphere for coordinate and a bool for detecting which hemisphere, as a premature optimization for fun.

 

Will pathfinding in such world model be computed for flat coordinates first, and then transformed to spherical coordinates?

 

If the planet is huge, then you'll be using standard pathfinding for current region.

If the planet is tiny (Little Prince/Spore aka "baby planet"), you'll need a custom solution. Pathfinding algorithms like A-star work on graphs. So they do not care about shape of your world.

 

Depends on your heuristic for distance, assuming global pathfinding and you go custom and not unity's. Crossing the edges and poles of any of the solution that use flat like source primitive is something that you will need to tackles. Generally you wouldn't be able to flatten at edges and poles, because that's how curve surface works. The solution would be to treat each surfaces as it's own flat area and find way to transition to other area, which is where the whole edge and distance management apply.

 

Got it. No matter where you go, "seams" of the projection are the main problem

 

small planets != big planets - very different techniques
big planet games are hard, especially if space faring - see star citizen, Beyond Good and Evil 2 lol. But flight sims ok

 

I was thinking more about small planets. And preferably reusing the existing navmesh algorithm (thats why the talk about calculating the nav data for flat projections and then "spherifying" it). I'm not sure I'll be ready to make my own navigation

 

There is also the Buckminster Fuller dymaxion projection which doesn't suffer from cell shrinkage and uses an icosahedron.
https://www.atlasofplaces.com/cartography/dymaxion-world-map/
Pretty good layout for UVs as well.

 

That one is a variation of geodesic polyhedron.
https://en.wikipedia.org/wiki/Geodesic_polyhedron


It is a fairly common one, when peoplewant hex tiles. It is still going to have 10 singularities, meaning 10 pentagonal shapes on the map.

 

Yeah, we used a subdivided icosahedron to runtime generate little planets in our game Element (https://elementgame.com) but we didn't need to worry at all about the singularities or doing any texture projection. I remember falling down the well of world generation for quite a while prototyping various techniques but I've forgotten most of the stuff that might be useful for your larger worlds.

 

12 if I remember correctly, not 10.

 

The problem is the same, edge and pole don't disappear with scale, big planet have more loading/LOD/scale/editing/float problem.

But big is relative, if you use planet centered on origin and have radius lower than 8km, you would be able to rip the benefit of not having to deal with floating issue:
- 1 km radius is 12km² of area (roughly equivalent to a 3.5 x 3.5 km square map)
- 4 km is 201 km² (14x14)
- 8km is 804km² (28x28)
- skyrim is 37km² (6x6 but skyrim map isn't a square)
- Botw is 49km² (7x7)
- wow is 113km² (10x10)

As you can see, map are decently sized for gameplay without hitting the float limit, You still have issue of dealing with LOD and usual terrain chunking stuff.

So my guess is when you say small, it's probably mario galaxy small. You can probably use the dot product of two normalized position on the sphere as a distance heuristic, it's a good approximation of the great circle distance on sphere. If you want proper "relative" distance as an heuristic, you can scale the result by the radius or multiply by the perimeter. The issue is that dot product is in the range -1,1 so you will have to remap that (0 is one quarter, 1 is no distance aka closest, -1 is antipodal, you should lever have any distance bigger that 180°) .

 

@neginfinity Interesting topic, thanks for sharing the gist.

@neoshaman I was going to ask if it was worth scaling everything down so a 1m unit becomes a 1cm unit but a little research suggests that would be a poor approach to the scaling problem.
I found this thread which talks about the floating point issues on large scale worlds which also has a link to this which details why its an issue should anyone else be interested.

@greg-harding Nice looking game, I just grabbed a copy from Steam.

 

Due to nature of floating point, usable area of the world will be roughly the same regardless of the scale you use. You'll have roughly 8 km cube, whether you use 1cm or 1 meter as a unit, and you'll need some sort of origin shifting algorithm if you go beyond that.

Games that have "baby planets" often have them small enough to fit into that cube. That would be spore and dyson sphere.

No Man's Sky is said to have larger planets than this - online sources claim that they use 74 mile diameter planet. That's 120 kilometers. Elite Dangerous also has large planets (planets are said to be life-sized), but I doubt that there's a lot of sense trying to circle a planet there in a vehicle. Those games seem to be streaming sectors as you move.

 

No man's sky didn't need that big of a planet,

Spoiler: no they didn't.

that's a mistake they made the moment they formulated the idea to have planet as stop, collect and go, instead of exploration. Now they have 120 km radius of copy pasted pattern with equal distribution of resources, because you are supposed to be able to land everywhere

.

 

No, they got that part right, because baby planets are not a whole lot of fun.

Also, it is not "stop, collect and go", because there's base building.

 

Thanks! I hope you have a few minutes of fun with it. I would have sent a key your way if you mentioned you were interested in taking a look

It's a little old now (Unity 2017.4) and has a few rough edges with UI scaling and a few other things that bug me but it's hard to find time to keep things up to date. It was just two of us working part time and it was our first 3d title so there was plenty of learning done as we built it. Updating to use the modern UI, TextMesh Pro, nested prefabs, better audio systems, and a bunch of other things would make the project a lot nicer to work in.