Repeating textures in a texture sheet ... impossible?
Author
To avoid switching active textures, textures are sometimes put into a single larger texture sheet. This works perfectly for non-repeating textures, but I imagine it is impossible to do such a thing with repeating textures.
Am I right about that?
You could probably do it with fragment programs / pixel shaders but I doubt it's worth it becouse of additional instructions and basicly converting all texture reads to dependant texture reads.
No need for dependent texture reads, you just need to pass in the wrapping points as constants to the pixel shader and do the wrapping in the pixel shader. There's some extra pixel shader math to do but the resulting texture read is not a dependent read.
Quote:AFAIK only lightmap textures are packed into larger textures.
it can be done for all kind of small non repeating textures, for instance, GUI elements.
and I second _DarkWing_, I doubt it's worth it too... as long as you see a texture is used by a surface in repeat mode, don't pack it with others...
and you'll have to look at mipmapping and bilinear filtering too, not only texture repeat mode, it influences the pack or don't pack choice too.
if a texture can be mipmapped down to an arbitrary level, you probably wouldn't want to add it to a texture sheet, as nearby textures will "leak" into each other when you bring the mipmap level down.
you can still pack multiple textures together even if mipmapping and bilerp filtering are used though... by extending their borders, but this will only be worth it for a few mipmap levels.
as level 0 will require a 1 pixel border, level 1 a 2 pixel border, level2 a 4 pixel border, level 3 8, level 4 16, etc...
what's doable is compute borders for a few levels down (let's say 3, that's already a 4 pixels border, and group textures together taking into account their border colors, so nearby textures leaking into each other at lower mip levels won't be that noticeable (by this I mean: don't pack a bright green texture next to a dark red one)
EDIT: cross with mattnewport: didn't see it this way, well you're probably right... never tryed texture sheets with repeating textures...
Author
What exactly is the difference between a dependent texture read, and one that is not dependent? I thought it was only influenced by if the GPU can predict which texel you are going to nead. If that is so, I would classify the wrapping in the shader as a dependent texture read. Although I guess the result of the calculations is only a constant factor times the input, and therefore might be so easily calculated as to be non-dependent.
A dependent texture read is one that depends on the result of another texture read. If you look up a value in a texture and use that value as a texture coordinate (or to modify a texture coordinate) to make another texture look up then that is a dependent read. Just using pixel shader constants and math in the shader to modify or create texture coordinates without doing a texture lookup isn't a dependent read, though the texture cache might be a bit less effective if the resulting lookups jump around the texture.
Actually I believe a depedent read is one where the texture coordinates are modified in any way in the pixel shader before the texture is fetched.
from the directx docs :
"A ... dependent texture instruction is a texture instruction in which either:
src0 is a Temporary Register (r#).
dst was previously written, now being written again."
This is typically done by reading one texture, doing some math on the result, often with constants or texture coordinates, and then performing one or more other reads.
However, simply grabbing a set of uvs, and adding a constant to them in the pixel shader is also considered a dependant read ( and is a bad idea - this should go in the vertex shader ).
As far as wrapping goes, there is a demo about 'Texture Atlases' on developer.nvidia.com that shows how to use pixel shader instructions to achieve wrapping.
I wouldn't reoommend this, however. It's not always texture changes that are the 'batch breaker'. The reason to use texture sheets is that you have two or more objects that could be rendered together, except that they have different textures AND you are cpu bound enough to make this matter.
If there is any other renderstate that differs between the two objects, you can't render the objects together anyway, and the extra texture switch won't cost you.
Can you give more details on what you're trying to render?
from the directx docs :
"A ... dependent texture instruction is a texture instruction in which either:
src0 is a Temporary Register (r#).
dst was previously written, now being written again."
This is typically done by reading one texture, doing some math on the result, often with constants or texture coordinates, and then performing one or more other reads.
However, simply grabbing a set of uvs, and adding a constant to them in the pixel shader is also considered a dependant read ( and is a bad idea - this should go in the vertex shader ).
As far as wrapping goes, there is a demo about 'Texture Atlases' on developer.nvidia.com that shows how to use pixel shader instructions to achieve wrapping.
I wouldn't reoommend this, however. It's not always texture changes that are the 'batch breaker'. The reason to use texture sheets is that you have two or more objects that could be rendered together, except that they have different textures AND you are cpu bound enough to make this matter.
If there is any other renderstate that differs between the two objects, you can't render the objects together anyway, and the extra texture switch won't cost you.
Can you give more details on what you're trying to render?
If you plan to use non tiled textures for specific assets it can work well. You also require your artists to be aware of a non-tile policy on these assets. Of course this may require artists to divide up where they would tile into seperate polygons.
Author
SimmerD: there's no realworld example. I was just working on my trackgenerating code for a racegame when I realised this (the track texture will tile in one direction). I'm not actively trying to get this working.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
