(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:

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:

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.


  • 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).


1 Like

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:

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.

1 Like



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


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.

1 Like

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.

1 Like

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

1 Like

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.
Pretty good layout for UVs as well.

That one is a variation of 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.