Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[deathevor]

Hi,

Just a quick post:

I really like your idea to accept user support in creating the world environment.
I definitely have a lot to contribute to this project.
I just have been playing with road tools and found information that you planing to do importer for Open Street Maps.

One of my ideas to create roads (or airports) that doesn't exist in OSM, was to have 2D software (new or existing one) like FAB (Fast Airport builder) or Airport Design Editor. It is much easier way to work with correct coordinates vector data. Preferably also to have elevation information attached to vectors).

So my question is, which file stores user vector data, and what is structure (format) of this data in Outerra?
I think I can write some script to convert data from existing programs or websites (like OSM) to Outerra format.

Also just an advice - building the roads in Outerra, you need to use waypoints. It would be nice to be able to see and correct coordinates for those waypoints. So just by clicking on waypoint to have a dialog box with it's editable coordinates. This way the roads can be built more precisely and easy adjustable.

I really look forward for any news from you. I think Outerra is really amazing idea.

[cameni]

Hmm at the moment our internal format is still somewhat unstable and incomplete. It's optimized for GPU rendering and partitioned in our tiling scheme aligned with the quadrilateralized spherical cube projection of OT. In other words, this format isn't really suitable for that purpose, it would be better to have an intermediate format.

Road API already contains functions that accept latitude & longitude and several other parameters, that could be used to create the roads. But at the moment the road maker only works from within the engine, though it should be possible to drag it out and make it stand alone.

It would be useful to have a tool that extracts external vector definitions, getting rid of unused stuff and partitioning it into smaller tiles so that our tool can process it easier and from a cleaner intermediate format.

Way point defined roads are just one type of vector data, there will be also another, polygon-defined, more suitable for larger areas.

Btw why not to add those roads and airports into OSM?

[deathevor]

So how those waypoints (roads) stored in game folder? Is it Xml file or a code?
Cause it would be easier if outerra engine could just read Xml file (with road vector data) from one of it's root folders.
Then anything that is done in external editors (with some conversion to outerra format (xml structure)) could be easy just to drop in folder, that will be loaded in next outera startup.
And whenever road adjusted within outerra engine, it would just correct the xml file.

It would be useful to have a tool that extracts external vector definitions, getting rid of unused stuff and partitioning it into smaller tiles so that our tool can process it easier and from a cleaner intermediate format.

Looks like OSM all the vectors are named, and it should be quite easy to pick up just one that's needed (using a script). That's what I've originally planned - I know how OSM xml looks like, but I don't know what's outera accepts, therefore don't know to what format to convert those xml's.

Btw why not to add those roads and airports into OSM?

Already did some contribution to it. Only if anybody will want to make his own road or city (for example medieval city) , that doesn't exist in real world, then OSM can't be a solution. And external 2D editor could be very useful. Again, many of them exist already, just need outerra to read xml's.


Sorry if I'm wrong about Outerra vector storage way. If it already does (reads) it in kind of XML, then much of what I'm said is out of date
that's what I'm trying to find out.

[cameni]

Right now there's just a kind of cache that keeps the roads (see cache folder in data dir). The file format is binary, because it's directly loaded to GPU buffer and accessed from the shaders. The roads are partitioned into tiles, but these tiles don't correspond to any usual tiling schemes used in mapping.

Roads in these files are also manipulated by the road editor, which can chain together the segments divided into multiple tiles and modify the road, writing the partitioned binary data back. However, this representation is not (yet) stored anywhere, everything operates on the binary representation.

[deathevor]

is it possible to have this external converter (form xml to binary data), as it already exists inside engine. So certain xml structure get's converted to binary and added to this cache file?

[cameni]

It does not convert from XML, there's an interface through which the way points are created from latitude, longitude and altitude and road parameters. Mouse clicks in road editor are first converted to lat/lon etc and then the function is invoked to create a way point.

In the same way an importer from external data would process all roads within a region by feeding its waypoints to the engine, that would process it into data needed by the road processor. The importer could go over some files and feed the waypoints to some converter tool. However, the process would be much speedier if the mapping tool processed external tiled source of XML (or whatever) data in batches, just as the mapressor tool currently processes the elevation data.

Hmm, it could be a hybrid process - the mapper queries a registered plugin provider of data (just as there are providers of elevation data in mapressor) to get data for given tile. The plugin would then read XML or any other format it uses and load the road definitions through the API. The mapper then can continue compiling the pre-cached data in an effective manner. This way the process can be both fast (cache friendly and operating on batches) and support a variety of sources via the plugin system.

[deathevor]

Sorry that I wasn't clear in my messages. Yes, when I meant XML I just was talking about waypoint info (latitude, longitude, altitude and road parameters). But stored in external file - that's why I always mentioned XML, as it is simply to read and modify (and it's very common).
In more simple words, the mouse clicks you have mentioned, are done automatically based on data from external file (in this case XML).
The rest already exists in outerra - it converts waypoints to road tiles.

As I understood your last paragraph correctly - then it is a thing that I was talking about.
I also think that there should be a chose of providers - like an option to switch on/off OSM. Instead (if user wants) it can only get data from XML's  stored in local folder. That's in case if user did for example a racing road in external editor and just want to load it in outerra.


!P.S. After the XML is loaded and converted to waypoints in outerra, it would be nice if any changes done by user in Outerra (for example position or width of road change), do changes to XML file.
This way it will be extremely easy to do any corrections to data.

[deathevor]

Just got another idea (but still on the same topic)

If users will do an accurate roads, forests etc. in outerra or external editor (but local) - Outera can have an automatic export (upload) of data to OSM.
Basically if any of users did local vector changes to outerra and want to submit it to world, he can do it by submitting it to YOU (just a button inside outerra, that sends XML to you), and you (if you agree with user changes) submit it to OSM.
It's a way of submitting contributions to Outerra engine.


Based on all above:

If user submits a 3D model for Outerra with it's correct coordinates. Outerra can also submit the contour of the building to OSM.

[cameni]

!P.S. After the XML is loaded and converted to waypoints in outerra, it would be nice if any changes done by user in Outerra (for example position or width of road change), do changes to XML file.
This way it will be extremely easy to do any corrections to data.

A bidirectional import/export would be more complicated, and not always possible as there's a loss of information when converting to OT. Anyway, I think it would be reasonable only if there was a goal to make some kind of 3D OSM viewer, effectively competing with Google Earth and similar software, which is not our aim at the moment. OSM road import will be an experimental feature, I think there will be a lot of issues with it. It should be easy initially but there are details that will make it more complicated.

For now the goal of OSM import is to help building the civilization layer and populating the world with structures, for games/simulators/apps that want to use it. If it works sufficiently well, we would use it for Anteworld to get a network of old decayed roads together with city ruins, given the Anteworld's setting. I expect it will get more usable over time, and when we proceed with making a global simulator platform we will be able to use it there.

The idea of a bidirectional i/e with OSM flew through our minds some time ago as well, but the road tools in OT must become far more advanced for it to be usable. Until then it would be better to perform the edits in OSM and reimport in OT.

As for the intermediate format from which the roads and polygonal land class areas are imported, it could be anything. We usually don't use XML as it's not quite human readable, and not suitable for stream-reading, but I guess it's not that big problem and people are used to it for interoperability reasons. Another option would be JSON.

[deathevor]

Thanks for info. Looking forward to OSM road import.
As mentioned before, would be nice if this import would be automatic, the same as it made now with elevation data.

[Bromstarzan]

This thread is of interest to me I guess, since I am also eager to find a way to place vector data (roads, rivers, vegetation patches, buildings etc) on top of the DEM. Not just by manually drawing the nodes, but actually import for example a GIS shape-file.

I guess it is possible with some transformations/conversions but at this stage I take it there is no "easy" way without digging into the binaries? The point is that much GIS data today is freely distributed and accessible. Just to have a tool that was capable of placing *.shp files in this awesome earth engine would blow my mind

Good luck with the development, I'll check for progress as time goes by.

[cameni]

Right now there are just spline-based roads, support for more vector data types will be coming too.

Integration methods - the priority is to be able to integrate these data seamlessly on all detail levels and with naturally looking transitions. Internally these vector data have to be extended to include additional data like transitional areas that define how one type transitions to the other or to the original terrain, or auxiliary attributes like river profile/depth. These data aren't usually present in GIS files as the mapping usually deals with discrete 2D representations, but in OT the terrain generator is driven by probabilities in order to produce those natural transitions from one land/vegetation type to another, or even to generate an arbitrary degree of decay into the natural state. The import will be a bit more complicated because of this; I guess some heuristics will be used to augment the imported data. With in-engine tools it should be later possible to adjust also these hidden variables.

[Bromstarzan]

I understand this huge task of transforming (or terraforming) a 2D line (node to node) representetion into a seamless 3D (and nice looking) virtual reality. It is massive. I work with a mix of 2D and 3D data and obviously there are problems everywhere when it comes to GIS-data, since it's different formats are very dynamic, hence the lack of standards.

I am currently focusing on interpolating soildepths between rock outcrops using various mathematical methods, but also sediment-coring for controlpoints (to "hang" it up on). It relates a bit to what you describe for the river profiles - the lack of water-depth data. For rivers, my solutions have been based on setting a constant maxdepth based on the surrounding soiltype. Slope/bank angles can then be computed using erosion rates for that particular sediment type in conjunction with parameters describing the channel shape (perimeter, cross sectional area etc). It's a simple but very effective way to come away from expensive radio echo soundings and laser scans.

As you say, it complicate things when importing 2D surface shapes and in the process we want to turn them into "nice" looking 3D. A nice challenge though. If I see (later on) that I can be of any help I'll let you know. I'd be happy to contribute, time allowing, as both a geologist and terrain analyst/modeller.