2.14beta Sandworm origin suggestion


photo

Recommended Posts

Hello,

Currently, the sandworm geodetic origin is computed as the "center" of the database. This as the drawback that the origin of the terrain can shift every time the tileset changes and the landscape is regenerated. And then, the terrain would be offset from any previous custom layer (considering the projection would be the same of course).

I would suggest you offer the possibility (not mandatory) to set the geo position of the origin of the landscape in Sandworm, so every time the terrain is generated, whatever its extent, then the geo origin would stay at the same x,y,z=0,0,0 point.

As a bonus, maybe you could also select the X,Y,Z position of the geo origin (so for example we could choose to have the default 0,0,0 or the projected coordinates of the selected geo position, for an easy way to position object in the Editor)

Thanks!

Link to post

I second that, working with third party generated tiled objects (ie procedural generation from CE, or photomesh) which are georeferenced and exported in a certain projection with a reference origin (usually the same as the database in unigine) becomes tedious if the extent of the database changes over iterations, as it forces to regenerate all external data with the new unigine center every-time as new values for the offset in current projection. I think it should be settable directly or with the use of  reference point in an shp.

Link to post

Hello!

16 hours ago, Amerio.Stephane said:

I would suggest you offer the possibility (not mandatory) to set the geo position of the origin of the landscape in Sandworm, so every time the terrain is generated, whatever its extent, then the geo origin would stay at the same x,y,z=0,0,0 point.

We are on the way to implement that feature and it can be expected in a following release. Thanks for suggestion!

Quote

As a bonus, maybe you could also select the X,Y,Z position of the geo origin (so for example we could choose to have the default 0,0,0 or the projected coordinates of the selected geo position, for an easy way to position object in the Editor)

As for this part we didn't quite understand what you mean. Stephane, maybe you could do a rough sketch with a visualization of what you want, please? This would help us better understand what functionality you want to see.

Thanks!

Link to post
Posted (edited)

Something like this maybe:

image.png.f65c41f6bc1047ea3338eda08e5bc738.png

If "Set Origin At World Origin" is pressed, then the X,Y,Z will be set at "0,0,0".

If "Set Origin At projected 2D Coordinates" is pressed, then the X,Y,Z will be set at "<projected value for geodetic origin>".

Eg for 43.43N5.22E origin and EPSG2154, it would set XYZ=6092322.18, 3060864.17, 0

This would allow for an easy positioning of nodes in the Editor knowing their geodetic coordinates. If you think the projected coordinates may be too large, maybe add an option to scale them down (*0.1, *0.01, *0.001). Again, this is just so positioning an object is easy, and above all stable between terrain regeneration.

Thanks!

Edit: after thinking about it, the (*0.1, *0.01, *0.001) part is stupid because just the origin would be scaled, not the other coords. But the rest stands. Of course, you are the better judge here :)

Edited by Amerio.Stephane
  • Like 1
Link to post

Hello!

@Amerio.Stephane, thanks a lot for your mock-up, the first part of it was already implemented successfully, and from now on the location for the origin can be defined manually or calculated automatically:

изображение.png

I also want to mention that your suggestion caused a huge discussion, and we want to clarify some issues that were risen in its course.

In fact, the second part of your mock-up implies adding the functionality that would help to place nodes by moving the whole terrain, but we plan to implement a "placement tool" that will allow setting coordinates for any selected node in accordance with the world origin or a selected projection.

And here is the question: knowing that such a tool will soon appear in the Editor, will you still need the functionality that you pictured in your mock-up (the lower part)?

Feels like you probably want to be able to have the previous workflow, which was in release 2.13.0.1, where the LandscapeTerrain after generation was far away from 0,0,0 and its coordinates were something like X = 6092322.18 Y = 3060864.17, then you transformed the Lat Lon coordinates of the required node and could accurately position it by specifying the XYZ values in Editor on the Parameters tab.

Is our guess correct?

Then in 2.14 beta release we've introduced the concept of the origin and now you have difficulties with placing nodes, because the terrain no longer has the same coordinates as it was before. The center of the terrain has coordinates XYZ 0,0,0 but nodes still can be placed easily if you transform Lat Lot coordinates of the origin and then subtract that value from the coordinates of the node.

Here is a raw example:

Let's say, you want to have the origin set to Paris Eiffel Tower which has the following geo coordinates 48.85834395290128, 2.2944772967737452. Transformed to EPSG:2154, that will be X:648235.58 and Y:6862265.46.

And as an example, your node is "Orly" Airport 48.7271014806416, 2.3616007938875256. Transformed to EPSG:2154, the coordinates will be X:653075.75 Y:6847634.94.

Spoiler

coords.png

Then we subtract the XY origin value from the XY node and receive the X and Y values equal to 4840 and -14631.

As we set the specified coordinates for the selected node in Editor, it is located exactly in the required place with the selected projection EPSG:2154.

изображение.png

 

 

 

  • Like 1
Link to post

Hi,

6 hours ago, bmyagkov said:

we plan to implement a "placement tool" that will allow setting coordinates for any selected node

This would be great. Keep in mind that we need :

  • to be able to set the position of an object with a geo loc (lat,lon,alt)
  • AND to be able to tell the position of an object already in the world.

The 2.13 implementation with TerrainGlobal+GeodeticPivot fills both criteria. It would be great if the visualization/edition of the geo coord could be done independently of the node hierarchy position, and also visible in the NodeInfo debug overlay.

We don't really require the projected coord, the geo coord are enough, so if we have the mean to do that, the part two (lower GUI mockup) is not needed.

Yet, having the projected coord in addition to the geo coord would be a good bonus (but not mandatory)!

Hope all is clear, and thanks again for the dedication you put in understanding your customers!

 

 

  • Thanks 1
Link to post