vsgb file size

23 views
Skip to first unread message

Denis Taniguchi

unread,
Feb 24, 2022, 4:03:58 AM2/24/22
to vsg-...@googlegroups.com
Hi Robert,

I converted a gltf file to vsgb and the difference in file size was
quite large:

model.gltf - 6.4KB

model.bin - 699KB

texture1.png - 15MB

texture2.png - 15MB

texutre3.png - 639B

converted.vsgb - 193MB

I suspect the reason for this is that the textures are stored
uncompressed inside the vsgb file? Do you have plans to address this? Is
there a way to store textures out of the file currently?

Cheers,


Denis

Robert Osfield

unread,
Feb 24, 2022, 4:44:41 AM2/24/22
to vsg-...@googlegroups.com
Hi Denis,

On Thu, 24 Feb 2022 at 09:03, 'Denis Taniguchi' via vsg-users : VulkanSceneGraph Developer Discussion Group <vsg-...@googlegroups.com> wrote:
Hi Robert,

I converted a gltf file to vsgb and the difference in file size was
quite large:

....
converted.vsgb - 193MB

I suspect the reason for this is that the textures are stored
uncompressed inside the vsgb file?

Yes, the VSG will serilalize data out as uncompressed data, this applies to all nodes, images, vertex data etc. 

If the image data is stored in a graphics compatible compressed format then it'll be serialized in this form, as well as past to the GPU in this form.
 
Do you have plans to address this?

Potentially one could write a ReaderWriter that supported compression/decompression using something zlib.  I don't have plans to implement this before 1.0, community are welcome to step up if they can't wait for me to tackle it.
 
Is
there a way to store textures out of the file currently?

The vsg::External class provides a mechanism for loading scene graph from files and then object sharing support within the VSG loader can map these to the appropriate parts of the scene graph. This mechanism works for all types of objects, so you could load models, textures using it.

Unfortunately, there are not currently any examples that illustrate how it's used.  I wrote it very early in the project's life as a proof of concept alternative to implementing external file support for textures such as what the OSG has.  The neat thing about it is that it's completely general purpose, all vsg::Object types supported, from all loaders, without any local support for external file support to local classes - they are essentially oblivious to how they are loaded/saved.

The concept behind it is that a root node of the scene graph would have a vsg::External attached to it as user data and then all the parts of the scene graph you want to be stored in an external file you add that object to the vsg::External object associating it with a filename.  i.e.

   auto group = vsg::Group::create();
   auto child = vsg::read_cast<vsg::Node>("models/teapot.vsgt");
   group->addChild(goup);
   vsg:write(group, "group.vsgt");  // standard no external reference, everything inlined

   auto external = vsg::External::create();
   external->add(""models/teapot.vsgt", child);
   group->setObject("external", external);
   vsg::write(group, "group_using_external.vsgt");

If you wanted to be creative you could probably have a .vsgt file that uses vsg::External to load components of a gltf - the bin, png etc as externals so have a minimal .gltf replacement.  It'd be daft but technically should be possible :-)

On a more practical note, while none of the existing loaders support it, it should be possible to have them assign vsg::External and all the texture files associated with a subgraph to it.  Again this isn't on my TODO list for 1.0, if I keep adding stuff I'll never get 1.0 out the door...

Cheers,
Robert.









 
Reply all
Reply to author
Forward
0 new messages