X-Large bmp as texture
Hello all,
Hope every one is enjoying. The problem I wanna use a 4096x4096 bitmap as texture but i can''t be able to load it(at least in win98). So help me out friends i want help from you ppl. Hope all of you provide me with nice ideas. All ideas are welcomed. pls let me know what ever you come out with.
Take care all of u
Bye
manni
Its not good to load gigantic bitmaps, but if you want to load any bitmap, it has to be a power of two. a.k.a. 32x32, 64x64, 128x128, 640x480, 1280x1024, etc etc.
Good luck.
Good luck.
------------------------------Put THAT in your smoke and pipe it
Remember the first rule of programming? Divide and conqueror? (Some, or possibly lots of u will disagree with that, but it makes my response flow well, ok?) Well, the same works here - simply chop your bitmap into chunks - I would recomend 128x128 (Suported on all accelerators - larger and u can''t be sure.), and subdivide the surface your applying it to as well. Subdivision will be the hard part - I just hope your model is suitable. (A flat plain being the easiest.) I think u can get the graphics api to do this, but it isn''t recomended as it would be a generall solution - ie you can optimise it to your specific scenario. (Unless the api can optimise it:-))
Another point to note with large textures is that u are presumably applying the texture to somthing u want to get close to, (Otherwise use a smaller one!) and u will want to have a high resolution mesh anyway, unless antistrobic(sic) mapping is switched on (Which I wouldn''t recommend) as otherwise the texture will distort noticably.
When implimenting such a system remember that it takes longer to load a texture than anything else - so aim to reduce that algorithmically and let everything else slide initially.
Another point to note with large textures is that u are presumably applying the texture to somthing u want to get close to, (Otherwise use a smaller one!) and u will want to have a high resolution mesh anyway, unless antistrobic(sic) mapping is switched on (Which I wouldn''t recommend) as otherwise the texture will distort noticably.
When implimenting such a system remember that it takes longer to load a texture than anything else - so aim to reduce that algorithmically and let everything else slide initially.
BTW, 4096 is a power of two, 2^12 infact... 4k * 4k pixels is a little excessive, but perhaps there is some good reason to use a bitmap that large.
I cant think of any situation where it wouldnt work to divide it into say 64 textures of 512*512px. Editing would be a bit of a pain, and managing memory (all 64mb of it assuming 32bpp) would be simpler as its only one chunk. Then again, getting that big a piece of memory, especially as one big chunk, from the os is likely to fail if not because of a lack of room, but because of fragmentation. Splitting it would make getting the memory easier, and you could unload pieces of the texture that arent visible.
Ofcourse, you could solve the problem of getting memory by loading the image in pieces, but you would then be splitting it anyway, and then it may or may not be easier to just split the image beforehand.
If i needed to implement something like this, i would split the texture into 64 (512*512 px) or 256 (256*256 px) textures. It should be trivial to write a program that split the image into pieces. Loading and drawing may be more of a pain in the ass depending on what the texture is being used for.
I cant think of any situation where it wouldnt work to divide it into say 64 textures of 512*512px. Editing would be a bit of a pain, and managing memory (all 64mb of it assuming 32bpp) would be simpler as its only one chunk. Then again, getting that big a piece of memory, especially as one big chunk, from the os is likely to fail if not because of a lack of room, but because of fragmentation. Splitting it would make getting the memory easier, and you could unload pieces of the texture that arent visible.
Ofcourse, you could solve the problem of getting memory by loading the image in pieces, but you would then be splitting it anyway, and then it may or may not be easier to just split the image beforehand.
If i needed to implement something like this, i would split the texture into 64 (512*512 px) or 256 (256*256 px) textures. It should be trivial to write a program that split the image into pieces. Loading and drawing may be more of a pain in the ass depending on what the texture is being used for.
I can see one problem
over 16 million pixels
that means 16 megabytes for an 8 bit image
in 24 bit (3 bytes) from something like mspaint it is 64 megabytes.
how much memory do you have on your system and video card?
Beer - the love catalyst
good ol'' homepage
over 16 million pixels
that means 16 megabytes for an 8 bit image
in 24 bit (3 bytes) from something like mspaint it is 64 megabytes.
how much memory do you have on your system and video card?

Beer - the love catalyst
good ol'' homepage
Beer - the love catalystgood ol' homepage
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement