In the last couple of weeks, numerous inquiries reached me, asking about the current state of the development of my tool to the edit existing X-Plane terrain meshes. In summary I can say: The development of the core features is finished and the tool proved itself already in various payware (e.g. recently released Aspen XP) and freeware (e.g. upcoming Cologne-Bonn) projects.
Why do I offer mesh editing only as a service and why isn’t the tool available yet? The answer is, that I want to avoid that we just have another tool in the series of VertexTool, RasterTool and MeshRemexe, which offer some basic editing options, but don’t really suit the needs of the scenery designers out there and don’t takle the real issues: Particularly the implications in conjunction with the distribution of edited meshes.
With the start of the development, I announced to aim for a mesh patching workflow, that is smoothly integrated into the existing workflows of scenery designers. Furthermore, the mentioned implications should be avoided by shipping only patches with scenery packages instead of whole X-Plane terrain tiles. Last but not least, the mesh patching should require as less as possible technical knowledge from the endusers. In the best case, the mesh patching happens automatically during the runtime or startup of the X-Plane application. A goal, I cannot reach by my own and therefor I’m in contact with some experts which are very close to Laminar Research, the developer of X-Plane.
There are various technical and organizational questions to answer: “What is a patch and what not?”, “When should we recommend a mesh patch and when a mesh recut from scratch?”, “How does a patch look like, what characterizes a patch?”, “How could a patch be applied, so that the end user doesn’t need any deep knowledge about meshes and how they are organized?” and so on.