terrainLayer and displacementmap

[urmjs]

Hi Robert,

d48e481

Post this commit, have there been any developments to add terrainLayer to the vsgTile example. May I know what needs vsg::Tile is missing to make it suitable for the displacementMap. Thanks.

Ramji

[robertosfield]

I don't recall off the top of my head. I'm just wrapping up some work camera animation, once that's checked in I'll be doing some further work on vsg::TileDatabase and as part of the work will check up on the status of the terrain layer support. Should have answer for you by the end of this week.

[urmjs]

Look forward to it. Thanks

[robertosfield]

I'm now working on the evolution of vsg::TileDatabase node and the associated vsg::tile ReaderWriter, I am still working on the possible new approaches to for generalizing the functionality to handle multiple layers.

I have checked the existing vsg::tile ReaderWriter code and the implementation is currently hardwired to just using the TileDatabaseSettings::imageLayer and ignores the terrainLayer field. To support the terrainLayer field several of the internal methods in the vsg::tile will need to rewritten to both read and apply the the terrainLayer when/where required, this is not a huge amount of work, perhaps just a couple of days work.

However, generalizing the vsg::TileDatabase/vsg::tile to handle multiple layers will likely require a wider refactor of this functionality so there isn't any point in tweaking the existing implementation to support the terrainLayer field as it'll just be deprecated by the more general functionality, and the new functionality should make it easier to add in support for terrainLayer in a more flexible way.

I'll provide info to this forum as the refactor of vsg::TileDatabase & vsg::tile progresses over the next week or so.

[urmjs]

Thank you for the update.

If I have understood right, the refactor will aim at adding the capability for vsg::TileDatabase/vsg::Tile to support multiple ImageLayers and multiple TerrainLayers, as against the current implementation which is only capable of a single ImageLayer.

[robertosfield]

The refactor will aim to support multiple image layers and I had assumed a single terrain layer. I haven't yet figured out how flexible a scheme to implement. I may start with just simpler extension of the existing scheme.

[urmjs]

single terrain layer would be most appropriate. I was only trying to ascertain and be sure if I had understood right.

[robertosfield]

Work is progressing on the refactor of TileDatabase, there is now support for a TileDatabaseSettings::detailLayer which is working, and prep work for TileDatabaseSettings::elevationLayer (renamed from terrainLayer) is done but...

When testing the ReadMap elevation data I found out that vsgXchange's tiff support I found it's wholly reliant upon GDAL and vsgXchange::GDAL doesn't yet have support for reading from istream which is used by vsgXchange to read http using libcurl. I've been investigating how to get GDAL to read from a memory buffer and have ended up down a virtual file system rabbit hole. My initial test code suggests this route is viable and have data reading and rendering but the elevations aren't correct yet.

After Christmas I will tinker with it further and hopefully get vsgXchange::GDAL working with http data and the shaders updated to handle the displacement mapping, or change the vsg::tile ReaderWriter to create meshes based on the DEM textures.

The work in progress on TileDatabase can be found in the VSG branch:

https://github.com/vsg-dev/VulkanSceneGraph/tree/MultiLayerTileDatabase