Jump to content

height data interpretation in Unigine


photo

Recommended Posts

Hi all, has this issue (height discrepancy between source data and gpu terrain mesh at LOD0 (finest)) been fixed in latest releases, with new implementation of sandWorm for instance? by the way, I've artificially increased pixel width resolution of source data (altimetry oversampling at 1m, 0.50m and even 0.25m, and discrepancy seems to decrease but is still here (at least size or double of source data pixel width in Z difference, how weird is that...) As a workaround, oversampling pixel density of source data does't seem to be viable (still some differences and huge source files ) 

Thanks for feedbacks

Link to comment

Hi Romain,

Sandworm tool can generate final results without applying any additional projections, so in theory you should see what the files contains.

The devil may be hidden in the approximation algorithms that calculates the final heights between the pixels (especially if you have very low quality data 30-50m per pixel). In that case I guess we can't do much about it.

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

Hi Silent, ok, so for the moment if source height is very low res I oversample it to 25cm per pixel (tiled etc), this improves things a lot up to an approximation epsilon somehow around 50cm. Lowering data to 1cm per pixel doesn't show any more improvements. So I process things a bit differently in CE in order to take this threshold into account.

But I'm thinking more generally, do you think it could be possible to extend the terrain building process to constrain the dynamic terrain mesh triangulation with linear/point vector data (having Z values)  in addition to building it from rasters only? I guess it could be an extension of how area features are handled within the 2.5D building process (here Z values are draped correctly on terrain Z)

Link to comment

Can you show us an example of such vector data - how does it look like? What we think would be interesting to try is to adjust the terrain height based on the data from the separate buildings, so every house would be located exactly on the terrain. But it may look weird when difference between raster data and vector will be too big.

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

in fact this is directly inspired from how things are done in some GIS tools like FME for instance : surfaces can be constructed internally from raster cells + 2.5D vectors (meaning any area, point or linear having xy+Z values on vertices), the surfaces are built with a xy tolerance (or pixel width) + a Z tolerance; of course this construct TIN, or constrained delaunay triangulation, so for example if you have a crest line with fixed Z values say a linear vector where vertices have fixed Z values, you can get it and keep it all along the lod switching, don't know how it could fit in the regular grid paradigm. 

Another insight would be to do what others do with rasterizing vector data at a xyz tolerance. For example in globale mapper or Qgis, or other proprietary engines, you can rasterize vector data at very fine res and blend those tiny rasters with some linear ramp with any underlying low res elevation raster, the process is: - sample height of each vertices with the height field beneath if Z is not given (or use the Z values if there known (ie precise survey)), and build a new height raster at a very small per pixel resolution, to be sure it captures all Z details and do not approximate values (like what you talk about 30m versus 1cm resolution). Here in Unigine the process could be dynamic, meaning building some small rasters at adequate resolution around inserted vector vertices and linearly interpolate with other layers. Of course like what you mentioned, result can be weird if difference is too big (large ramps around features), but if tolerance values are exposed and controllable by the user. Advantage of this method is that extra detail or accuracy is done with vectors (lightweight), eventually it also could be extrapolable to lidar.

Link to comment
  • 8 months later...

Hi, resurrecting this old thread, while I'm still fighting with Z discrepancies between terrainGlobal (the old one) and source data at "low" densities usecase (can't oversample data in this case). So i'm trying to figure out how things are being evaluated for my info..

So I tried just to verify using the simple 2.5D building feature in landscape tool (again georeferenced, curved, geodetic pivot etc), in order to see if they are generated "on" the terrain skin or not and what would be the logic here as they are not generated on the fly. Problem is still the same footprints base are always under or above terrain skin:

image.thumb.png.6a804d5e0c3d596ac6d72d32b5ec8181.png  

or

image.thumb.png.047c6a8d3777d7465edbb6f26c3a20cf.png

at least at minimum elevation lod(0):

image.thumb.png.0baf018c6096bbfbe094543dadba27cb.png

image.thumb.png.c3c242fb1a85e47bf5ab6647591ab5fd.png

but in reality getting their elevation somehow from coarsest Lod 

image.thumb.png.5cf167d0be1d981aaa49e48251b45480.png

So question is where the 2.5D buildings get their Z values from internally with landscape Tool ? (input elev rasters ?, terrainGlobal ?) And then would to it possible to fix the issue, so these would actually always be above (even if flying, ie on vertex at minimum is on terrain skin)

I'm asking all that in order maybe to find a clue on how to workaround the Z discrepancies (again not related to landscapeTerrain and working in a flat projection all way which does not have this problem with high res elevation sources) while importing large tiles of external buildings.

I guess one of the solution would be to actually make a mesh out of the lod0 terrainGlobal and save it as input data for my other tools, reason why I asked that another thread.

Thanks for some info about this.

image.png

Link to comment

Hello!

We think that the issue can be solved much easier. The problem is that the Landscape Tool was always used sources height data for placing object where Sandworm tool get elevation position straight from generated terrain object (ObjectTerrainGlobal or ObjectLandscapeTerrain no matter) and cause of this prevents distortion from curved state since all calculations are done after the object has been internally ready.

So, It turns out that it will be enough to generate a project just using a new Sandworm tool to solve your problem.

Thanks!

Link to comment
  • 6 months later...
×
×
  • Create New...