Landscape UX/UI

[binstream]

Together with new UnigineEditor iteration we are working on new version of landscape tools, here is the preliminary UI mocap. The goal is to streamline workflow and improve productivity of creating large terrains. First iteration (with limited featured) should be available in 2.3 release.

 

 

Sorry about the quality, but there were requests to involve customers as early as possible, so we are doing it.

It would be interesting to know if the concept is understandable from the user stand of point.

 

The "processing rule chain" concept is intended to primarily eliminate the need for 3rd-party tools from the terrain content pipeline. The idea is to introduce a universal rule API, so rules could be implemented in various ways (C++/C#, node-based flow, Python script, etc). Rules are to be implemented in 2.4.

[tmorris]

Oh man, this concept seems really really nice! I have been wrapping my head around ways to remove 3rd party tools from our terrain pipeline, seems I might no longer need to do this!

 

My biggest question when looking at this concept is how are the base data layers handled (import vs creation)? 

 

For now I think this initial concept is very understandable, I am excited to see how this progresses, especially the processing rules chain side of things.

[binstream]

Terrence, at the moment we expect that all of the data (both raster and vector) have geo coordinates on import time. We are not going to provide full GIS editor features (at least for now), the landscape tool is intended to handle import.

[renato.semadeni]

Looks really something we want to get our hands on it! =)

 

Regarding the large possible land cover classes and each with their different values, it would be very handy to be able to adjust the import and/or assignment in the landscape tool instead of processing it through a third party tool. Another question for me is, how to overlap regions when building large database from different sources.

 

The overall concept is very understandable and points in a very interesting direction to improve the workflow of building terrains.

[binstream]

Regarding the large possible land cover classes and each with their different values, it would be very handy to be able to adjust the import and/or assignment in the landscape tool instead of processing it through a third party tool.

Another question for me is, how to overlap regions when building large database from different sources.

 

The idea is that there are pre-defined data source types + custom ones. Most pre-defined types have explicit interpretation (like elevation), the idea for overlapped areas is to use values from the lowest item of the list + some interpolation on texture edges.

 

As for land cover classes - the idea is to be able to specify several rules (e.g. grass, forest, snow caps, etc) and freely assign any of the data sources as input, including reading specific image channels and data ranges.

[binstream]

Work in progress: framework done, starting UI assembly.

 

[s.moussa]

Very well, that 's exactly what was expected of the evoluted landscape tool !
The concept is understandable, but at this stage it raises many questions (which I imagine you don’t necessarily have the answer today) .
However, for a perhaps clearer idea ( on the concept and the features ) what will differ from a tool like worldComposer for example? Is it the same "philosophy" ?
Then another question I ask myself ( as it is related to the maximum resolution of future landscapes , crucial parameter for us) which GIS databases will be connected?

[binstream]

Very well, that 's exactly what was expected of the evoluted landscape tool !

The concept is understandable, but at this stage it raises many questions (which I imagine you don’t necessarily have the answer today) .

However, for a perhaps clearer idea ( on the concept and the features ) what will differ from a tool like worldComposer for example? Is it the same "philosophy" ?

Then another question I ask myself ( as it is related to the maximum resolution of future landscapes , crucial parameter for us) which GIS databases will be connected?

 

We plan to develop the tool by iterations: at the moment it is clear what set of minimal critical features is required, so we are focused on delivering it. As far as I understand our concept is similar to WorldComposer in a lot of ways, the main difference is that it is targeted towards professional projects and the underlying engine is UNIGINE 2.

Regarding GIS databases at the first stage we are looking for working with local files, and later adding online data sources.

 

Some more WIP today:

[binstream]

Work in progress (2.3-beta)