vsgXchange and Assimp

[Andre Normann]

Hi all,

I have a working version of an assimp loader. Robert created an assimp branch for testing. Before I can create a pull request, two points needs to be discussed:

- How should 3rd party libs be integrated in vsgXchange? As a submodule or as a regular directory? Not all libs are hosted on GitHub or even using git.

- How should the texture unit layout look like? I am currently using this scheme:

0 = diffuse/albedo

1 = metall/roughness

2 = normal

3 = ambient occlusion

4 = emissive

- What is the best and easiest method to convert texture formats? Let's say I have a texture file with format a, but this format is not supported by my graphics hardware. So it needs to be converted into format b. Is there something available in vsg?

I am using STBI and libktx for loading jpeg, png, ktx etc. image files.

This screenshot is showing the damaged helmet gltf file:

-André

[Robert Osfield]

Hi André,

On Wed, 20 Jan 2021 at 16:16, Andre Normann <andre....@gmail.com> wrote:

I have a working version of an assimp loader. Robert created an assimp branch for testing. Before I can create a pull request, two points needs to be discussed:

Good to hear you've got things working. Looking forward to testing things out.

 

- How should 3rd party libs be integrated in vsgXchange? As a submodule or as a regular directory? Not all libs are hosted on GitHub or even using git.

How to go about it will probably need to vary depending upon the nature of the dependency.  Possibilities are:

    1) If a dependency is a standard lib installed then just checking for it with cmake and then enabling the associated ReaderWriter would be appropriate

        vsgXchange uses this approach for the present OSG and FreeType integration.

    2) If a dependency is in git then submodule is a possibility, but even then might not be something we want to make a default. 

         This is what vsgImGui does with ImGui.

    3) If a dependency isn't git, or we don't want to use a submodule then using cmake to checkout the dependency should be possible.

    4) Just copy the code in if the license is compatible.

We will likely want some kind of CMake control over what set of dependencies should be pulled in if they don't already exist, and even the control of disabling use of dependencies that exist but we don't want them included.

- How should the texture unit layout look like? I am currently using this scheme:

0 = diffuse/albedo

1 = metall/roughness

2 = normal

3 = ambient occlusion

4 = emissive

For now just go with this combination.  Longer term I think it would be useful to have some form of configurable builder for state and geometry data, a scheme that multiple loaders could use.  Being able to customize this would be nice too.  This is really just arm waving right now - knowing this would be useful is a lot easier than actually implementing it.

 

- What is the best and easiest method to convert texture formats? Let's say I have a texture file with format a, but this format is not supported by my graphics hardware. So it needs to be converted into format b. Is there something available in vsg?

The core VSG itself doesn't have tools for converting between image formats.  It just has data containers for the image data that are assumed to be in Vulkan friendly formats.

The OSG vsgXchange code has some basic format conversion, but it's mainly just converting from RGB to RGBA type of thing - NVidia presently doesn't support RGB formats so you have to convert to RGBA.

Potentially vsgXchange could provide image conversion functions/classes.

What formats are you thinking we'll need to convert between?

I am using STBI and libktx for loading jpeg, png, ktx etc. image files.

Cool.  Does STBI support mipmapping, cubemaps etc?

 

This screenshot is showing the damaged helmet gltf file:

Sweet demonstration of Qt and Assimp integration :-)

[Andre Normann]

I will use cmake find_package() for assimp and libktx. STBI is just one header file. I will check the license and if it fits, then I will include the file directly.

STBI does not support mipmapping and cubemaps, but libktx does. There are some programs available which lets you create ktx files with mipmapping etc. (PVRTexTool, AMD Compressonator).

Regarding format conversion: I do not have any special format in mind. It was more a general question how to handle this issue. I saw some vulkan tutorials which were demonstrating such a format conversion.

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BV8gEzL4AZLLyiH-ACAoU%2BxRa7g%3Ddh9P0e%2BmTgZ%2BGO6rw%40mail.gmail.com.

[Robert Osfield]

Hi All,

André has done the heavy lifting for us so we now have the ability to load 3d models using assimp and images using stbi.  The work is checked into the Assimp branch of vsgXchange:

    https://github.com/vsg-dev/vsgXchange/tree/Assimp

You'll need to compile and install assimp:

    https://github.com/assimp/assimp

Then vsgXchange should pick it up and automatically build it.

Rebuilding vsgExamples should then give you the ability to do things like :

     vsgviewer DamagedHelmet.glb

And have a nice PBR model to look :-)  This model is in the official glTF data set.

    https://github.com/KhronosGroup/glTF-Sample-Models

While there will still be more work to do, what we have so far is certainly ready for wider testing.  Thanks to André for his efforts.

Cheers,

Robert.

[Robert Osfield]

Today I checked in a couple of refinements of vsgXchange and the new stbi functionality:

1. Add a new vsg::lowerCaseFileExtension(..) method that makes it easier to compare file extensions across a supported list, so we can handle image.JPG as well as image.jpg without problems. I also added usage into other ReaderWriters so the whole vsgXchange now uses this functionality.
   
2. Added custom C++ based new/delete versions for the STBI malloc/free/reallocate functions to allow us to use STBI created image data directly in the associated vsg::Array2D images, without need for extra allocs and copies.

I am continuing with testing and refinement where I see opportunities. My expectations is that vsgXchange Assump branch will be in a good enough place to merge with master in the next day or so.  Testing out in the community would also be appreciated.  If you have some nice screenshots please share :-)

[Andre Normann]

I nearly finished my work on a dds file loader. It supports loading of mipmaps, compressed image files and cubemaps. Loading of mipmaps and compressed files is done. Currently I am testing cubemaps.

The dds file loading is based on tinyddsloader <https://github.com/benikabocha/tinyddsloader>

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/886654ee-afb5-4806-b413-02f3a73b61d7n%40googlegroups.com.

[Robert Osfield]

On Monday, 25 January 2021 at 16:29:55 UTC andre....@gmail.com wrote:

I nearly finished my work on a dds file loader. It supports loading of mipmaps, compressed image files and cubemaps. Loading of mipmaps and compressed files is done. Currently I am testing cubemaps.

 

The dds file loading is based on tinyddsloader <https://github.com/benikabocha/tinyddsloader>

Excellent. That's another really useful addition :-)

 FYI, I've just checked in the addition to ReaderWriter_assim.cpp of output to the console the original texture path so we can track down failures more easily. so we see output like:

Failed to load texture:  texPath = .\wal67ar_small.jpg
Failed to load texture:  texPath = .\wal69ar_small.jpg
Failed to load texture:  texPath = .\SpiderTex.jpg
Failed to load texture:  texPath = .\drkwood2.jpg
Failed to load texture:  texPath = .\engineflare1.jpg

This highlights the need to handle file paths from other OS's more elegantly in the VSG i.e. change \ to /  when required.

Though we'll need to be even more creative when trying to fix things like:

Failed to load texture:  texPath = C:\code\sourceforge\kwxport\trunkMerged\test\data\bottom.tga
Failed to load texture:  texPath = C:\code\sourceforge\kwxport\trunkMerged\test\data\top.tga
Failed to load texture:  texPath = C:\code\sourceforge\kwxport\trunkMerged\test\data\updown.tga

This is for test data in the Assimp project itself.

Do you know if Asssimp has the ability to report all the supported file formats/extensions?

[Karol Nowak]

Hi There,

I am testing the vsg-assimp and facing the following issue:

Here you are my demo code:

#include <vsg/all.h>

#include "assimp/ReaderWriter_assimp.h"

#include "stbi/ReaderWriter_stbi.h"

int main(int argc, char **argv)

{

auto windowTraits = vsg::WindowTraits::create();

windowTraits->windowTitle = "MyFirstVsgApplication";

auto window = vsg::Window::create(windowTraits);

auto viewport = vsg::ViewportState::create(0, 0, window->extent2D().width, window->extent2D().height);

auto perspective = vsg::Perspective::create(60.0, static_cast<double>(window->extent2D().width) / static_cast<double>(window->extent2D().height), 1.0, 100.0);

auto lookAt = vsg::LookAt::create(vsg::dvec3(0.0, -50.0, 0.0), vsg::dvec3(0.0, 0.0, 0.0), vsg::dvec3(0.0, 0.0, 1.0));

auto camera = vsg::Camera::create(perspective, lookAt, viewport);

auto scene = vsg::Group::create();

//

//

//

auto options = vsg::Options::create();

auto composite = vsg::CompositeReaderWriter::create();

composite->add(vsgXchange::ReaderWriter_stbi::create());

composite->add(vsgXchange::ReaderWriter_assimp::create());

options->readerWriter = composite;

vsg::Path path = "Path to the DamagedHelmet.glb";

auto object = vsg::read(path, options);

if (auto node = object.cast<vsg::Node>(); node)

{

std::cerr << "Node" << std::endl;

scene->addChild(node);

}

else if (auto data = object.cast<vsg::Data>(); data)

{

std::cerr << "Data" << std::endl;

}

else if (object)

{

std::cout << "Unable to view object of type " << object->className() << std::endl;

}

else

{

std::cout << "Unable to load model from file " << path << std::endl;

}

//

//

//

auto viewer = vsg::Viewer::create();

viewer->addWindow(window);

auto commandGraph = vsg::createCommandGraphForView(window, camera, scene);

viewer->assignRecordAndSubmitTaskAndPresentation({commandGraph});

viewer->compile();

viewer->addEventHandler(vsg::WindowResizeHandler::create());

viewer->addEventHandler(vsg::CloseHandler::create(viewer));

viewer->addEventHandler(vsg::Trackball::create(camera));

while (viewer->advanceToNextFrame())

{

viewer->handleEvents();

viewer->update();

viewer->recordAndSubmit();

viewer->present();

}

return 0;

}

Did I miss sth in my code? 

Model URL:

https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/2.0/DamagedHelmet/glTF-Binary/DamagedHelmet.glb

Best regards,

Karol

[Karol Nowak]

I installed the latest Vulkan SDK and it's fine now:

[Andre Normann]

I think you are looking for this method:

// -------------------------------------------------------------------
/** Get a full list of all file extensions supported by ASSIMP.
 *
 * If a file extension is contained in the list this does of course not
 * mean that ASSIMP is able to load all files with this extension ---
 * it simply means there is an importer loaded which claims to handle
 * files with this file extension.
 * @param szOut String to receive the extension list.
 *   Format of the list: "*.3ds;*.obj;*.dae". This is useful for
 *   use with the WinAPI call GetOpenFileName(Ex). */
void GetExtensionList(aiString &szOut) const;

[Robert Osfield]

I think you are looking for this method:

// -------------------------------------------------------------------
/** Get a full list of all file extensions supported by ASSIMP.
 *
 * If a file extension is contained in the list this does of course not
 * mean that ASSIMP is able to load all files with this extension ---
 * it simply means there is an importer loaded which claims to handle
 * files with this file extension.
 * @param szOut String to receive the extension list.
 *   Format of the list: "*.3ds;*.obj;*.dae". This is useful for
 *   use with the WinAPI call GetOpenFileName(Ex). */
void GetExtensionList(aiString &szOut) const;

I see that you need to construct an Assim::Importer to do the query.  As quick hack I added output of the supported formats to the read() method and this is what I get:

GetExtensionList() *.3d;*.3ds;*.3mf;*.ac;*.ac3d;*.acc;*.amf;*.ase;*.ask;*.assbin;*.b3d;*.blend;*.bvh;*.cob;*.csm;*.dae;*.dxf;*.enff;*.fbx;*.glb;*.gltf;*.hmp;*.ifc;*.ifczip;*.irr;*.irrmesh;*.lwo;*.lws;*.lxo;*.m3d;*.md2;*.md3;
*.md5anim;*.md5camera;*.md5mesh;*.mdc;*.mdl;*.mesh;*.mesh.xml;*.mot;*.ms3d;*.ndo;*.nff;*.obj;*.off;*.ogex;*.pk3;*.ply;*.pmx;*.prj;*.q3o;*.q3s;*.raw;*.scn;*.sib;*.smd;*.stl;*.stp;*.ter;*.uc;*.vta;*.x;*.x3d;*.x3db;*.xgl;*.xml;
*.zae;*.zgl

Which is pretty amazing.    I also see that you've already utilized the IsExtensionSupported() method so short term we shouldn't have any issues.

Longer term I'd like to add some form of feature query mechanism for ReaderWriter so we can allow applications to enumerate which file formats are supported and their features.

--

When tinkering with the above I noticed that you use a ReaderWriter_assim::_options member to pass on the handle to the ReaderWriter_stbi, this will limit the Assim based loader to just have access to the stbi for loading images.  I think it would probably be more flexible to just pass in the Options object passed into the the intial ReaderWriter_assim::read(..) call.  This way also enable file paths added to the Option to be utilized when search for files.

Cheers,

Robert.