Replies: 16 comments 13 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Look forward to it. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
single terrain layer would be most appropriate. I was only trying to ascertain and be sure if I had understood right. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Look forward to it. This will provide more comprehensive support for terrain |
Beta Was this translation helpful? Give feedback.
-
|
The vsg::TileDatabase changes will provide "more" comprehensive, but I would caution expecting too much, it's still not comprehensive, not do I ever expect it to be. Terrain is a huge topic with lots of different ways of tackling it, a number of which are supported by the VSG via database paging, of which TileDatabase provides a simple example of, more sophisticated examples are provided by Rocky and vsgCs. TileDatabase is really just meant as a simple entry into reading well constrained image and DEM tiled datasets, rather than a general purpose solution. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
The vsg::TileDatabase now supports base texture and detail texture support as well as support for displacement maps. Changes have been in the VSG since around January. I don't know what you are referring to by "3d Earth visualization inside vsg is the port to the new FlightGear...". I haven't kept track of the status FlightGear project so have no idea whether they have experimented with porting to VSG, let alone how they might be going about. |
Beta Was this translation helpful? Give feedback.
-
|
I tested the last commit. The problem is that the vsgtiledatabase sample works great but the dem data is not used (Mountains are flat). It does not save the dem tiles in the cache address either. |
Beta Was this translation helpful? Give feedback.
-
|
P.N: In another try, I also used a hackish way to use a local folder instead of url for the map address, I was successful but it takes time if I am connected to internet before it times out and reads data from my cache folder. It would be best to support an address format like: file:// or local:// for local addresses. |
Beta Was this translation helpful? Give feedback.
-
|
What do you see when you run: vsgtiledatabase --rmeThis is what I see:
What value add would it add? Adding a prefix when none is needed would just require loaders to remove the prefix before they can do anything. The http prefix is enough to alert the vsgXchange::curl that files are a location that requires it's services, this worked fine for OSG for decades. I really can't see any need or value in making things any more complicated for the VSG. |
Beta Was this translation helpful? Give feedback.
-
|
What a beautiful scene... I see this, everything is flat: And here my debug info: $ ./vsgtiledatabase --rme --debug Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 Validation Error: [ VUID-vkCmdDrawIndexed-viewType-07752 ] | MessageID = 0xce261924 |
Beta Was this translation helpful? Give feedback.
-
|
Could the problem be with the shaders not being recognized or ...? |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps it is a shader issue. The pre-compiled ShaderSet that are integrated into the VSG don't include displacement mapping so that is enabled in the set up of the shaders and the shaders will then need to be compiled. Check to see if the VSG has been compiled against glslang. The CMakeCache.txt will list the optional parts that are compiled in, and the include/vsg/core/Version.h will list which features are compiled in. This is what my include/vsg/core/Version.h looks like, with VSG_SUPPORTS_ShaderCompiler automatically set by CMake to 1, #define VSG_VERSION_MAJOR 1
#define VSG_VERSION_MINOR 1
#define VSG_VERSION_PATCH 11
#define VSG_SOVERSION 14
#define VSG_VERSION_STRING "1.1.11"
#define VSG_SOVERSION_STRING "14"
#define VSG_API_VERSION_LESS(major, minor, patch) ((VSG_VERSION_MAJOR < major) || ((VSG_VERSION_MAJOR == major) && ((VSG_VERSION_MINOR < minor) || ((VSG_VERSION_MINOR==mino
r) && VSG_VERSION_PATCH < patch))))
#define VSG_API_VERSION_GREATER_EQUAL(major, minor, patch) ((VSG_VERSION_MAJOR > major) || ((VSG_VERSION_MAJOR == major) && ((VSG_VERSION_MINOR > minor) || ((VSG_VERSION_MI
NOR==minor) && VSG_VERSION_PATCH >= patch))))
/// maximum number of logical vkDevice supported
#define VSG_MAX_DEVICES 1
/// Instrumentation level to built into the VSG library, 0 for off, 1 coarse grained, 2 medium, 3 fine grained.
#define VSG_MAX_INSTRUMENTATION_LEVEL 1
/// vsg::ShaderCompiler support enabled when 1, disabled when 0
#define VSG_SUPPORTS_ShaderCompiler 1
/// vsg::ShaderCompiler optimizer support enabled when 1, disabled when 0
#define VSG_SUPPORTS_ShaderOptimizer 1
/// Native Windowing support provided with vsg::Window::create(windowTraits) enabled when 1, disabled when 0
#define VSG_SUPPORTS_Windowing 1 |
Beta Was this translation helpful? Give feedback.
-
|
Yes I did compile with glslang: $ glslangValidator --version CMakeCache.txt seems OK:
And my version file is located at /usr/local/include/vsg/core/Version.h with exact same contents as yours. |
Beta Was this translation helpful? Give feedback.
-
|
I should mention that I have successfully run vsg-dev/MyFirstVsgApplication with lz.vsgt and worldviewer with cesium-ion |
Beta Was this translation helpful? Give feedback.
-
|
OK, that suggests that shader compilation is not the issue. The Vulkan debug error is curious, the VK_IMAGE_VIEW_TYPE_1D report for what should be a 2D type is curious. No idea what might be causing this. I don't seen any errors like this on my Kubuntu 24.04 + Geforce 2060 system. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I will test on more systems and report back. |
Beta Was this translation helpful? Give feedback.
-
|
It seems that I found the issue. My vsgXchange does not support tiff. Overall, I didn't had time to say thank you (and probably your other team-mates) over the years I have used osg and now vsg. |
Beta Was this translation helpful? Give feedback.
-
|
Glad you got to the bottom of it. The vsg::tile ReaderWriter that is loading the tiles from the remote servers and building the scene graph for them should emit a warning if the file type isn't handled, I'm surprised I didn't implement this already. I'm away from from machine this weekend so attempt adding anything. Could you Issue for it, so we know that it's an problem that needs addressing. A non GDAL based tiff plugin would probably be helpful too. I'm not the one able to add functionality so please feel free to dive in add missing bits. |
Beta Was this translation helpful? Give feedback.
-
|
By the way, It works like charm on my pc, but on a rk3588, I get memory leaks(even on osm map with lightings and dem turned off). Is it VSG or maybe the mali driver? Do you think if the problem is solvable? P.N>: Unfortunatelly in the rk3588 device, I get unrecognized instruction using valgrind. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not familiar with rk3588 device, could you provide more context. What makes you think you have a memory leak? As for an unrecognized instruction, the VSG doesn't contain any machine code so if there is an unrecognized instruction it'll be the compiler or lined library that has the instruction that valgrind isn't recognaizing. This "might" be a compiler bug, but I'd more suspisious of an issue with valgrind not being up to date with all the instructions supported by the hardware and generated by the compiler. |
Beta Was this translation helpful? Give feedback.
-
|
This is 8-core 64-bit arm cpu with 4GB of RAM and Mali-G610 gpu. If I move the scene, the used memory goes up to 4GBs (full system ram) and the model gets heavier and slower until the system crashes in a minute or two. If I keep the zoom very low(seeing the whole earth inside the view) the ram does not grow. It is apparent that the unloaded tiles(or textures?) remain in the memory. If I don't move the scene, the memory remains fixed. Also I do not have this problem in other examples like MyFirstVsgApplication. Some years ago, I used to have same kind of problems(memory leak when unloading a osg object) in the odroid XU4 with osg, which I could not solve either. |
Beta Was this translation helpful? Give feedback.
-
|
I do not get a cue using the --api or --debug modes. I get no continuous errors. valgrind ./vsgtiledatabase --rme |
Beta Was this translation helpful? Give feedback.
-
|
There could be a bug in the driver. On the paging front, the DatabasePager is designed to load balance using a target maxium number of PagedLOD. If the individual tiles are larger, such as when you have elevation and image data then you may need to use a lower target, if the hardware is memory limited then again using a lower target will also be required. The vsgviewer example and a few other examples support the --maxPagedLOD command line argument which you can use to set the above limit. This is how vsgviewer passes the value on to active DatabasePager: if (maxPagedLOD > 0)
{
// set targetMaxNumPagedLODWithHighResSubgraphs after Viewer::compile() as it will assign any DatabasePager if required.
for (auto& task : viewer->recordAndSubmitTasks)
{
if (task->databasePager) task->databasePager->targetMaxNumPagedLODWithHighResSubgraphs = maxPagedLOD;
}
}There is also support for adjusting the level of details selected for a given viewing distance, but I can't recall the exact API off the top of my head so will have to look it up when I get back to work and at my desktop system. |
Beta Was this translation helpful? Give feedback.
-
|
Some people from rockchip checked the problem and told that this is not a driver issue: From valgrind summary, can see lots of "still reachable". By comparing memory profiles at different times when the program runs, Means a large number of VKImage and VKBuffer were applied for by the program but were not released in time. mem_profile_5min_later.log |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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
Beta Was this translation helpful? Give feedback.
All reactions