Print

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

[deathevor]

So where are they (roads/vectors) stored?
Is it possible to modify these files from outside of Outerra?

roads.bix?

[deathevor]

Request a converter - Vectors to Road.bix (and Object.bix)
Basically if it even will be converter from your own vector format - but human readable.

[cameni]

Yes, roads.bix. However, these data are compiled for direct GPU usage and will change when the internal format changes. Plus the indexing scheme makes it totally unsuitable for direct modification.

Working on an importer API that will allow writing plugins for import of vector data. We'll try it first on the OSM roads, but then it will be possible to write a custom plugin for any format you want.

[deathevor]

Something like:

For Roads:

Road 1 -  texture, etc
x, y, z, <gizmo settings>, width,
x, y, z, <gizmo settings>, width,

For Objects:

x, y, z,  rotx, roty, rotz - model name.


Theoretically, you have this converter built in Outerra already. But would be nice to have external, even console converter.

[deathevor]

Make sense if you changing your internal formats , then probably no reason to make it this way.

Just was assuming that on button Make (road) pressed, the outerra was reading point positions and creating road based on them.
Why not to use the same creator, but from point positions in file (as source) .

[cameni]

Just was assuming that on button Make (road) pressed, the outerra was reading point positions and creating road based on them.
Why not to use the same creator, but from point positions in file (as source) .

Exactly, the importer API will expose the same functionality that is already there for manual waypoint placement. It won't be a new format, but an API through which the entities can be created from script or from other data formats via import plugins. That makes it much more universal. The API will enforce certain usage pattern (a tiling scheme) to achieve a good import performance.

[deathevor]

Another question - what about deleting roads?
(the same with Exporting them)

[cameni]

Deleting via the IAPI, you mean? Normally the import is meant to go into a new, separate layer, and the old version of that layer will be removed. It's expected that you'll be doing the management of roads in your files & format (deleting, moving, whatever) and then it gets cleanly imported into OT into a layer that can then be enabled in OT.
While there's a possibility to perform these modifications in OT and then export the data back via the API, such a cyclic operation has a great potential to end up in a mess and conflict havoc. But technically it is still possible.

What is more problematic is if you wanted to import into an existing layer, while also deleting some old roads during it. That's because, as I wrote, the data are prepared for direct access from the GPU, and as such they are partitioned in OT world tiling scheme. That means that a single road that you define during the import (or when manually creating the road) may end up partitioned in several files, as it crosses several of them. Deleting a road would mean tracing it in all of them, but right now the data do not contain any unique id of the road that would associate it with the imported vectors, and allow you to specify which one to delete. But I'll be reworking the format and will probably add some uid into the extra nodes there, not primarily because of the import but to be able to use the identifier later in the game/sim code. Then you'd be able to do the deletions as well, as long as you know the uid of the road you want to delete.

I guess the concept of multiple layers where the data can go (stored in their own folder, enabled/disabled as needed) answers also the Midviki's question, though I'm not at all sure from that description

[deathevor]

How quick would be to convert, would say, vector data of whole Europe roads to Outerra roads?

The reason I'm asking is to offer following structure:

Originally have 2 separate road storages:

1) Vector
2) Outerras (GPU ready roads)

So the relation is following:

1) Vector data used for modifications - importing new layers, editing existing ones, deleting layers, deleting selected vectors, selecting and exporting layers and parts of vectors. (All this outside of outerra, but will explain what happens inside later).

2) If the convertion is reasonably quick (or speed can be achieved by partitioning the conversion process) then-
As Outerra starts it checks for any modification done to Vector file. If such exists it checks the region of modification - deletes (GPU ready) roads from this region and generates new one, based on vectors.

(Additionally if Outerra is running already, would be helpful to have "refresh roads" button.  Does the same as on start)


Now second part: Modifying roads in Outerra

When user opens dialog for road modification, he is not modifying GPU Ready roads.
Instead he is presented with vectors from Vector file (as it does now with yellow lines) for region he is modifying.
With other word's user temporary has Vector visualization in Outerra. Visualized as lines. (This what happens now, when yellow lines modified).

Basically each modification is direct change in vector file. And after it's done (and saved), again refresh is happening - No2 (mentioned before).

Layer support is additional of course. But this way it is easy to track changes, modify, delete anything. As the only trustable and main source is vector file.  Which in case of update is converted (only partially , as needed) to Outerras format.


If the process is not reasonably quick, then no automatic updates - just a refresh button (External and internal) which will keep user aware of loading process.


Hope it make sense

[cameni]

What kind of use are we talking about?

I doubt it will be fast enough for interactive editing through an external vector file. Here's how quick it is when processing the elevation data:



Sure, vector data import & partitioning should be faster, but routing the edits through an external format and reimporting back when you just want to move road a bit .. that's not the right way, latency and all.
The goal is to import an existing global (or large scale) database of vector data into OT to make a rich world, not to use OT as a GIS app (at least not initially). Even if it was, it would be better to let it operate on its internal representation, and then to have it export the world back to whatever format you are using through the same plugin that was used for the import.

[deathevor]

I doubt it will be fast enough for interactive editing through an external vector file.

A bit misunderstanding.

The roads in Outerra ARE (looks like they do) modified now as vectors. I mean in the process of modification (of yellow path) they (GPU roads) don't re-render.

Here's a question - after making a road and restarting outerra, You can still select this road (as yellow path)- so what do you actually select?
"A vector that is created and saved along with GPU road" or "you temporary convert Outerra road back to vector (yellow path)"?

I've made this conclusion (that it's saved as vector or spline or whatever) as after selection you don't modify road, you modify yellow path, and after pressing "make"it converts to GPU road.


So what I was talking about is, that to have road vector file that is always updated (on any modifications done in outerra). But reverse direction (Vector->Outerra) only synced during Outerras start, or when Refresh button is pressed).

The speed that is shown on video is definitely fast enough to do those syncs on start (or refresh).
So it's not live, it's jut like link update.


The benefits of this, is that user even after modified the road inside outerra (the Vector file is automatically updated as user does modification inside outerra), can switch to external editor, click refresh there and see updated roads. Do the modification in External soft->save. Jump back to Outerra, click refresh and (converter determines what block was changed, and converts vectors to Gpu roads - overwriting whole block) see all road updated.
(Unmodified blocks stayed the same. Modified block - old deleted, new taken it's place. And fully represents (the same as) the vector file.

[cameni]

There's an intermediate buffer that keeps the waypoints of a single path, before they are committed and compiled into road segments suitable for the terrain road generator.

When you click on a road, the buffer gets constructed from the internal tiled representation of road segments, together with an auxiliary index that holds which tiles and which segments make up the road. When you modify the road, these segments are removed and new ones created in their place. All editing happens on this representation; there's no global shadow copy of roads as vector paths: the path is just a complex symbolic reference to the underlying tiled scheme, and you can only commit it or delete the segments it refers to.

Hmm, but to support what you want to achieve, these commits or deletes could be sent as events to the import plugin API to keep the external database in sync, should the plugin support a write-back to the source data.

[deathevor]

Sorry, gets complicated, have few question so not to loose the point:

"internal tiled representation of road segments" -  is it:

1)shadow copy of roads
 or
2) final GPU road?

If 1 then

   I offer to store it as easy editable (from outside) vector database.
   Then you actually modify the same file from inside and outside.
   And all that's left is ONCE (on start or on refresh) bake them as Final GPU roads.


If 2 then

   as you've said - keep database synced.
   Then external changes are done to database. Later baked (on start or refresh) as GPU roads. - overwrite existing tile.
   If internal changes made then changes sent to external database (to keep it in cync) and roads baked as Gpu roads o the press of make"button.


!!!The most important here, in both cases, is that any sharing, layers, copy pasting is done at database.
(and preferably to have Database as human readable file - like collada)
So the database hold layers, hold their state (switched on or off), maybe hold UNDO's.
(even modifiers - like thickness, texture , noise)

This way users can access this data, modify it even from notepad. Program their own soft for modifying it.
And especially copy and share.

Database is a mess that is kept away from constant access (loads). But it's a mess that have all the existing roads in Outerra + All layers that is switched off.

The Outerra itself runs as always, like now, loads only GPU ready roads. And only Refreshed.


Additionaly - Outerra might have switches for layers in database. So some menu shows what layers exists in database - you tick necessary ones.
Then press "refress". Again GPU roads gets updated (Overwriten).



P.S. Keeping the database this way (as server) will also make Outerra more independent from this database. If file gets corrupted, outerra still runs with roads that were baked previously. Probably you can also recreate database from baked (GPU roads) roads (if correct option was 2 in the beginning of the message)

[cameni]

"internal tiled representation of road segments" -  is it:

1)shadow copy of roads
2) final GPU road?

I said there's no shadow copy, so it's the final GPU road. Besides, the layers in your database are not the same as layers in OT. Whole your db normally goes into one layer, OT roads aren't meant to handle all features a GIS system may want at that low level, it's just a flat data layer.

If it's copying and sharing that you want, you can distribute the compiled road data as well, they will be in a separate folder as a layer. Anyway, I believe that the plugin system that handles the commits and deletions and synchronizes the external database can be used for what you want.

[MrNobodyX3]

So can you import roads?

If so, where can I get some? I was looking for at least the US & CA region