Open raeleus opened 5 years ago
You could just create two or more seperate atlas files for this purpose.
I'm sorry. I could do that, but I don't like it as a solution. That actually goes against the purpose of having a texture atlas in my opinion.
I think this depends on the viewport. Let's say you have 3 layers of background images. You name your atlas "bgImages.atlas" for example, including 3 pages, one for each layer. You do have your personal structure, yes. But i think differently. I don't use the atlas to organize my images (so these images are all background images and my atlas is called bgImages.atlas containing them all). I see it as a pack of images which get rendered together and not as an organization tool for my images, so my approach would be 3 different atlas files: bgImagesLayer1.atlas bgImagesLayer2.atlas bgImagesLayer3.atlas
Having multiple atlasses means my entities need to keep track of which atlas they belong to in addition to their texture region name. Having one atlas is cleaner and fits for many kinds of projects. Most of the time you realize you need more than one page after having everything already in one atlas. This option would save the time from having to redo the atlasses all over again. Also, it's part of the original spec, so it seems to be an omission. You can still use your technique if that is better for your project.
@raeleus sorry for the late reply. It's actually interesting because this feature is completely gone years ago and can't be easily implemented now. Since the app introduced the concept of "input files", the traditional texture packer approach to how to feed the images/dirs for the packing was completely abandoned. Currently, the app collects the list of the images using input/ignore files/dirs from the "input files" list according to all the rename rules and other configuration that is solely on the side of the GUI application. This process happens every time an application "pack entry" gets packed. So it's almost safe to say that the result image list is somehow randomly ordered.
Now the real question is what are other use cases when people want to group images together or control the order in any other way and what the app can do about it to provide meaningful options/UI?
A common paradigm is to separate the UI from the game graphics, so the UI would be on its own page. You can also separate graphics for each level into individual pages. Honestly, I've switched to using pack.json files with the command line texture packer to do this. As I understand it, most people don't know you can arrange pages in this manner. It doesn't sound like it's worth the effort to add the feature. Feel free to close this if you choose.
It's true that separating in that manner is important. But from my experience, I was always separating things by atlases (HUD, menu screen, level0, level1, etc...) and kept them to one-page only. It's pretty much the same thing, as organizing individual pages in one atlas, but managing those in the GUI app using separate "packs" might give some extra tweak options for individual images.
All in all, I tend to think that people mostly use the multi-atlas approach rather than one big multi-page atlas for the entire app. Which if true, makes the case described in that issue a minor one. But the fact that there were multiple requests for the ordering feature makes me think that the possible solution for it might also give some nice opportunities for your case here.
I have several large images that need to be in the same atlas. I'm fine with it spanning multiple pages. However, for the sake of efficiency, certain images need to appear on the same page to limit texture swaps. This technique works well when your images are drawn in specific layers. I see no option to do this in Texture Packer GUI. LibGDX's Texture Packer has this option: https://github.com/libgdx/libgdx/wiki/Texture-packer#directory-structure It would be nice to have this feature in some capacity in your fantastic utility. Where would this option go? I imagine it can go in the properties menu for each item in the Pack files panel. It would take an integer indicating what page it should prefer. Thanks for your consideration.