PagedLOD texture loading

[avilkinnick]

Are PagedLODs with same texture loading its texture again or not?

[robertosfield]

It all depends on how the textures are stored. As you haven't said anything about how you PagedLOD based databases are created I can say anything specific about your usage case.

The vsg::External class was written to enable scene subgraphs to pull in external files like texture, but it can be any object type. You set up the vsg::External class then assign it to the root of the subgraph as user data, and as long as the vsg::Options object used when reading shares the vsg::SharedObjects external objects that are common should be shared.

Rather than just textures what you ideally want to share is the BindDescriptorSet/DescriptorImage objects as this would then share the same Vulkan state.

However, far simpler than this, the other way to share state is put it at the top of the scene graph and inherit it down. This is how the vsg::tile/vsg::TileDatabase class functions, putting common state, including graphics pipeline and common uniforms on the root node.

So... you have options, what suits you application best depends upon your needs, which... you haven't mentioned anything about so you'll need to tell us or just figure out what works yourself.

[avilkinnick]

I have railway tracks that consist of:

1. separate gltf models;
2. one file with matrix transform for all objects

Railway track is very long and many models (and textures) are repeating.
For example: there maybe only 300 unique models, but over 50K matrix transforms
And many models share textures.

So, what should I do to optimally load only nearby models?

1. create root vsg::Group;
2. create vsg::PagedLODs for all objects or only for unique models? Assign bound and filename;
3. create vsg::MatrixTransforms for all objects, add paged lod as child to it;
4. add all matrix transform to root.
   Right?

Do i have to add vsg::External to root and specify all textures and other shared resources or giving filename to pagedlod is suffice?

[robertosfield]

My recommendation would be to try and move the common state up to a root node, just like he vsg::tile ReaderWriter does for TileDatabase data. Putting textures into a texture array or texture atlas, uniform arrays etc. that you can assign to a StateGroup in the root subgraph.

Then underneath the root node you'd typically create a quad tree hierarchy, but for point clouds it might be an octree, or a linear world like around a railway perhaps even a binary tree. You can mix and match depending upon the neeeds of the region that you are breaking down into LOD's/PagedLODs.

Then for the PagedLOD you'd have a low res version of the data that is seen in the distance, and then a high res external subgraph that is loaded on demand when the viewpoint gets close enough. The external subgraph would further break the hierarchy down as far as is needed. In the case of whole world database you can gets over 20 nested levels of detail.