Open thejustinwalsh opened 11 years ago
The current algorithm is dead simple, but it's been producing very good results for me, so I haven't been planning to change it.
But if it's performing poorly and there's another algorithm that will produce better results I'd be all for it. Do you have an example we can look at of a Flump project that gets bad texture packing results?
I will chime in and say that it takes ages for flump to pack my UI atlases. So a faster algorithm would be neat for my project. I don't know if MaxRects is that, but there's my 2 cents.
On Thu, Sep 12, 2013 at 1:13 PM, Tim Conkling notifications@github.comwrote:
The current algorithm is dead simple, but it's been producing very good results for me, so I haven't been planning to change it.
But if it's performing poorly and there's another algorithm that will produce better results I'd be all for it. Do you have an example we can look at of a Flump project that gets bad texture packing results?
— Reply to this email directly or view it on GitHubhttps://github.com/threerings/flump/issues/84#issuecomment-24351985 .
Nathan Curtis "Education is not the learning of facts, but the training of the mind to think." --Albert Einstein
It's not that we are getting horrible results with the current implementation (it does take a while to pack). It is that we are currently generating fifteen 2048 x 2048 atlases. And in attempting to crop, cut, and slice assets up for better results, I also had the thought "MaxRects" is freaking cool. Just trying to squeeze more out of the texture space.
I won't have time for a few weeks to look at this myself, so was just curious if anyone else was about to take a stab at another algorithm.
No immediate plans here (my current project is still in prototype phase and my atlases are pretty small), but if anyone is interested in tackling this, the relevant code to modify/replace is all in TexturePacker.as
Any plans to implement a better texture packing algorithm. Like MaxRects?