Dynamic Texture Size Support

varmint · Post by **varmint** » Sat Mar 22, 2008 12:03 am

For our project we wanted to do all the textures in the highest detail. We made that 1024x1024 (were it made sense) . Scaling down is easy, scaling up isn't so. Then instead of creating multiple textures of different sizes and including them in the download thus increasing download size, I added a little code to IVideoDriver.h and CNullDriver.cpp

in IVideoDriver.h just after

Code: Select all

	class IMaterialRenderer;
	class IGPUProgrammingServices;

add

Code: Select all

	//dynamic texture size support
	enum IRR_TEXTURESIZEOPT
	{
		IRR_TEX_TINY,
		IRR_TEX_SMALL,
		IRR_TEX_MEDIUM,
		IRR_TEX_LARGE
	};

Then towards the bottom just after virtual core::stringc getVendorInfo() = 0;
add

Code: Select all

		//sets size of texture support desired
		void setTextureSizeSupport ( IRR_TEXTURESIZEOPT in ) { textureSizeSupport = in; }
		//gets current texture size support
		IRR_TEXTURESIZEOPT getTextureSizeSupport () { return textureSizeSupport; }		
		IRR_TEXTURESIZEOPT textureSizeSupport;

Then goto CNullDriver.cpp just after

Code: Select all

	#ifdef _DEBUG
	setDebugName("CNullDriver");
	#endif

add

Code: Select all

textureSizeSupport = IRR_TEX_LARGE; //default to full texture size support

then in
CNullDriver::loadTextureFromFile(io::IReadFile* file, const c8 *hashName ) change

Code: Select all

	if (image)
	{
		// create texture from surface
		texture = createDeviceDependentTexture(image, hashName ? hashName : file->getFileName() );
		os::Printer::log("Loaded texture", file->getFileName());
		image->drop();
	}

to

Code: Select all

	if (image)
	{
		if (textureSizeSupport == IRR_TEX_LARGE) {
			// create texture from surface
			texture = createDeviceDependentTexture(image, hashName ? hashName : file->getFileName() );
			os::Printer::log("Loaded texture", file->getFileName());
			image->drop();
		} else {
			// create texture from surface
			core::dimension2d<s32> texSize = image->getDimension();
			f32 sizeMode = 1.0f;
			switch (textureSizeSupport) {
				case IRR_TEX_TINY:
					sizeMode = 0.10f;
					break;
				case IRR_TEX_SMALL:
					sizeMode = 0.25;
					break;
				case IRR_TEX_MEDIUM:
					sizeMode = 0.50;
					break;
				case IRR_TEX_LARGE:
					sizeMode = 1.0f;
					break;
			}
			texSize.Width = (s32)ceil((f32)texSize.Width * sizeMode);
			texSize.Height = (s32)ceil((f32)texSize.Height * sizeMode);

			IImage * ImageTmp = new CImage(image->getColorFormat(), texSize);
			image->copyToScaling(ImageTmp);
			
			texture = createDeviceDependentTexture(ImageTmp, hashName ? hashName : file->getFileName() );
			os::Printer::log("Loaded texture", file->getFileName());
			image->drop();
			ImageTmp->drop();
		}
	}

Example usage:
driver->setTextureSizeSupport(video::IRR_TEX_MEDIUM);

Tiny Support is about 10th the size of the texture

Medium is 1/2 the size

You can change the Texture Size Support at any time before loading textures. You could easly setup options for characters to have their own texture size settings and enviroment, FX, etc.

It's been tested against the latest SVN and on OSX, Linux and Windows

Course this does the change at load time, you could how ever save it back to disc, so next time it wouldn't have to load up the entire texture.

Thx
V

Acki · Post by **Acki** » Sat Mar 22, 2008 1:54 am

yes, it's a prety nice idea !!!

but I see a problem with the tiny size...
remember texture dimensions have to be in power of 2 (2^n)...
1/2 and 1/4 are no problem, but with 1/10 for IRR_TEX_TINY you'll never get a suitable dimension !!!

for example with 1024:
IRR_TEX_LARGE = 1024 >>> OK
IRR_TEX_MEDIUM = 512 >>> OK
IRR_TEX_SMALL = 256 >>> OK
IRR_TEX_TINY = 102.4 >>> BAD

maybe 1/8 (0.125) would be better for tiny, then the result will be 128 ???
and I bet your 1st screenshot will look better than...

varmint · Post by **varmint** » Sat Mar 22, 2008 12:10 pm

Acki wrote:yes, it's a prety nice idea !!!

but I see a problem with the tiny size...
remember texture dimensions have to be in power of 2 (2^n)...
1/2 and 1/4 are no problem, but with 1/10 for IRR_TEX_TINY you'll never get a suitable dimension !!!

for example with 1024:
IRR_TEX_LARGE = 1024 >>> OK
IRR_TEX_MEDIUM = 512 >>> OK
IRR_TEX_SMALL = 256 >>> OK
IRR_TEX_TINY = 102.4 >>> BAD

maybe 1/8 (0.125) would be better for tiny, then the result will be 128 ???
and I bet your 1st screenshot will look better than...

Actually I ended up using 0.0625 so the resulting would be 64 for tiny. And no the above screen shot will not look any better as the texture size of the dwarf starts at 512 and by the time it gets reduced to tiny support it's 32 or in the screenshot above 51.. either way your not going to get much detail at that res

Below are some links to what it looks like using 1024x1024 as a base
http://shadow.krabbit.com/varmint/sizes ... nysize.png
http://shadow.krabbit.com/varmint/sizes ... llsize.png
http://shadow.krabbit.com/varmint/sizes ... umsize.png
http://shadow.krabbit.com/varmint/sizes ... llsize.png

Acki · Post by **Acki** » Sat Mar 22, 2008 2:22 pm

yeah, right, when the original texture already is small than you can't assume to get a better result...

I just had your comment about using 1024x1024 textures in mind...

maybe you should also change the code in your post to the correct value for tiny, too ???
just for those who will just copy/paste the code...

BlindSide · Post by **BlindSide** » Sat Mar 22, 2008 3:46 pm

Yeah this is a good idea, very useful for performance scaling. If a computer is low end, no need to create different resolution textures, just use this.

Yet another useful idea Varmint.

vitek · Post by **vitek** » Sat Mar 22, 2008 11:32 pm

The following will get a smaller image size based on a quality setting, will always get you a power of two sized result, and doesn't require floating point math.

Code: Select all

enum E_TEXTURE_QUALITY 
{ 
  ETS_HIGHEST = 0u, 
  ETS_HIGH    = 1u, 
  ETS_MEDIUM  = 2u, 
  ETS_LOW     = 3u, 
  ETS_LOWEST  = 4u, 
}; 

core::dimension2di get_dimension_for_quality (const core::dimension2di& d, E_TEXTURE_QUALITY q) 
{ 
  core::dimension2di r (1, 1); 

  // 
  // find the next larger power of 2 height and width 
  // 

  while (r.Width  < d.Width) 
    r.Width  <<= 1; 

  while (r.Height < d.Height) 
    r.Height <<= 1;  

  // 
  // if d is non-power-of-two, then reduce size to next 
  // smaller power of two value. i.e. 190x65 => 128x64 
  // 

  if (r.Width != d.Width) 
    r.Width >>= 1; 

  if (r.Height != d.Height) 
    r.Height >>= 1; 

  // 
  // now reduce the size based on quality setting 
  // 

  for (u32 i = 0; i < q; ++i) 
  { 
    if (r.Height != 1) 
      r.Height >>= 1; 

    if (r.Width  != 1) 
      r.Width  >>= 1; 
  } 

  return r; 
}

Travis

MasterGod · Post by **MasterGod** » Sun Mar 23, 2008 12:08 am

Someone wrote:Yet another useful code vitek.

And thank you both, that's a great idea with now even better implementation!

Thanks guys, I could really use it.

Nadro · Post by **Nadro** » Sun Mar 23, 2008 12:27 am

It's really nice:) Good work Varmint!

Halifax · Post by **Halifax** » Sun Mar 23, 2008 3:50 am

I have to agree with BlindSide. This is great, varmint, for performance scaling, and such a simple idea. I guess KISS applies to this.

rogerborg · Post by **rogerborg** » Sun Mar 23, 2008 8:44 am

Thanks for sharing; that looks really useful.

varmint wrote:Course this does the change at load time, you could how ever save it back to disc, so next time it wouldn't have to load up the entire texture.

IIRC, GTA 3 did that, but it seems more usual to just scale them on each run, based on a user preference and/or VRAM size.

sio2 · Post by **sio2** » Mon Mar 24, 2008 10:54 am

Why not just drop the top mips of any texture above a threshold based on the host hardware - say 1024x1024 or 512x512? This could significantly reduce texture memory usage without losing detail in smaller textures via this "scale every texture" method.

BlindSide · Post by **BlindSide** » Mon Mar 24, 2008 11:17 am

sio2 wrote:Why not just drop the top mips of any texture above a threshold based on the host hardware - say 1024x1024 or 512x512? This could significantly reduce texture memory usage without losing detail in smaller textures via this "scale every texture" method.

Good point, I think user-adjustable mipmapping is on the agenda for Irrlicht developement.

sio2 · Post by **sio2** » Mon Mar 24, 2008 5:21 pm

I'm not sure if using mipmap-lod bias actually drop the higher mips from vidmem - possibly driver dependant. Probably better to not load those mip levels in the first place.

Since it's usually a significant performance boost to have all level geometry use mipped textures the best solution is probably to just not upload "large" mip levels at texture load-time. This will save texture memory and not make small textures look blurred.

Irrlicht Engine

Dynamic Texture Size Support

Dynamic Texture Size Support

Re: Dynamic Texture Size Support