PSA: Please size your textures appropriately


TL;DR: When building content for you should try to ensure that your texture sizes are always exact multiples of 128x128 (for textures that are larger than 128x128, smaller textures are fine with any size).

I’m currently working on some rendering back end code that will smooth out the performance while loading content, as well as allow the application to start reducing texture quality of currently loaded content is we start running out of texture memory. However, there are some limitations with the functionality that depend on the content being loaded.

This functionality is supported by an underlying OpenGL feature called ‘sparse textures’. Sparse textures are only supported for textures where the dimensions of the texture are an exact integer multiple of the ‘sparse page size’, which is most commonly 64x64 or 128x128. This means that sparse textures can’t be used if a texture is, for instance, 10,000 x 10,000 pixels. However, 10,240 x 10,240 pixels would work just fine.

Following this guideline will make it a lot more likely that people running in HMDs and load your content without massive stuttering, and that when the amount of content exceeds the available memory on the card, we can address that by lowering quality, rather than by allowing the framerate to plummet.


Interesting that SL automagically adjusts the uploaded textures to some multiple of 128x128 (i.e. rounds the image up or down to the nearest size on that scale before writing it to the asset server), but HiFi is a completely different beasty. I wonder if there’s a way down the road to have textures automagically adjusted accordingly when brought into hifi.

But yeah, always a good policy when making new images for VR to set them by one of those multiples, i.e. set the new-created image size to 1024 x 1024 when you first fire up Gimp or or whatever you’re using, even if you’re going to later reduce that image down to 512x512 before upload.


You mean powers of two right?

I have some textures that are, forexample the pitchfork 128x512 etc. :slight_smile:

Or, will 32x32 and 32x256 textures be unsafe?


Yeah, powers of two. And… heck, I’ve pushed some very basic images down to 4x4 or 2x2 if all I needed was, say, a checkerboard on a tiny surface, or some very simple stripes. That was with SL and the opensim, though. Dunno how HiFi would take to 2x2 images, but I’d HOPE it wouldn’t throw a wobbly over it.

This is in direct contrast to some people placing a 1024x1024 image onto a freaking pencil on a desk because “I want to make sure the quality on the whole build is as high as possible and some people might want to zoom way in!” Oo




I have a project on my roadmap that would do something along these lines, and additionally would pre-generate the mipmaps for a texture and do compression of the texture in a format supported by the GPU, so that texture quality could remain higher than it would otherwise in situations where we’re using a lot of textures.

No. NPOT (non-power of two) textures are supported by all modern GPU hardware, so power of two textures aren’t really a thing anymore. However, ‘page alignment’ is still important. As far as I can tell, on nVidia, all page sizes seem to be 128x128. I haven’t tested on AMD yet, but I suspect it will either be the same or smaller.

Having any dimensions smaller than the page size is fine. Technically, anything larger than 64x64 will basically take up two sparse pages (one for the base level, and one for all the mipmaps), while anything smaller than that will only have one page (all the mip levels, including the base level) can fit in a single page. However, at the moment we don’t use sparse textures unless all the dimensions are greater than the page size.


Uhmmm, do we now have a problem, because i use textures with power of 2. like 128x64 or at least thew round numbers. 512x1024 256x128. Also found one texture with wrong format that sneaked in. Would be problem if things need to be readjusted now.


I’m not saying you can’t use power of two textures, just that the dimensions don’t have to be power of two. 512x1024 and 256x128 are both fine because they’re both evenly divisible by 128 in each dimension. 640x1024 would also be fine, even though 640 is not a power of 2, because it’s still evenly divisible by 128.

However, a 500x500 texture is bad, because 500 is not an integer multiple of 128.


Ok, thanks.
i always resize textures in the common used formats. 16. 32. 64, 128, 256, 512, 1024,


One of the neat things about SL was that it’d take a 500x500 texture and, at upload, quietly convert it into a 512x512 texture. I suppose there could be some mechanism built into the prepare-this-content-for-hifi pluggin/converter that would notice when a given texture isn’t one of those multiples-of-128 (or multiples-of-32, etc) sizes and ask if you want to adjust or replace that texture accordingly.


Not really nathan. in many cases the texture can be put inside the FBX. SO that would mean more work. or you need to convert it every time the object get loaded.

Better is to learn users how to resize it in Gimp or any other program.


Well, what I was talking about is… imagine if the pluggin that generates the FBX file in your 3D-object-creation-program, when you go to save out / export as an FBX, automatically notifies you that the textures you’re placing into the object are nonstandard sizes, and gives you the opportunity to rectify this, or lets you simply say “No thanks” and leave the graphic images unchanged as it saves it.


Great news!
As I understand this it would allow textures larger than 1024x1024 the size I see mentioned in this forum as the maximum size allowed.
Larger sizes make a lot of sense for atlasses and would help reducing draw calls. Is this already implemented? and if not, could you give an estimate when to expect this?
I tried to find info about the max texture size and as about the amount of textures allowed by the shaders but didn’t manage to find it. Maybe someone can help me out on that. Also I was wondering if displacement textures could be used by a custom shader.

thanks for any reply


As far as i know we don’t have a maximum texture size. However we now have these settings on by default

These seem to make the textures blurred which does make the fps higher.
I would like to get an understanding of how it decides what to blur and how to tailor my textures so they don’t get blurred by the engine.

Like you suggested a great big texture for the ground doesn’t seem to me like a bad idea.
But I really don’t know what optimum texture size looks like. I imagine to be subject to a decent uv as big as it will go before it looks pixelated and bad. I don’t see why there would be a difference between a 4k texture against 4x1k textures.
@Jherico can you shed any light on which direction we should go with textures ?


I guess that depends on how big the “ground” is. If it’s 64 meters across, then a large texture would work great for fine detail. If the “ground” is one entity the size of the entire domain across, then even the biggest texture you can cram into the system is still gonna come out looking pixelated. I suppose eventually we’ll have things devised to work similarly to how SL does it: apply small textures laid out against each other randomly selected across the whole surface of the ground, with different ones applied at different heights of the landscape.

EditL Then again, I was assuming one texture applied once to the entire object (say, a satellite picture of a city layout), but I guess if you apply a tileable texture across the whole thing with a very large repeat factor – say, a stone texture or a grass texture – it’d probably look fine no matter how big the entity.


Remember, bigger textures = bigger file size = longer download time for users and it need more badnwidth server side.

So far i know textures where limited to somewhere around 1400x1200 pixels in the past. at least in that time you did see some warning in the log.


Is it better to have 10x1k textures or 1 x10k texture?


Why not a 5kx5k … :grin:


Hello Judas, Nathan and Richardus, thanks for replying.

The use i had in mind was to use the bigger textures for combining objects in to 1 big mesh.
Caitlyn made a nice blog about draw calls ( ) so combing 16 1K1K textures into 1 4K4K would increase performance dramatically for the objects involved without adding any need for extra bandwidth.

Does any of you have a clue if there is indepht documentation on the shaders we can write?


Yes, sometimes 4096 would eb nice to bake one wall of building as one texture.
Simple because ii lose all details with smaller ones.

@Caitlyn , What is the max. texture size, high fideity support ?

But there’s one side effect with bigger textures. the eat more GPU memory to.
So people with less memory get faster automatic scale down on textures,