Archived

This topic is now archived and is closed to further replies.

monkeyman

Need to consolidate several small images into one big one..

Recommended Posts

monkeyman    253
I''m sure this has been covered more than a few times, but I''m not sure where to start looking.. Here''s the deal: I have an unknown number of small textures of unknown size that I want to combine into one large(power of 2) image.. The images are not guaranteed to be perfectly square, and can have any width/length.. It doesn''t have to be fast, but it does need to pack them in the most efficient manner possible.. My question is: Do I figure this out myself? OR Is there a standard, accepted method of doing this? "Like all good things, it starts with a monkey.."

Share this post


Link to post
Share on other sites
EvilCrap    134
the most effecient way would be to write a special image file, with a header and data segment. the header contains data on the images within, and the data segment is the actual image data.
you could accomplish this by appending .bmps to the same file and then sticking the header at the top.

sorry i dont know of any standard ways. do some research on data bases, youll get some ideas.

Share this post


Link to post
Share on other sites
monkeyman    253
Thanks for the response EvilCrap , I was debating whether or not I should try to bring it back or drop it..

Actually, I''m fine with the format and stuff, it''s just the logistics of the algorithm that I''m interested in..I''m looking for the most efficient process of sorting several variable-sized small rectangles into one large square..

I''m just using arrays of bytes for the image data, and can do whatever I want to with it..I can do this about a hundred different ways, but I don''t want to hack something less-than-perfect together from scratch if there''s a tried and true method out there for packing the images in the best way possible..

It seems like this would be a classic problem(like the traveling salesman), so I''m sure there''s some sort of papers/docs out there on the process, but I''m not sure what to look for..

"Like all good things, it starts with a monkey.."

Share this post


Link to post
Share on other sites
EvilCrap    134
i havent studied much formal surface stuff, but i think what your looking for is called a clipper object. im not aware of any programs that generate the image and a data file -you may have to manually create your clipper, recording rects as you go.
look up the directx sdk example, space donuts, it has a decent one.

Share this post


Link to post
Share on other sites
Oluseyi    2109
quote:
Original post by EvilCrap
i havent studied much formal surface stuff, but i think what your looking for is called a clipper object.

Excuse me?

You have binary image data in buffers. You allocate enough space to copy them to. You write the data. It has nothing to do with surfaces, clippers and other such presentation graphics issues. Here''s the bottleneck: you have [n]n images each of dimension xn by yn . How do you place them all within a larger image (perhaps with a border) of dimensions X by Y, where X and Y is the most efficient combination.

Frankly, the only solution I see is pretty much a software trial and error. Try various combinations of side-by-side and vertical tiling, record the resulting dimensions and then sort the products of the dimensions. The smallest product is the most efficient solution.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
thuned    122
here''s what i think.
get the size of the client''s video memory.
say its 16megs. save Xmegs for other stuff (vertex arrays, other buffers etc). then just make a large XxY image taking up the remaining space.
if you work with opengl, i don''t think a larger XxY image hinders performance if you don''t keep changing the bindings and if it fits completely in video ram all the time.

Share this post


Link to post
Share on other sites
monkeyman    253
quote:
Original post by Oluseyi
Frankly, the only solution I see is pretty much a software trial and error. Try various combinations of side-by-side and vertical tiling, record the resulting dimensions and then sort the products of the dimensions. The smallest product is the most efficient solution.



That''s about what I was thinking, create all possible combinations of horizontal and vertical strips and check the results..

It''s something I can do easily enough, I''m mostly just satisfying my curiosity

"Like all good things, it starts with a monkey.."

Share this post


Link to post
Share on other sites
monkeyman    253
quote:
Original post by thuned
here''s what i think.
get the size of the client''s video memory.
say its 16megs. save Xmegs for other stuff (vertex arrays, other buffers etc). then just make a large XxY image taking up the remaining space.
if you work with opengl, i don''t think a larger XxY image hinders performance if you don''t keep changing the bindings and if it fits completely in video ram all the time.


It doesn''t have to have anything to do with programming, it''s more of a brain-teaser..

"Like all good things, it starts with a monkey.."

Share this post


Link to post
Share on other sites