On 10/24/08, josch <[EMAIL PROTECTED]> wrote: > > feature idea: > > either pass a function a list of ImageData and let it return a list of > TextureRegions after it > 1) created a TextureAtlas with the best size for the given values > 2) packed the given images in the MOST EFFICIENT WAY POSSIBLE > > or have a TextureAtlas.add_multiple() function that does the same but > with the predefined Atlas size. > > worthwhile? or is such a thing too high level? > currently i'm just trying to implement exactly that on my own but i > need more knowledge about how TextureAtlas.add() works.
Have a look at http://pyglet.org/doc/api/pyglet.image.atlas.Allocator-class.html, and the source code to the Allocator class (pyglet/image/atlas.py) for details. From the documentation: "Allocator uses a fairly simple strips-based algorithm. It performs best when rectangles are allocated in decreasing height order." So, for the current implementation, (2) can be implemented as: regions = map(atlas.add(image) for image in sorted(images, key=lambda i: i.height, reverse=True)) which doesn't seem worth adding as a special method. Note that a better packing than the current algorithm is better when all the image sizes are known a-priori, however such an algorithm is NP-hard (2D bin packing problem). I'm not sure of the complexity of (1), but it feels like a variation of the same problem, and so is probably equally intractable (especially considering the size restrictions on textures). Alex. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
