That would be useful to determine if it's even possible to fit all the textures in one 1024x1024 atlas. Open a new bin and horizontally pack item j into i Īlso of interest, the paper describes an algorithm to determine the size of an optimally packed texture map. Pack item j in the bin, position and orientation corresponding to score Let score1 and score2 be scores with tow orientations Sort the items by nonincreaseing w,h values, and horizontally orient them Ĭompute a lower bound L on the optimal solution value, and open L empty bins įor each normal packing position in an open bin do The best algorithm he found was called Touching Perimeter. Luckily, texture packing is the easiest version. The thesis goes over some of the harder forms of this problems. The PhD Thesis of Andrea Lodi is entitled Algorithms for Two Dimensional Bin Packing and Assignment Problems.
Texturepacker fps unity code#
Obviously, there's not a lot of empty space left over, and it does a good job of cramming things into open spots.Īll the code for this is BSD-licensed and available at github. It looks blurry because mine is using Valve's distance-field based text rendering algorithm, which also accounts for the extra space between glyphs. That work just isn't worthwhile unless your company is at least 50 people large, and probably more.Īnd as a side note, I just implemented this algorithm (fixed width 512 pixels) for quite literally the exact same application that you're doing (no ftgles, but opengl-rendered freetype glyphs.) Here's the result. It's easy to code, fast to run, and you won't get much better without an amazing amount of work.
Sort items, jam into texture in scanline order. After all my work, quite literally three months of work, I ended up saving 3% space.Īnd after we ran our compression routine over it, it actually ended up larger (which I still can't explain) so we threw the entire thing out and went back to the old algorithm. I tried a bunch of wacky heuristics - trying to find objects that fit together, doing some weighting over a bunch of desired space packing properties, rotating and flipping. So, we had that algorithm, and I decided to improve it. In an attempt to preserve squareness, our algorithm would start at 128, then increase by 128s until it came up with a result that wasn't any deeper than it was wide. You either need to hardcode a width or come up with another heuristic for this. Lay them out in your texture in scanline order, just testing stuff from the topleft pixel to the topright pixel, moving down a line, and repeating, resetting to the topleft pixel after every successful placement.
Sort them by total pixels consumed, large-to-small. The algorithm we started with was simple. I spent a few months at one job coming up with a better texture packing algorithm.
0 kommentar(er)
