UV offset breaks batching

having this in Start broke batching. comment it out and batching is correct. intended behavior?

GO.renderer.material.mainTextureOffset = Vector2(-0.5,0);

That’s not really a big surpise. X Y offset are on the material. If you change them you probably end up creating a new material.

sounds logical. thought it batched on the fly as there’s batching overhead per frame (these are dynamic GOs). probably could create a new material and assign it to all.

You can’t batch objects which have different materials. Changing the UV offset creates a new and different material.

–Eric

yep got it. sharedmaterial will work but i have some objects where i don’t want the uvs to move. so a second material it is if anyone’s hits this situation.

think i’ll just have the artist fix the uvs for mine tho :smile:

I still made this work for Touch KO. Someone on the beta list had asked me about this. Here is just a paste of what I sent him:

There are basically 3 approaches i would take based on what you need to to

  • Super Lazy: This is what we do in Touch KO. Since all of the crowd are on a fixed cycle, we animate the UVOffset of the main texture using SharedMaterial. The only annoyance with this is that is affecting the actual asset in the project, so it shows up as a change in your asset server if it ends up somewhere weird when you stop playing the game in the editor. But, it lets them all batch. We get them to offset their animations just by changing the UV layout. Some of the crowd cards are laid out in the first cel, some in the fifth cel, etc. This way they are not all animating identically at all times
  • Might be Taxing: Much tricker. You could actually move the UVs in the mesh using script. I haven’t tried this, but I wouldn’t be surprised if it would be very taxing for the phone. I would cache each of the UVs into groups based on what cel of the UV layout they are in at start to determine where they are at any given time in the layout.
  • Most flexible: Requires a little more setup. Just create different planes that have their UVs laid out in different cels of the texture and swap them in the mesh filter via script, or toggle on/off difference mesh renderers. For instance, you have plane1, plane2, and so on all through plane16 in a 4x4 layout. This would conceivably allow you though to have multiple characters laid out on one texture sheet that are all animated completely independently of one another. e.g. you have 2 characters on one texture in 4 rows: char1 idle, char1 walking, char2 idle, char2 walking. Char1 could be idling and char2 could be walking – the animation states would all be managed by you via script.
1 Like

For the reference, i just edited the UV offset of my cubes and its still batches.
And as an answer to this post, if you do the same command with sharedMaterial instead of material it will still batch, but the maintextureoffset changes the source texture’s offset and not at the time when it’s applied to the mesh.

there’s a good UV offset script in unity answers from http://answers.unity3d.com/questions/13316/how-to-move-uvs-of-a-mesh-so-you-can-have-two-text.html

Can probably fix this by first instantiating then using the instantiated shared material.

You’ve taken that out of context. If the cubes are all still using the same material, then of course. But changing the UV offset of a cube at runtime, as per the original post, will create a new and different material, preventing batching.

Because in that case you’re changing the material for all objects which share that material, and are not creating a new material. Which would be incorrect behavior, unless you wanted all objects to have the same offset, which you often don’t.

–Eric

Haha, I was reading that script and I saw the comment ‘blow this shiz away’ and thought it sounded like a comment I’d write. Then realised I wrote that.

To use that script efficiently in a run time loop you’d need to cache a lot of that, otherwise it would be horrendously slow.