Hello there, spacefarer!

Welcome to my humble abode.
It’s where I tinker with maps and think about stuff.


HUD Recolor

I was able to obtain the golden dream of Elite Dangerous HUD recoloring:
Changing the main HUD color, while also keeping RED, GREEN, CYAN, WHITE separate, often unchanged, as in RED stays RED, GREEN stays GREEN, so on and so forth.

ED Green

ED Blue

ED Blue Medium

ED Cyan

ED White

ED Purple

ED Magenta

The problem though, is these color transformations were obtained inside a graphics editing software, by applying a channel mixer, with values going between -200% and +200%.

My in-game testing looks different: The colors are displayed as intended on Station HUD displays, but different on Cockpit HUD displays: more red on the red channel; or it simply doesn’t apply the whole transformation range (-200% to +200 percent).

In-System Distance Chart

2000 Ls. 15 AU. Quantities like these are often encountered by any commander. But what do they MEAN? How do they compare to anything meaningful? Some people may do maths and conversions really well in their heads, but I tend to understand only what I can SEE. I’m a visual person. So… here’s a “map” (official name “Chart”) I tinkered with for a while (drawing a bit of inspiration from Dieter Rams’ minimalism), that plots out the SOL System’s planets and orbits (including Pluto) on their accurate real-world positions for 1st December 2015, and then adds a double grid for comparison (in AU and Lightseconds). Now everybody can SEE what AUs and Ls mean.

In-System Distance Chart

Mapping the Galaxy, one fail at a time: Rare trades map

Ever since starting playing the Elite: Dangerous game after its release I began thinking about space maps. Which raised questions: How to best represent 3D-data on a 2D surface? What axonometric projection would help comprehension? What visual tricks could aid in simplifying complexity? Also, some theoretical questions, like “Somewhere in the future, 3D galactic cartography will become a real field of activity. How would it work? Does it make practical use to divide the Galaxy into quadrants and sectors, like in Star Trek?”. Present-day systems, like MGRS, divide the surface of the globe into an efficient grid system. I started thinking about the sizes of a “star sector” and a “star district”, and about dividing the “habitation zone” into “octants” and “belts”. But that’s material for another post :).

(If impatient, scroll down to red)

After messing about with hand-made grids and hand-plotted data, I got to the point where the need for at least some automatization of the process became imperative. Instead of measuring my own data by eye in-game, I chose to use the 3D-data from the rare trade systems, already gathered to (I suppose) a high precision. I put X,Y,Z data in a spreadsheet software and transformed it into the X and Y needed for the “cabinet projection“. If the nasty math thingies down this linked page baffle you, don’t worry. They baffle me too :). Math isn’t my forte (far from it), but I’m a visual thinker: If I can draw something, I can understand it. So, whenever I need to, I attack a math problem visually until it cracks :). I only need some logic and visual thinking to hack all that obfuscated, mind-bending trigonomathemagiks into simple proportionality; you just need to figure out the correct ratio, and be careful about how values along one axis are linked to values along the others. Why work with stuff like xz=x′2⋅cos(30∘)+y′−y=−x′2⋅cos(30∘)+y′−y when simpler things like X plus Z minus something divided by 1.73958blahblah produce just as accurate axonometric visuals?

Processed spreadsheet data is then copy-pasted into a .xml file which the vector graphics software can understand.


D-ImportSo I finally got my data inside the graphics software automatically by means of a graph (again, visual hacking: it’s a scatter graph, I don’t think it’s supposed to draw lines, I just found out that it could). Looks messy, but I’ve got there every visual clue I need (distance from the origin along the 3 axes) to build up the visual representation. The visual solution is the classical Elite one, of objects-on-a-stick, growing up or hanging down from the reference horizontal plane.


D-DimetricLooks like we’re getting somewhere, don’t we? Do you recognize the Lave cluster?

Alas, the classical Elite objects-on-a-stick representation works nicely in typical combat situations, with a maximum of 5 or so ships around you. The in-game data is also dynamic, which helps. When you have a whole bunch of data, especially in a static representation, the objects-on-a-stick solution begins to woefully show its limits. Here we have a lot of long hanging lines, that, while usable, add a lot of confusion. It’s like crawling on all fours under your desk, trying to find the end of an elusive cable hiding among a whole buch of them. Kinda.

So it’s back to the drawing board. I noticed that the space occupied by data expands less on the Z axis than it does on the vertical axis. Soo… I thought I could be smart about it: Instead of plotting the X,Z data on the horizontal plane and extruding the “helping sticks” vertically, let’s plot the X,Y data on the frontal plane, and extrude the sticks along the Z axis.


D-SideWell, there seem to be shorter lines and less clutter. And there’s the Lave cluster again. But not the most natural-feeling visual representation. Usable somewhat, and giving a rough comprehension of what is where, but it feels awkward for any precise(ish) measurements you might need. You’d better try translating a Georgian book into Chinese while stiff drunk and parking a double-trailer backwards at night, standing on your hands. You get the picture.

So it seems horizontal reference plane is a must. But… I’ve got to find some kind of shorthand notation for those long lines. After fruitlessly messing with all sorts of artsy but confusing “3D-trees”… and watching endless bunches of architectural drawings… I got back to something I purposefully avoided right from the start: the isometric projection :). Try drawing a cube in that darn thing to see why I mistrusted it at the start: too much superposing; the cube’s center and 2 corners occupy the same position. But the overwhelming popularity it enjoys among architects can’t be for nothing, can it? I should give it a try.

When adapting the spreadsheet transformation to the new projection, there were some mishaps: the results differed from expectations. Told you, not good with math. Checked everything, tried again, still wrong. Oh well, let’s just do it by hand. How hard can it be?


D-Manual IsoRiiight. You just draw three lines for each star you need, and fit them properly. You only need… over 300 of them. Crap. Oh well… I guess I need to go back to doing that math properly.

After getting my data plotted on the isometric projection, I saw that my preconceptions about using it were unfounded. Giving equal footing to all three axes actually helps things spacing out a bit more. Less bunching-up, which is a good thing.

The big idea though, inspired by another round of hand-drawing (on printed templates), was to renounce referencing all objects to the Y=0 plane, and segmenting the whole vertical space into 100-Ly “floors” (or belts, levels, bands, whatchamacallit), each with its own “ground”, out of which objects rise from. There’s a reason subway cars got doors on both sides. Divide et impera.


D-Dark(Open large image)
No more bunching up on the same reference plane. And no more sticks hanging down: the growing-up sticks feel a lot more natural, and intuitively comprehensible. We’re humans, not bats or spiders. There’s still visual vertical referencing to “ground-zero”, but it’s de-emphasized.


D-BlueWith the biggest hurdle out of the way, all it’s left is easier: tinkering with color schemes, line weights, labeling, and further visual helpers.

An unexpected advantage of the isometric projection stems right from the superposing I hated at the start: The horizontal grids for the various 100-Ly-multiple “floors” fit perfectly over each other. So you basically have one versatile horizontal grid, that you can use interchangeably for whatever set of vertical data you need. The fact that it can be used with data at different altitudes can become somewhat confusing; but if you pay a bit of attention, it’s really nifty, with advantages outweighing any shortcomings.


D-Rendered-ED-Iso-008(Open large image)
For the the final round, I reduced the clutter even further: the vertical reference lines stop climbing all the way to the Y=0 plane, and only go up to the next ceiling.

Scale it down, with 10-Ly floors, and you can in theory plot the whole inhabited space on a single sheet :).

PS: Some things still superposed. So in the grand interests of comprehension, I cheated, moving them a bit to the sides, to create perceptible separation.


New version released, with travel routes marked.
(Open large image) or (PDF)

New version released, top-down view with travel routes marked.
(Open large image)


A long fan of space (games, astronomy) and a graphic designer. Also quite fond of maps and information graphics. On this blog I collect my tools, musings and impressions.

Can’t vouch I’ll keep doing it. Hey, at least I started!

Everything I post is subject to edits, changes and updating, if I deem it necessary. Think of it less as a blog and more like a wiki.

In case you feel like rewarding me for my contributions: