vsgCs help!

[ComradeMashkov]

Hi everybody. I know that it is VSG Discussions topic but listen me out.
I find VSG perfect library for my purposes and it works just fine. However, recently I had a look at timoore vsgCs library, which implements cesium-native to VSG. I have some errors when building this library and since I had no answer on vsgCs Discussions I'm begging for community support here.

Here's my error when trying to compile vsgCs:

 error C3668: 'CsApp::CsViewer::advanceToNextFrame': method with override specifier 'override' did not override any base class methods [C:\Users\ilya.mashkov\Desktop\vsgCs\build\src\CsApp\CsApp.vcxproj]
  (compiling source file '../../../src/CsApp/CsViewer.cpp')

The overriding has this implementation:

bool CsViewer::advanceToNextFrame()
{
    VSGCS_ZONESCOPED;
    return Inherit::advanceToNextFrame();
}

Maybe I should install older version of VSG?

I guess VSG doesn't really has method with this signature. So if anyone dealt with this problem... I would be so grateful for any answer and support!

[ComradeMashkov]

Ok I fixed it by changing signature in vsgCs and now I have this error:

error C2039: 'shadowMaps': is not a member of 'vsg::DirectionalLight' [C:\Users\ilya.mashkov\Desktop\vsgCs\build\src\applications\worldviewer\worldviewer.vcxproj]
  C:\vcpkg\installed\x64-windows\include\vsg\lighting\DirectionalLight.h(23,24):
  see declaration of 'vsg::DirectionalLight'

VSG DirectionalLight indeed doesn't have this field named 'shadowMaps'.

[robertosfield]

Looks like vsgCs has drifted out of date w.r.t the VSG changes. It might be that @timoore has made fixes that aren't checked in, or they sit in a branch.

[kannode]

I would like to use Vsgcs but was unable to after a little effort. @timoore. I decided to return to it later. I might be able to help more if I could build it against the latest version vsg. At present, I have to learn the make auto download features before I can do so. Cesium would be a valuable addition to our work. Relevant Theory

…

On Wed, May 29, 2024 at 4:08 AM Robert Osfield ***@***.***> wrote: Looks like vsgCs has drifted out of date w.r.t the VSG changes. It might be that @timoore <https://github.com/timoore> has made fixes that aren't checked in, or they sit in a branch. — Reply to this email directly, view it on GitHub <#1202 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHWFHIOVMR7YIQBS25Y7HTTZEWEGJAVCNFSM6AAAAABIOIIFHCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TKOJQGIYDQ> . You are receiving this because you are subscribed to this thread.Message ID: <vsg-dev/VulkanSceneGraph/repo-discussions/1202/comments/9590208@ github.com>

[robertosfield]

Tim (@timoore) started working for Cesium a couple of months back, so I presume he's been very busy and doesn't have the time to keep vsgCs up to date over the last couple of months. If @timoore is no longer able to support vsgCs then we'll need to figure out how to maintain it going forward,

---

As a more general comment, vsgCs is one approach to supporting 3D Tiles, using cesium-ion, another approach would be to roll our own 3D Tiles support. I believe 3D Tiles is now an extension of glTF so perhaps a native glTF loader could be extended/encompass 3D Tiles support. The VSG has it's own database pager support so much of the functionality that cesium-ion isn't really required for VSG native 3D Tiles support.

The reason why I raise this possibility is the the cesium-ion project, while it's great that it's open source,it pulls in many large dependencies, it's a long way from a light-weight, easy to pull in dependency. With the the VSG project I have striven to provide a good ratio of functionality to dependency complexities, so we have a general purpose scene graph with just Vulkan, C++17, CMake and optionally glslang. cesium-ion is rather odds at this minimal approach.

However, rolling our own 3D Tiles support isn't trivial, so please don't think my suggestions above are a statement that I'll personally be writing such support over a weekend, it'll need to be something done over months effort by one or more engineers. If there are companies that want to see this happen and can find budget to fund it's development let me know.

[timoore]

Tim (@timoore) started working for Cesium a couple of months back, so I presume he's been very busy and doesn't have the time to keep vsgCs up to date over the last couple of months. If @timoore is no longer able to support vsgCs then we'll need to figure out how to maintain it going forward,

I have been doing work on vsgCs to keep its features somewhat at parity with Cesium's native runtime ports, but this is an unofficial effort. There have been breaking changes on VSG master that I haven't tackled yet.

As a more general comment, vsgCs is one approach to supporting 3D Tiles, using cesium-ion, another approach would be to roll our own 3D Tiles support. I believe 3D Tiles is now an extension of glTF so perhaps a native glTF loader could be extended/encompass 3D Tiles support. The VSG has it's own database pager support so much of the functionality that cesium-ion isn't really required for VSG native 3D Tiles support.

As an aside, I believe you are referring to the library called Cesium Native.

It's not really accurate to say that "3D Tiles is now an extension of glTF." The level-of-detail structure of a 3D Tiles database is still described by JSON files specified by the 3D Tiles standard. The leaf data file types that were created for 3D Tiles 1.0 are deprecated in 3D Tiles 1.1 in favor of using features of glTF (e.g., EXT_mesh_gpu_instancing instead of .i3dm files) or unofficial extensions. In particular, 3D Tiles metadata is stored in glTF extensions and needs to be parsed if the application cares about it.

The shift to using glTF for the payload depends on characteristics of the glTF file format that may not be obvious; they weren't to me! For example, the transform values for nodes in glTF can be specified in double precision; that is a property of JSON. 3D Tiles 1.1 uses this to eliminate the RTC_CENTER semantic and push it into the glTF. But assimp, among others, returns the node transform values as single-precision floats, so the precision required in a geospatial database would be lost.

The reason why I raise this possibility is the the cesium-ion project, while it's great that it's open source,it pulls in many large dependencies, it's a long way from a light-weight, easy to pull in dependency. With the the VSG project I have striven to provide a good ratio of functionality to dependency complexities, so we have a general purpose scene graph with just Vulkan, C++17, CMake and optionally glslang. cesium-ion is rather odds at this minimal approach.

I believe that the major offender is KTX. The process of cloning it as a submodule brings in lots of test data, or at least it tries to. Otherwise, cesium-native has a lot of dependencies because it solves a non-trivial problem 😄 It shares many dependencies with the assimp library used by vsgXchange, but developers are shielded from that because assimp is brought in as a 3rd party package. Cesium would like to use a package manager to satisfy cesium-native's dependencies, but this has proven to be a hard problem to solve in its officially supported targets.

However, rolling our own 3D Tiles support isn't trivial, so please don't think my suggestions above are a statement that I'll personally be writing such support over a weekend, it'll need to be something done over months effort by one or more engineers. If there are companies that want to see this happen and can find budget to fund it's development let me know.

No comment 😄

Tim

[timoore]

I haven't kept up with the latest VSG master in vsgCs. I'll give it some attention this week.

[rolandhill]

Hi All, Just to note that Assimp has a double precision mode. You can enable it at build time by setting the ASSIMP_DOUBLE_PRECISION cmake variable. I've done this and converted vsgXchange to inject a matrix transform to offset the centre while still returning float vertexes. I tested it on what I now think was a corrupt file, it didn't work and I had to move on to something else. I'll submit a PR when I get it working, or happy to do it now if someone wants to progress it. It does mean you would need to build your own Assimp. I don't think a double precision version is available through vcpkg. Regards, Roland

…

On Wed, 29 May 2024 at 23:35, Tim Moore ***@***.***> wrote: Tim ***@***.*** <https://github.com/timoore>) started working for Cesium a couple of months back, so I presume he's been very busy and doesn't have the time to keep vsgCs up to date over the last couple of months. If @timoore <https://github.com/timoore> is no longer able to support vsgCs then we'll need to figure out how to maintain it going forward, I have been doing work on vsgCs to keep its features somewhat at parity with Cesium's native runtime ports, but this is an unofficial effort. There have been breaking changes on VSG master that I haven't tackled yet. As a more general comment, vsgCs is one approach to supporting 3D Tiles, using cesium-ion, another approach would be to roll our own 3D Tiles support. I believe 3D Tiles is now an extension of glTF so perhaps a native glTF loader could be extended/encompass 3D Tiles support. The VSG has it's own database pager support so much of the functionality that cesium-ion isn't really required for VSG native 3D Tiles support. As an aside, I believe you are referring to the library called Cesium Native <https://github.com/CesiumGS/cesium-native>. It's not really accurate to say that "3D Tiles is now an extension of glTF." The level-of-detail structure of a 3D Tiles database is still described by JSON files specified by the 3D Tiles standard. The leaf data file types that were created for 3D Tiles 1.0 are deprecated in 3D Tiles 1.1 in favor of using features of glTF (e.g., EXT_mesh_gpu_instancing instead of .i3dm files) or unofficial extensions. In particular, 3D Tiles metadata is stored in glTF extensions and needs to be parsed if the application cares about it. The shift to using glTF for the payload depends on characteristics of the glTF file format that may not be obvious; they weren't to me! For example, the transform values for nodes in glTF can be specified in double precision; that is a property of JSON. 3D Tiles 1.1 uses this to eliminate the RTC_CENTER semantic and push it into the glTF. But assimp, among others, returns the node transform values as single-precision floats, so the precision required in a geospatial database would be lost. The reason why I raise this possibility is the the cesium-ion project, while it's great that it's open source,it pulls in many large dependencies, it's a long way from a light-weight, easy to pull in dependency. With the the VSG project I have striven to provide a good ratio of functionality to dependency complexities, so we have a general purpose scene graph with just Vulkan, C++17, CMake and optionally glslang. cesium-ion is rather odds at this minimal approach. I believe that the major offender is KTX. The process of cloning it as a submodule brings in lots of test data, or at least it tries to. Otherwise, cesium-native has a lot of dependencies because it solves a non-trivial problem 😄 It shares many dependencies with the assimp library used by vsgXchange, but developers are shielded from that because assimp is brought in as a 3rd party package. Cesium would like to use a package manager to satisfy cesium-native's dependencies, but this has proven to be a hard problem to solve in its officially supported targets. However, rolling our own 3D Tiles support isn't trivial, so please don't think my suggestions above are a statement that I'll personally be writing such support over a weekend, it'll need to be something done over months effort by one or more engineers. If there are companies that want to see this happen and can find budget to fund it's development let me know. No comment 😄 Tim — Reply to this email directly, view it on GitHub <#1202 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPOEQ4ST23PF46K6AFHAGLZEXKTZAVCNFSM6AAAAABIOIIFHCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TKOJTHE3DO> . You are receiving this because you are subscribed to this thread.Message ID: <vsg-dev/VulkanSceneGraph/repo-discussions/1202/comments/9593967@ github.com>

[xingfu2005]

CsViewer.h
#if VSG_VERSION_MAJOR >= 1 && VSG_VERSION_MINOR >= 1 && VSG_VERSION_PATCH>= 3
bool advanceToNextFrame(double simulationTime = UseTimeSinceStartPoint) override;
#else
bool advanceToNextFrame() override;
#endif
CsViewer.cpp
#if VSG_VERSION_MAJOR >= 1 && VSG_VERSION_MINOR >= 1 && VSG_VERSION_PATCH>= 3
bool CsViewer::advanceToNextFrame(double simulationTime)
{
VSGCS_ZONESCOPED;
return Inherit::advanceToNextFrame();
}
#else
bool CsViewer::advanceToNextFrame()
{
VSGCS_ZONESCOPED;
return Inherit::advanceToNextFrame();
}
#endif
worldviewer.cpp
#if VSG_VERSION_MAJOR >= 1 && VSG_VERSION_MINOR >= 1 && VSG_VERSION_PATCH>= 3
#else
auto shadowMaps = arguments.value<uint32_t>(0, "--shadow-maps");
directionalLight->shadowMaps = shadowMaps;
#endif
can the above solve problem?

[ComradeMashkov]

@xingfu2005 @timoore I solved this problem recently by myself as you suggested and I successfully built vsgCs but this does not work when running worldviewer :(

I used this command to run worldviewer:

./bin/Debug/worldviewer.exe --ion-token-file ~/.cesiumiontoken --world-file /c/Users/ilya.mashkov/Desktop/vsgCs/tests/csterrain.json

And the output in console:

Assertion failed: std::this_thread::get_id() == this->_threadID, file C:\msys64\mingw64\include\CesiumUtility/ReferenceCounted.h, line 64

Image

[timoore]

I've pushed changes to vsgCs:master to compile and run with VSG master. I've disabled shadows for the moment.

I'm not sure what's the best way to support shadows in a "third party" library like this. @robertosfield , should I include shadows.glsl from vsgExamples with vsgCs and call its functions in the same way as standard_pbr.frag?

[robertosfield]

Copying shadows.glsl is probably the thing to do right now.

As to what to do longer term. The ShaderSet's can include the shader GLSL source and/or SPIRVcode but looses reference to the original GLSL files. Would there be merit to extending it to include more information about the original files, and have them be part of the VSG install?

Perhaps one could take the approach of making a 3rd party ShaderSet be based upon a built-in ShaderSet like the PBR one but extending/adapting it. I'm open to suggestions on how best to navigate this issue.

[ComradeMashkov]

@timoore thanks for your commit! Though now it has no errors concerning shadows and simulation time variable, I have new error with Linker :/

Error

dracod.lib(options.obj) : error LNK2005: "public: __cdecl draco::Options::Options(void)" (??0Options@draco@@QEAA@XZ) уже определен в Cesium3DTilesContentd.lib(PntsToGltfConverter.obj) [Z:\dev\vsgCs\build\src\applications\gltfviewer\gltfviewer.vcxproj]
Z:\dev\vsgCs\build\bin\Debug\gltfviewer.exe : fatal error LNK1169: обнаружен многократно определенный символ - один или более [Z:\dev\vsgCs\build\src\applications\gltfviewer\gltfviewer.vcxproj]

It says, that some Draco declarations are already declared in cesium library (LNK1169 error) when building gltfviewer bin.

[ComradeMashkov]

@timoore OK I set cesium tag from this cd4fec62444edf356083f64519de8da1cef4b5b2 to this 32309b09de1a9e0860e647fa4900c1491d74c85b (old) and now at least I can compile without errors. However, when running any of .exe files (gltfviewer or csclient) I have this error: FATAL: pbr::makeShaderSet(...) could not find shaders.

[timoore]

You need to set VSG_FILE_PATH to the location of vsgCs' data directory.

[ComradeMashkov]

Thanks a lot! I finally managed to run vsgCs and it works! But I guess you should change git hashtag for cesium-native to the old one (?).