MipLevels = 13

[chriscalef]

Just wanted to drop a comment here, in case anyone else ever runs across this issue, it took me a second to figure out what the problem was.

The symptom: I was trying to import a set of building models which all reference the same huge texture, in order to reduce load on the graphics card. Great strategy, but when I tried to load it in Torque I got a hard crash every time. On debugging, I got a message about mipLevels greater than maxMipLevels.

The solution: after searching around a while I found the following in gfx/bitmap/gBitmap.h:

 

     
    c_maxMipLevels = 13;

 

The comments indicate that 13 takes you up to 4000 pixels or so, but my situation requires 16384 pixels high, so I jacked that up to 15 and now it works.

I don't know if there are any negative side effects to doing this, does it allocate a giant buffer somewhere for every image now, or something terrible like that? I haven't noticed any ill effects so far anyway.

[Duion]

I don't know what the current standard of texture sizes are, but I guess the potato PC owners will complain when their potato GPU cannot handle 16k textures. 4k textures are pretty safe and everyone nowadays should have a GPU that can handle those, however I don't know how it is with bigger ones.

[marauder2k9]

Could you tell me why your texture has to be that big?

Also could you tell me what format the texture is?

[Duion]

He already told you, it is to reduce load on the GPU and improve performance, it is called atlas texture.

[marauder2k9]

i know what a texture atlas is im asking why it has to be 16384

[chriscalef]

I didn't create it, so I don't know why it has to be 16384, I expect the FlightGear artists just kept making it bigger and sticking more textures onto the bottom of it. It's only 256 pixels wide.

[marauder2k9]

I didn't create it, so I don't know why it has to be 16384, I expect the FlightGear artists just kept making it bigger and sticking more textures onto the bottom of it. It's only 256 pixels wide.

 

Ah okay, and what is the texture format is it png?

[chriscalef]

Yeah, png.

[marauder2k9]

Yeah, png.

 

That may be your problem, as i understand it mip maps are generated automatically for png and jpg when imported into torque, with the hard coded limit of 13, this means each level the image drops by po2 till it gets to a 1x1. Because it isnt getting to 1x1 its throwing out that error. You could convert the image to DDS and define your own mipmapping without having to change that setting.

A texture of that size 16384 x 256 will take up a lot of VRAM to load in to the GPU

[chriscalef]

Any idea how much would be a lot? And would it be affecting performance in any other way? I'd rather not have to define my own mipmapping unless the cost is significant, because I'm lazy and don't like to work. :-)

[marauder2k9]

well each minimap is effectively 50% of the size of the texture that came before, so if 1 texture is 10Mb the next will be 5Mb and so on and so forth 13 times or in what you have set 15 times. That setting being changed is going to do the same thing for all of your textures that are png or jpg. The thing about dds is you have to define your own mipmaps but you can generate them in something like photoshop with the dds tool. You might find it being better performance especially for models with only one or 2 LOD to have fewer mipmaps

[Duion]

16384x256 is a really stupid dimension, why would anyone do that? I mean it is already heresy to use non 1:1 ration textures, but luckily Torque3D is able to tolerate those, but 16384x256 is probably stretching the limit too far.

A mipmap is the texture divided by 2 to create the next lower res version, now try dividing 256 by 2 over 13 times.

256, 128, 64, 32, 16, 8, 4, 2, 1

As you can see you cannot even divide those 13 times, it is already over at 8 and even if you could, it would make no sense at all, on the other hand the 16384 can and has to be divided a lot more.

My guess is the flight gear developers do not use mipmaps or they are amateurs that have no clue how to do things or there is a secret absurd reason why it has to be that way.

Textures should always be in .dds format, which already includes the pre-made mipmaps inside the image and improves performance by a lot and atlas textures should be in 1:1 ratio or 1:2.

[marauder2k9]

the way it works is once the Y gets to 1 the X keeps dividing by 2 until it too gets to 1 so whenever the Y gets to 1 i think 16384 will be at 128 then it will keep regressing to 64 x 1 - 32 x 1 etc until the image is at a 1x1

The texture size does seem strange to me, can you upload the texture somewhere? or even a screenshot of it?

[chriscalef]

Sure, here's the texture:

http://chriscalef.com/files/atlas_facades.png

Thanks for the help! They probably don't use mipmaps in flightgear, I'll find out though.

[marauder2k9]

i would guess that flight gears engine doesnt do mipmapping or at least is selective mip mapping, import that texture as a dds file with no mip maps, you shouldnt get any errors and it would have a smaller footprint on vram because of both that and the dxt3 compression

[chriscalef]

Okay, I found the DDS plugin for gimp and installed it, seems to work fine. Should I use compression on it? If so, which one?

[chriscalef]

And yeah, it looks like flightgear does do mipmapping, but apparently not with this texture, this is coming from sort of a side project within flightgear, called osm2city.

[marauder2k9]

well there are some black areas on that texture map so im guessing it has alpha? but it doesnt seem to have any fading alpha so no banding should occur from DXT3

[chriscalef]

Oh, nice, that came out smaller than the original png file! :-)

[marauder2k9]

Oh, nice, that came out smaller than the original png file! :-)

 

blessed is the DDS and its dxt compression lol

The thing is DDS format actually goes direct to gpu, as far as i know png and jpeg and a load of other formats have to go through some form of progressive compression before being read into memory on a gpu so with them as dds you just saved your gpu from having to work another step harder :D

[chriscalef]

Sweet, thanks! :mrgreen:

[Duion]

well there are some black areas on that texture map so im guessing it has alpha? but it doesnt seem to have any fading alpha so no banding should occur from DXT3

You are such amateurs, always use DXT1 if possible, if you cannot because alpha channel, delete alpha channel, since those textures are not supposed to have alpha, but even DXT1 can have alpha, just no gradients in it. DXT1 gives best performance, since it is half the size of DXT3 or 5.

And someone should go to the Flightgear developers and punish them for their development style crimes, but hey wait a minute, I just realized why they may do it that way, the reason is if you have an atlas texture with no textures right or left to it, you can tile the texture horizontally using the atlas texture without creating new polygons. So this may be the reason for that weird format, but I see they also have textures next to each other, which breaks this system again, so no idea, if they are genius or just stupid. The textures are also too small, should be at least 512 pixels or even 1024, think about upwards compatibility, which open source developers usually never care about, but a professional developers usually always keeps the high res versions.

[marauder2k9]

well there are some black areas on that texture map so im guessing it has alpha? but it doesnt seem to have any fading alpha so no banding should occur from DXT3

You are such amateurs, always use DXT1 if possible, if you cannot because alpha channel, delete alpha channel, since those textures are not supposed to have alpha, but even DXT1 can have alpha, just no gradients in it. DXT1 gives best performance, since it is half the size of DXT3 or 5.

And someone should go to the Flightgear developers and punish them for their development style crimes, but hey wait a minute, I just realized why they may do it that way, the reason is if you have an atlas texture with no textures right or left to it, you can tile the texture horizontally using the atlas texture without creating new polygons. So this may be the reason for that weird format, but I see they also have textures next to each other, which breaks this system again, so no idea, if they are genius or just stupid. The textures are also too small, should be at least 512 pixels or even 1024, think about upwards compatibility, which open source developers usually never care about, but a professional developers usually always keeps the high res versions.

 

DXT1 is smaller for a reason, due to the finer details in the texture he posted he should use DXT3

if you look at this image, the pic on the left is the original image the one on the right is after DXT1 compression. The finer changes in color are completely removed under the compression. You have too many details in those textures that are close together such as the roof tiles. if you were to have them as DXT1 these details would be lost.

This happens because DXT1 is only 4 bpp whereas DXT3 is 8 bpp

EDIT: Also just on that point about the Flightgear developers. They probably modeled whole cityscapes in one file with simple geometry plus, being a flight sim they would have probably thought most of your time would be spent yano flying! as far away from any of those textures as possible. Smaller textures actually look better from further distances. That's actually why mipmaps are used in a lot of games, its not to save on resources as using mipmaps actually use more resources because the engine is loading more textures than if you were to just use the default texture, but if you already start off with the smaller texture u don't really need them if these textures are specifically meant to be viewed from a distance.

[chriscalef]

if you have an atlas texture with no textures right or left to it, you can tile the texture horizontally using the atlas texture without creating new polygons

 

Ah, thanks, I didn't know that, and that explains why so often there are triangles that extend off the right side of the file. They do sometimes put two textures next to each other, but it's not the typical case, and there are definitely a lot of UVs that go into space on the right, so maybe they just know which is which somehow.

Re: going to yell at them, good luck with that, it's a bunch of part time volunteer people with mixed skill levels, same as every other open source project, and they have their own set of flame wars ongoing, feel free to go start one if you want but don't tell anybody you're with me. ;) :lol:

[Duion]

I hardly ever found DXT1 to be an issue, it is only bad for normal maps or textures with alpha, if your low res textures look fine from the distance the few broken pixels due to DXT1 will not matter also.