Maps and the like
Added 2019-08-24 09:03:39 +0000 UTCOkay, now that I’m done breathing into a paper bag for a moment, I have the Q&A for the Patreon launch up on SoFurry now. Easier than to keep putting it off >.>
Other notes for this lovely Saturday before I go try to find more croissants:
- Chapter 2 of The Valiant and the Bold is up, which at 4,000 words of notes is I think probably the biggest ratio of story:notes I've written. That's probably worrying, isn't it? :P
- I know there are bugs in the animation system for the map. It probably needs to be completely refactored, but I thought it was better to have something up rather than to continue to have two entirely separate forks of the renderer.
To explain a bit more: the first version of the rendering system, which was used in the original Hatikvah map, took geocoordinate data from KML files which were then translated by a Python script into normalized X and Y coordinates, which—
Well. No. To explain even further, the original map for my fantasy setting was—and is—done as an SVG file, in Inkscape. I wanted to use vector graphics because they're smaller and more efficient, and because they would allow me to do things like using the same map for city-level and continent-level data.
The problems were threefold. One, Inkscape is a pig and started choking. Two, the way SVGs work is you say "well, this river is 2px wide" and you can zoom in, as you like, to draw a house with walls that are .00005px thick, but that house then becomes invisible when you zoom out, so the idea of having one map became slightly more complicated. Three, and this is the big one: Inkscape canvases are square, and the world is not, and eventually it reached the point where I was covering enough of the world for those distortions to become noticeable and problematic.
So I wrote an engine that took KML files, extracted and normalized the data, and then plotted that on an HTML canvas. Because it's constantly being redrawn, that means that I can simply decide country borders are always 1-pixel wide at every zoom level. And because it's constantly being redrawn, I can switch off rendering of city buildings altogether above a certain altitude. And because it's constantly being redrawn, I originally decided to precalculate all the normalized values, so the source data for the map engine is already in non-geocoordinate format.
As it happens, however, the performance impact of doing that live turned out to be fairly minimal, and precomputing everything was a pain for other reasons. So after testing the map with Hatikvah, I redid it without that intermediate conversion step. All values are now lat/lon pairs, rather than x/y ones. This also means that in the definition files, I can now say "this street is 5 meters wide" rather than "this street is 2.5 dimensionless units wide."
But it also meant that some of the values that were used in the animation engine needed to be rethought, and the animation components were always a little bit hacky, so they expose more of the flaws of this entire approach.
Still! It works, mostly, and you can build your own if you like :P It's just not as user-friendly as it could be.