ZSlice landscape editor

    I have long wanted to talk about the ZSlice project.

    The editor has been under development for about 5 years, survived two prototypes and a complete rewrite ...
    And it is still under active development.

    Probably, I would not have ripened to write this article for several more years until the editor is 100% licked and functional. But as my colleagues correctly noted, this will never happen. Therefore, the idealist inside was slightly strangled, which resulted in the writing of this article.

    Game development has changed dramatically over the past few years. The value of the game code itself has fallen significantly, while the value of the content, on the contrary, has grown. In the modern world, writing a game is not a problem. The problem is to create enough quality content.

    In 2007, by chance, I got into the company of fans of the rally simulator Richard Burns Rally.

    In about a year of work, we made a simple rally engine. Of the content, we had one car and a track in Novorossiysk:

    This track was done for about 3 months.

    Too slow development eventually affected enthusiasm, graters went inside the team ... In general, the project never saw the light, although its ideological inspirer, as far as I know, is now looking for ways to complete it.

    Around the same time, the understanding came that forcing modelers to create tracks in 3ds Max or Blender is inhumane. The tool is not sharpened for such tasks, and even a simple tutorial on creating a road is a set of rather complex and labor-intensive actions.

    A leisurely search for the editor began. It turned out that in the public domain there are a lot of editors who can create a landscape, but paving roads in them is either completely absent or at an extremely flawed level.

    Let me give you an example: the landscape is leveled under the road and at some distance from it. And the road is laid on top in the form of a decal. Even the very recent Just Cause 2 sins with this (you can notice that the landscape next to the road always strictly corresponds to the geometry of the road).
    I was not happy with this situation and I began to create a tool for editing landscapes. Not in order to compete with the existing editors of the height map (to compete with them is almost impossible, take at least World Machine), and in order to solve the only problem - fast, convenient and high-quality paving of roads.

    The first version of the editor was a prototype designed to test your ideas.

    But even the prototype already allowed creating quite decent landscapes, albeit with limitations.

    This is what the first prototype of the editor looked like just before his “death”:

    The screenshot shows the landscape created for the game “Storm: Defense Line”, which participated in the strategy contest on gamedev.ru
    Information about the game Storm: Defense Line, if anyone is interested

    Video with the game that won first place. I just can not help but mention this project.

    When watching a video for a second there is no feeling that the game was made in less than six months by one person. It was not a shame to lose such a project.
    However, in this competition we took 10th place in the region, and there were many projects that it was a shame to lose.

    The prototype allowed us to expand our understanding of landscape management processes. For example, an obvious problem surfaced that was not noticeable before implementation: the junction of two landscape blocks is very much affected by filtering. It’s not only necessary to duplicate the pixels on the neighboring block - the border should be two pixels thick, otherwise the linear filtering will cause such a nuisance:

    The strategy is not very noticeable, but if we are creating a landscape for a shooter, then this is already a very critical artifact .

    Also, when developing the second version, we took into account that the maximum of actions should be accessible externally, through the API. It is impossible to accurately predict what functionality the user wants to have. But this is not necessary. It is enough to give access to the API and the user himself will create the necessary tools.

    Therefore, all brushes in the editor from the hardcode moved to an external plugin.

    Unfortunately, this is also not quite a trivial matter.

    And the problem here lies in the very border created for the normal operation of filtering at the junction of blocks.

    In fact, it turns out that editing one point at the junction turns into editing up to 4 points (in case it is an angle-joint of four blocks). At the same time, from the outside it should look like editing one point, so as not to complicate the processing process unnecessarily.

    As a result, the API for tools has become a little more complicated than we would like and slower than it could be.

    The first prototype worked with the landscape through streaming. Since one of the tasks was to create an editor capable of processing giant areas, I had to look for a solution that would allow changing such landscapes. And streaming seemed an adequate option. Streaming has been fully implemented, but practice has shown that this creates some difficulties. Not that it was very annoying ... But in modern reality, when memory volumes are constantly increasing and even the browser does not shame to eat a few gigabytes, complicating the tool and reducing convenience in order to save memory is simply not justified. Therefore, the new version of the editor moved to a 64-bit compiler and lost the ability to stream. Even very large landscapes fit in 5 gigabytes of memory. And that covers most needs. Well, 1% of those Those who need landscapes of 100x100 km will have to buy a few dice of RAM into their workstation. However, at present even 32 gigabytes cost quite tolerable money.

    The editor continues to evolve. Now, taking into account new experience, we are talking about the transition to the third version of the editor, again with a complete rewrite. The purpose of rewriting is to universalize work with materials and accelerate the API.
    The current version remains LTS for those customers who are currently using it.

    You can download the current version of the editor at the link: www.dropbox.com/s/j08r1a2z095h9ai/ZSlice_build_2014_04_02.rar

    I draw your attention to the fact that this is not even a beta, but a version intended for internal use. Accordingly, stability is far from ideal, and part of the additional functionality (for example, the arrangement of vegetation) is only indicated, but not fully implemented.
    The editor is free for non-commercial use.

    APIs and source codes for brushes and exporters are sent on request.

    PS Of course, the original idea of ​​making a rally did not go away.

    Actually, the editor is largely created and developed due to the use of it by our customers and, of course, in the SRF Rally project:


    Also popular now: