Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional texture embedding #172

Merged
merged 5 commits into from
Jan 3, 2024
Merged

Conversation

lufriem
Copy link
Contributor

@lufriem lufriem commented Sep 28, 2023

The vsgXchange::assimp ReaderWriter now offers the option of not embedding texture files into the generated vsg native file. This is done by setting the external_textures option to true. Note that this does not work for textures already embedded within the source model!

In addition, by suppling the external_texture_format command line option, it is possible to specify whether the stand-alone texture files should be saved in the vsg-native format (either vsgt or vsga). By dong this there is no need for the integrating application to link against vsgXchange for texture conversion.

This leverages the vsg::External object, see this discussion.

One thing I am unsure about is that currently only the vsg::Image is being loaded from external file, but the associated vsg::Sampler is still embedded within the file and not recalculated if the image is being loaded, which could be problematic if that external file has some properties changed (like the number of included mipmaps..)

…dding texture files into the generated vsg native file. This is done by setting the external_textures option to true. Note that this does not work for textures already embedded within the source model!

In addition, by suppling the external_texture_format command line option, it is possible to specify whether the stand-alone texture files should be saved in the vsg-native format (either vsgt or vsga). By dong this there is no need for the integrating application to link against vsgXchange for texture conversion.
src/assimp/assimp.cpp Outdated Show resolved Hide resolved
root->setObject("external", converter.externalObjects);

return root;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The above code block changes what happens when a null ref_ptr is returned from convert,visit(), and would cause the code to fall through to the vsg::read() at the end of method. Is this intended?

I would have thought a else return {} would keep the original behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you are correct. I mentally completely blanked out the #if .. #endif block and its contained 'return' statement (without that block the behaviour is actually unchanged, but still probably less easy to read).

I hope to get around to updating this PR beginning of next week.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the PR now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants