![]() Up until now the line ways were drawn using GPU lines, but I wanted more features than these simple lines. There are two kinds of graphical entities in my processed database: line ways and filled shapes. The preprocessor is now tagging and including more kinds of shapes based on the OSM metadata and the proto renderer is using more colors now. I switch to Luxembourg, looking for more complexity and a varied and larger urban grid. At this point I was starting to battle with the concepts of relations, in/out ways, and how OSM stores them. Larger shapes are now triangulated, stored and drawn. This involves storing the coordinates as a pair of 32 bit floats and using vector shader tricks when doing the view transform to keep the full precision without ever using 64 bit floats, which are terrible in consumer GPUs. Also not visible in this map is the fact all the vector data is in full precision longitude-latitude, not missing a single bit. This would haunt me later on, but it was the right call in the end. I decided to triangulate on the preprocessor and not on the game, and take the extra storage hit. This is handling simple filled shapes already, as for example building footprints, which was a lot of work on the preprocessor side, since it needed to start triangulating ways and relations. If it’s not clear enough, the left side is my renderer, the right side is the OSM.org render.Īnd here it is with quite a bit of work in just a couple days later. Here it is with the same prototype renderer. I decided to iterate on increasingly complex and larger maps, switching to Andorra as an initial target. ![]() It is the street grid of my city, Barcelona, and it’s just doing polylines using GPU lines, with no real shape processing yet happening. This was the first time my rough prototype map renderer drew a recognizable map, processed by my OSM preprocessor. This would be low level coding with no game engine and using libraries only for things like image loading. It calls into the underlying graphics API of the system via the excellent bgfx, and it would be all in C++, with me having been reconciled with the language after a years long detour into various Lisp dialects. In parallel to the OSM map preprocessor (which was alarmingly growing in complexity very fast), I started developing a map renderer. My own map format would be stored as a series of tables in a SQLite database, with proper indexing. I ignored MapBox, PostGIS and other ready-made solutions. My idea was to load these PBF files and transform them into my own database format, with heavy lifting of processing ways and relations into triangulated shapes and generating indexes as a preprocessed step. They are not database, being more like a serialization of the OSM data. These contain an optimized protobuffer dump of the OSM database, and can be found already pre-cut down into countries or regions. I like programming way too much for my own good sometimes, so I decided to start from raw OSM PBF dump files. The obvious place to start was OpenStreetMap. I really wanted to have the real world maps as the map of my game, the canvas for the player to build their track networks, but doing so would require using actual GIS data. November-December 2018 - I hope you like maps So, barely a month before my finals, I started working on the idea for way too many hours every day. The idea of doing the railroad game with a track design based on this line interpolation started taking shape. I was truly enamored with this way of smoothly interpolating a polyline into a curve, which was new to me, and seemed much more usable than the splines I knew. But the various games I tried that had vector-based tracks had either a too complicated interface for laying them, or tried to simplify too much and the curves seemed unnatural and quite different from real world track layouts. I also had been, for some time, thinking about doing a game about railroads, with the twist of making it based on real world maps, trying to approximate real track networks. To me it looked like a series of circle arcs linked by line segments at their tangents, and I quickly produced a bézier approximation of the same idea, drawing the arcs using cubic béziers with the often used coefficient of 0.55191502449. I saw tweet about paper which involved a very smooth, very natural curve interpolation, and I was immediately intrigued. I’ve been working on it for the past 18 months and I kept a development diary. NIMBY Rails - A development retrospective 16 March, 2020
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |