Timeline for Texture packing algorithm
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 19, 2015 at 18:54 | comment | added | CoffeDeveloper | Ah ok thanks, I needed to understand the algorithm :). I needed something fast because I procedurally generate thousand textures/ minute for a game, actually I rolled my own algorithm wich is very fast (but waste some more space, it's ok since after some time I discard textures anyway).. thanks for sharing the algorithm It was my starting point :) | |
| Aug 19, 2015 at 18:19 | comment | added | ZorbaTHut | @dariooo, in theory, yes, but most of the items will be added much faster than that because a valid location will be found very quickly. My experience is that this is almost always fast enough. There are more advanced algorithms you can use if you really have a huge number of elements being added to a single atlas, but don't bother with these unless you need them, which you probably don't. And note that you can make this one or two orders of magnitude faster or two by encoding the next "free" pixel into the byte that says whether a pixel is used, thereby skipping dozens of pixels ahead. | |
| Aug 18, 2015 at 16:36 | comment | added | CoffeDeveloper | It is not clear how do you check only "top left and top right" pixels. Do you mean this algorithm just text placing a image in every possible position each time it resets? that means that for a 1000x1000 image filled with 1000 items we do 1.000.000.000 steps? | |
| May 15, 2015 at 20:18 | comment | added | Jack | "Sort items" how? By height? By width? By area? | |
| Mar 28, 2014 at 10:52 | comment | added | ZorbaTHut | Oops, thanks for the update - I've been reorganizing that project pretty seriously. Modified the actual post :) | |
| Mar 28, 2014 at 10:52 | history | edited | ZorbaTHut | CC BY-SA 3.0 |
deleted 33 characters in body
|
| Mar 27, 2014 at 10:17 | comment | added | mems | For how search the latest version of ZorbaTHut's packing code (font_baker.cpp), you can found here: github.com/zorbathut/glorp/blob/… | |
| Jun 3, 2013 at 17:09 | comment | added | Hanna | The reason it got larger after compression is probably because of the compression algorithm. Since compression often relies on hashing and finding binary patterns, if the algorithm can identify enough patterns it'll generate a whole bunch of them which can cause the size to expand. a great way to test this it to simply re-zip a file over and over again and eventually it'll start getting bigger again due to the lack of patterns. | |
| Sep 8, 2010 at 5:47 | vote | accept | deft_code | ||
| Aug 22, 2010 at 18:03 | comment | added | Calvin1602 | Thanks for algo description + the admitted fail + the source code. Great post. | |
| Aug 18, 2010 at 4:27 | history | edited | ZorbaTHut | CC BY-SA 2.5 |
added 102 characters in body
|
| Aug 17, 2010 at 18:33 | comment | added | JasonD | I described it my answer. Essentially I think it's the same as yours, but with a slightly different heuristic. It would be easy for you to try, I think. Change your system to rotate the chars so they're always taller than they are wide, and sort by height rather than area - see what happens. Might be better, might be worse :) As with any heuristic method, there will be good cases and bad cases, but I've generally found that keeping things to be roughly the same shape (by rotating) and sorting by height (which minimises gaps in the initial packing) helps in the average case. | |
| Aug 17, 2010 at 17:39 | comment | added | ZorbaTHut | @JasonD, I'd love to know what your algorithm does, if it gets better output :) Even if it gets roughly equivalent output in a different way. | |
| Aug 17, 2010 at 9:35 | comment | added | JasonD | I looked at your texture and thought to myself "I'm sure our texture packer does a bit better than that". And then I went and looked at it, and realised that I broke it some time ago and didn't notice (because once it's working, who looks at the output textures?)... So thanks for posting - wouldn't have found the bug otherwise :) (once I fixed the bug, it looks very similar - maybe a shade better, but it's tricky to tell exactly. "as good" is probably the safest description). | |
| Aug 17, 2010 at 6:32 | history | edited | ZorbaTHut | CC BY-SA 2.5 |
added 56 characters in body
|
| Aug 17, 2010 at 6:06 | history | edited | ZorbaTHut | CC BY-SA 2.5 |
added 49 characters in body
|
| Aug 17, 2010 at 5:54 | history | answered | ZorbaTHut | CC BY-SA 2.5 |