izzyboris
commented
7 months ago Marked as Draft, as I realized this may be a wrong or incomplete solution.
When in 'ref' mode: gltf2bam doesn't know the original path of the .blend file. I would assume that if using 'ref', the relative path of a texture to the .blend file should be the same as the relative path to the resulting .bam file. However, to calculate the relative path we need to know where the .blend file came from on disk.
When in 'copy' mode: a new relative path to the copied image can be used. However I'm having difficulty with this, where even though the uri gets set as e.g., "Beam.png", something is still storing a relative path, and this only becomes obvious once the game files are moved to a different Windows drive (since in Windows, it's impossible to construct a relative path between drives).
:gobj(error): Texture::read() - couldn't read: ../../../../../../../AppData/Local/Temp/tmptzg9q0ys/Beam.png
:gobj(error): Unable to find texture "../../../../../../../AppData/Local/Temp/tmptzg9q0ys/Beam.png" on model-path /d/win_amd64;/..;/../models;/d/win_amd64/assets;/d/win_amd64/assets/models
Proposed to fix #89. Write gltf image uris as paths relative to the asset, keeping in line with the gltf format spec and also avoiding the problem described in https://github.com/Moguri/panda3d-gltf/issues/131
Note that I can't seem to run these unit tests in my environment at the moment but I've checked this works at runtime during loadModel(), running manually at the command line and in bdist_apps.