Is it possible to utilize iphone dynamic batching with "traditional" animated sprite techniques?

By traditional animated sprite techniques, I mean having an sprite sheet that I simply animate the UVs on over time.

I have an animated sprite class that accomplishes animations on a sprite sheet by doing something like this

renderer.material.SetTextureOffset( "_MainTex", offset );

The problem, it seems, is that calling renderer.material does a lazy copy, which means that the material on that particular game object is now an instance of the base material. Since my game objects all have "unique" materials now, the engine can't batch my sprites.

I was hoping to avoid having to batch my spites manually (through something I roll myself or something like Sprite Manager).

Basically, I guess, is it possible to set the texture offset without having the material be instantiated?

Answered: As suggested, modifying the UVs of the model instead of the texture instance offset worked. Without pasting my entire AnimatedSprite class, this is the bit that matters:

void OnFrameChanged()
{
    // split into horizontal and vertical index
    int uIndex = frameIndex % uvAnimationTileX;
    int vIndex = frameIndex / uvAnimationTileX;

    // v coordinate is the bottom of the image in opengl so we need to invert.
    vIndex = uvAnimationTileY - vIndex - 1;

    // build offset
    Vector2 offset = new Vector2( uIndex * tileUVSize.x, vIndex * tileUVSize.y );

    Vector2[] newUVs = new Vector2[ uvs.Length ];
    for( int i = 0; i < uvs.Length; ++i )
    {
        Vector2 previousUV = uvs[ i ];
        previousUV.x *= tileUVSize.x;
        previousUV.y *= tileUVSize.y;
        newUVs[ i ] = previousUV + offset;
    }

    mesh.uv = newUVs;
}

I haven't done enough benchmarking to know if this is significantly slower/faster than using something like SpriteManager, but at the very least it's plug and play into my existing feature set.

The problem is that if you modify the texture offset (and you were using the same material for all of your objects), it would change all of the objects' texture offsets (Since it'd be the same instance of the material class).

The only way to get around that really would be to modify the uvs of the models instead, which may or may not be easy