[Nuke]

my gtx260 will do 8192x8192, but at the 4/8 bpp for dxt1/5 respectively, your talking about a 32/64 meg texture. but thats one texture, with our texture system, you need 4 of them, 2 of which absolutely must have alpha support. so were talking 32 (64 with alpha)+32+64+64, thats 192 (224 with alpha). mind you this does not include mipmaps (which at this resolution would be huge by themselves) considering a video card with a gig of ram (and mine has less than that), this is about 1/5th of the memory on the card. therefore this resolution is not even remotely sane for this type of application. these texture resolutions are mostly reserved for world geometry textures in other types of games. if you want a mission where two super-caps duke it out, youve used up half of your video memory.

i kinda have to agree with the mediavps methodology here. its not about supported maximum texture size but in the amount of video memory on the card. 4096^2 should be the absolute maximum right now, and lower res textures should be made available to those who have hardware that does not support those resolutions. but a good practice is to draw textures at a much higher resolution than supported, and down sample to the maximum and sub-maximum sizes. that way when the average video memory goes up, you can release super high detail textures from existing sources.

[Zacam]

Exactly.

[Rga_Noris]

My Sath currently uses 3 4096^2 textures, but I will provide 2048^2 in additon for older machines. It should be of note that, in a crude beta test involving multiple Saths on screen, my Sath actually had improved performance over the tile mapped retail. It doesn't make sense, considering the sheer poly count, but the numbers are what they are. Also, I have detail boxed the bejesus out of this thing.

[Nuke]

since down-sampled images are already present in the mip maps of a texture. is there any way to make the bitmap management code automatically toss the first mip level when it loads large 4096^2 textures into memory? this would really simplify mod distribution and installation. some kinda flag like -toss4096, could be used on low end machines.

[Zacam]

since down-sampled images are already present in the mip maps of a texture. is there any way to make the bitmap management code automatically toss the first mip level when it loads large 4096^2 textures into memory? this would really simplify mod distribution and installation. some kinda flag like -toss4096, could be used on low end machines.

Maybe. The issue there is knowing -when- and getting appropriate talk back from the hardware to know to do so and doing it BEFORE the hardware tries to choke on it.

But not a bad idea, really. Definitely an interesting possibility. And it would mean that more artist would have to verify the MIP layer output. (I always examine the mip layers myself and have adjusted Photoshop for what I believe to be the best results).

[TrashMan]

Interesting...Now if only 3D Max would cooperate..I moved from 7 to 8, and the UV mapping works differenlty here....

[Nuke]

since down-sampled images are already present in the mip maps of a texture. is there any way to make the bitmap management code automatically toss the first mip level when it loads large 4096^2 textures into memory? this would really simplify mod distribution and installation. some kinda flag like -toss4096, could be used on low end machines.

Maybe. The issue there is knowing -when- and getting appropriate talk back from the hardware to know to do so and doing it BEFORE the hardware tries to choke on it.

But not a bad idea, really. Definitely an interesting possibility. And it would mean that more artist would have to verify the MIP layer output. (I always examine the mip layers myself and have adjusted Photoshop for what I believe to be the best results).

last night i combed over the dds file specs and talked to the e about this. and from my investigations it would be possible to do this at file load. after loading the file header into memory, but before loading image data, the resolution data can be checked to see if it is beyond a previously set limit (perhaps as a command line flag or other setting). if it is not, then file load goes as usual. however if it is, then the header is tweaked (i think only 4 values need to be changed), and the read pointer advanced to start of the next mip level. so the first mip will never be loaded into memory while still maintaining the format. and the engine never knowing that the image on disk is actually much larger than the one in memory. actually i kinda think the format was designed specifically for this kinda application.