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
When multiple output files get generated due to having too many images in your atlas there is no way of knowing how many of them were created.
Maybe a file that tells you how many atlas were created could be useful?
(I would make this an option to always do it (even if only one atlas was created) so from code I can just tell my loader to check one file and load all the things that said file knows: be it one or many atlas.)
anyway, awesome work!
Edit: Maybe a metadata field for that would be simpler and break less stuff?
Edit2: the metafield related_multi_packs could host an array of strings naming all the other files created by the packer. We could inject it into the options object here: https://github.com/odrick/free-tex-packer-core/blob/master/FilesProcessor.js#L27 however I am not sure how this would affect the templating system :S
(It seems that the metafield related_multi_packs is what is used for that in other packers)
The text was updated successfully, but these errors were encountered:
miltoncandelero
changed the title
[Feature Request] Add a file that lists all atlas created
[Feature Request] Add a meta field that lists all the created atlas
Mar 25, 2020
When multiple output files get generated due to having too many images in your atlas there is no way of knowing how many of them were created.Maybe a file that tells you how many atlas were created could be useful?(I would make this an option to always do it (even if only one atlas was created) so from code I can just tell my loader to check one file and load all the things that said file knows: be it one or many atlas.)anyway, awesome work!
Edit: Maybe a metadata field for that would be simpler and break less stuff?
Edit2: the metafield
related_multi_packs
could host an array of strings naming all the other files created by the packer. We could inject it into theoptions
object here: https://github.com/odrick/free-tex-packer-core/blob/master/FilesProcessor.js#L27 however I am not sure how this would affect the templating system :S(It seems that the metafield
related_multi_packs
is what is used for that in other packers)The text was updated successfully, but these errors were encountered: