Sign in to follow this  
rick_appleton

Repeating textures in a texture sheet ... impossible?

Recommended Posts

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?

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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





Share this post


Link to post
Share on other sites
Quote:
Original post by SimmerD
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.

I stand corrected. Should have looked at the docs, I'd always thought it meant a dependency on a texture read rather than just on pixel shader math but I don't know now where I got that idea from...

Share this post


Link to post
Share on other sites
Well, perhaps because all ps.1.0-ps.1.3 dependent texture operations and fixed function embm involved texture fetch first, and then another dependent read.

Your definition is the way it *should be*. You really shouldn't be doing dependent reads in a pixel shader unless they depend on some non-constant, non-linear quantity that changes per pixel ( like the color value of a texture at that pixel ).

Typically, unless you are trying to improve batching, constant values should be precomputed on the CPU, and linear values should be computed in the vertex shader and passed down.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this