📜 ⬆️ ⬇️

ZSlice landscape editor



I have long wanted to talk about the project ZSlice.

The editor has been developed for about 5 years, survived two prototypes and a complete rewriting ...
And still under active development.
')
Probably, I would not have ripened to write this article for a few more years until the editor is 100% licked and functional. But as my colleagues rightly noted, this will never happen. Therefore, the idealist inside was slightly smothered, resulting in the writing of this article.

Over the past few years, game development has seriously changed. The value of the game code itself has dropped significantly, and the value of content, on the contrary, has increased. 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.

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



This track was made about 3 months.

Too slow development as a result affected the enthusiasm, the floaters 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 opportunities to complete it.

At about the same time, it was understood that forcing modellers 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 fairly complex and time-consuming activities.

Began a leisurely search for the editor. It turned out that free editors are full of editors who know how to create a landscape, but the construction of roads in them is either completely absent or is at an extremely flawed level.

I will give an example: the landscape is aligned under the road and at some distance from it. And the road is superimposed on top in the form of a decal. Even recent Just Cause 2 suffers from this (you can see that the landscape next to the road always strictly corresponds to the geometry of the road).
I was not satisfied with this situation and I began to create a tool for editing landscapes. Not to compete with already existing editors of the height map (it’s almost impossible to compete with them, to take at least the World Machine ), but in order to solve a single task - fast, convenient and high-quality road construction.

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

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

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



The screenshot shows the landscape created for the game "Storm: The Line of Defense", which participated in the strategy competition on gamedev.ru
Game Information Storm: Line of Defense, if anyone is interested


Video with the game, ranked first. Just can not fail to 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 10 places in the region, and there were many projects that were embarrassing to lose.


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



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

Also, when developing the second version, we took into account that maximum actions should be available outside, through the API. It is impossible to predict exactly what functionality the user wants. 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 the brushes in the editor from hardcode moved to an external plugin.

Unfortunately, this is also not a completely trivial matter.

And the problem here lies in the very curb 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-junction of four blocks). At the same time, from the outside it should look like editing a single point in order not to complicate unnecessarily the processing process.

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 gigantic areas, I had to find a solution that would allow changing such landscapes. And streaming seemed an adequate option. Streaming has been fully implemented, but the practice of use has shown that this creates some difficulties. Not that it was very annoying ... But in the conditions of modern reality, when memory volumes are constantly increasing and even the browser is not ashamed to eat a few gigabytes, complicate the tool and reduce convenience in order to save memory is simply not justified. Therefore, the new version of the editor moved to the 64-bit compiler and lost the possibility of streaming. Even very large landscapes fit in 5 gigabytes of memory. And it covers most needs. Well, 1% of those who need landscapes of 100x100 km, will be forced to re-buy a few dies of RAM in their workstation. However, nowadays even 32 gigabytes cost quite tolerable money.

The editor continues to evolve. Now, taking into account the new experience, we are already talking about the transition to the third version of the editor, again with full rewriting. 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 via the link: www.dropbox.com/s/j08r1a2z095h9ai/ZSlice_build_2014_04_02.rar

Please note 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 distribution of vegetation) is only indicated, but not fully implemented.
The editor is free for non-commercial use.

API and source codes of brushes and exporters are sent on request.

PS Of course, the original idea to make the Rally has not gone away.

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

image

Source: https://habr.com/ru/post/234627/


All Articles