Jump to content

  • Log In with Google      Sign In   
  • Create Account


Material textures: to pack or not to pack


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
No replies to this topic

#1 theagentd   Members   -  Reputation: 549

Like
0Likes
Like

Posted 27 April 2013 - 06:43 AM

Hello.

 

TL;DR: Just jump down to the last paragraph. ^^

 

I've come to the point where I want to implement most of the features our material system is planned to support, and I suddenly find myself surrounded by lots of textures!

I have:

 - Diffuse + alpha maps, 4 channels (alpha is used for alpha-testing)

 - Glow maps, 1 channel

 - Normal maps, 3 channels

 - Specular maps, 1 channel

 - Gloss maps, 1 channel

 

In total I need 10 channels, which could be packed into 2 RGBA8 textures + 1 RG8 texture for optimal memory usage. However, I'm having doubts on the benefit of doing so due to the fact that not all maps are mandatory. Since I'm using deferred shading, almost all the data in the textures is just copied directly to the G-buffers. Memory bandwidth is a huge bottleneck here, and not all maps are needed for all materials. 

 

To reduce the number of shader permutations I intend to simply use a 4x4 "null" texture when a map isn't needed instead of a custom shader that doesn't sample that texture. Diffuse, normal and specular maps are almost always used while glow and gloss maps are much rarer. With that in mind, keeping the above 5 maps in separate textures could reduce bandwidth usage even more than packing since I could just replace a texture with a 4x4 "null" texture if it's not needed. However, this would require 5 texture samples instead of 3, although there would be less data sampled per texture so the total should be the same. Memory-wise, only the normal map is padded to RGBA, so it'd increase memory usage by 10% (10 ---> 11 channels).

 

 

TL;DR:

I guess it all boils down to a single question: Do the number of texture samples (from different textures) affect performance or is it just how many total bytes of data that is read from textures that affects performance? Texture access is very cache friendly.



Sponsor:



Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS