You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would expect that the writer saves the images to the disk at the relative location described in the image uri.
Additional context
I traced this issue down to the WriteImageData() function that is passed to UpdateImageObject(). This function expects the FsCallback passed as the user data. However, the default write_image_user_data with is initialized withnullptr, causing the file to never be written to disk. An experimental change the initialize write_image_user_data with a pointer to the default FsCallback (&fs) fixed this issue, but caused a different unit test failure.
The text was updated successfully, but these errors were encountered:
Passing FsCallback to write_image_user_data is a confusing, so we are better to modify WriteImageDataFunction API to accept FsCallbacks callback pointer as an argument.
Thanks for the quick investigation! Your proposal looks good to me!
One point to consider as well is to omit unneeded copies of the source and dest paths are the same
Describe the issue
Writing a glTF that contains images referenced as uris without embedding images does not save the images to the disk next to the glTF model.
To Reproduce
OS: MacOS
Compiler: Apple clang version 15.0.0
The following unit test fails with with the latest version of tinygltf:
Expected behaviour
I would expect that the writer saves the images to the disk at the relative location described in the image uri.
Additional context
I traced this issue down to the
WriteImageData()
function that is passed toUpdateImageObject()
. This function expects theFsCallback
passed as the user data. However, the defaultwrite_image_user_data
with is initialized withnullptr
, causing the file to never be written to disk. An experimental change the initializewrite_image_user_data
with a pointer to the default FsCallback (&fs
) fixed this issue, but caused a different unit test failure.The text was updated successfully, but these errors were encountered: