How not to embed textures in vsg files

[lufriem]

Hi all,

it seems that currently all vsg model files (vsgt/vsgb) embed all required textures. However, I'd like for users of my application to be able to provide alternative textures (without having to recompile the model file(s), and to share textures between models.

From the research I did it looks like OSG did actually allow for this (at least in its text format representation), so I'm wondering why this was not done for VSG? Possibly just a lack of time (and it's on the list)? Embedding all required data makes the handling of models certainly much easier..

So I guess my question is, will be this added in the future?

[robertosfield]

To handle definition of objects that are supplied by external files I implemented a vsg::External class:

https://github.com/vsg-dev/VulkanSceneGraph/blob/master/include/vsg/core/External.h

You set up the objects you want to be loaded from file, then assign this vsg::External object to the root node of the subgraph you want to read/write. The VSG's sharing objects within the native loaders can then handle wire up the externally loaded objects with the objects that are used within the scene graph itself.

Unfortunately I don't have an example showing how it works in practice. When I originally wrote it 2019 I will have created a test of it, but I can't see anything in vsgExamples now.

The idea behind it is that it would work for all objects sub-classed from vsg::Object, not just images like is done with the OSG, and it's done without support for it spreading out over the whole code base, instead it's a locally "trick" that is a bit esoteric but is quite powerful.

I hope this makes enough sense for you to start experimenting with it.

[lufriem]

Thank you for your fast reply! That looks very interesting and I think I 'get' it, I'll give this a try!

[lufriem]

Sorry I am back asking for more help.. I just don't understand how I specify that a given externally loaded texture applies to (or replaces) a texture used in the model..

In the documentation you linked to, the "mytexture.png" texture is inserted using the "external" key (I guess this can be any string), but what's the link to the model's texture? I mean, the native file format (and hence the native loaders) does not know about any filenames (since they're embedded).

[robertosfield]

A search of the old vsg-users group that was active when I wrote vsg::External, the following post might be helpful:

https://groups.google.com/g/vsg-users/c/UgTgwrmP7qo/m/fnDLEHoDDwAJ

[lufriem]

Thanks once more for your reply, and your time!

I always tend to forget about the old user group, sorry. I found another nice explanation by you in this thread, and I got it to work (for the teapot) :)

So I guess I'll look into changing assimp now, I see that its SceneConverter::convertTexture() function is already using shared_objects, my thought would be to simply add an 'extern_objects' vsg::External member to SceneConverter and register all textures in there when converting the textures, then add this node to the root of the scenegraph so that it will be exported

[robertosfield]

Off the cuff thought, I wonder if one might be create a loader like the vsgXchange::curl to catches attempts to read files and then populates a vsg::External on successful loads. No ideal if this could be made to work.

[lufriem]

I created a PR adding this functionality, it can be found here.

Basically there are two more command line parameters:

• external_textures [true/false]
• external_texture_format [native/vsgt/vsgb]

The second option enables the user to convert these external textures into vsg's native format, so that the application consuming the model need not include vsgXchange to convert these external textures. If the 'native' option is specified (which is the default) then the original texture will not be changed.

Like I wrote in the PR there's one thing I'm unsure about, the vsg::Sampler.. the vsg::Image is now read 'just in time' but the vsg::Sampler has already been precomputed (and embedded in the model file). So if for example the external image was created with mipmaps by the time the model was converted, but is then later changed NOT to include mipmaps, I am not sure what's going to happen (if this is a bad thing or not).