Jump to content

MipLevels = 13


Recommended Posts

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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?

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.


M2N1Xbf.jpg


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.

Link to post
Share on other sites

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:

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...