Quick question about materials for procedural meshes

Unity Engine
1

Hi,

I’m creating a few procedural meshes in the editor with a custom EditorWindow.
Each mesh is assigned vertices, normals, tangents, colors, uv and uv2.

The meshes are created using the sharedMesh member of the gameobjects MeshFilter.
The first time I edit a gameobject that’s missing a sharedMesh, a new mesh is created and then assigned to sharedMesh.
So the meshes are unique, and not shared between the gameobjects.

Everything is working great for one gameobject, but if I add another object and create a mesh, the UV channel of both gameobjects meshes go haywire both in the editor and in play-mode IF they have the same material.

I can’t figure out why? If I duplicate the material and assign the duplicate to one of the gameobjects, the problems go away.

I really need to know if the properties for procedural meshes (normals, colors and so on) are somehow shared between different meshes if they share the same material?

If so, why is there no problem with non-procedural meshes sharing the same material and what do I have to do to avoid the problems?

Thanks in advance!

Anders

2

Too bad for me, it seems as if I’ve found the reason:
If I add enough vertices / attributes to disqualify one of the two meshes for dynamic batching, everything goes back to normal.
If I then mark both objects as static to qualify them for static batching, the problems re-appear in play-mode (but not in the editor).

Does anyone know how the batching actually works?
It seems that all other attributes continue to work as they should during batching except for the uv (or uv1) channel…

Edit: It looks worse than I thought, the vertices (which I transform in a vertex-shader) get mis-placed when batching is active. Is it impossible to batch a shader that moves the vertices, or is there some smart way?

Edit 2: Solved… The reason for all this trouble seems to be because batched vertices lie in world-space. In my shader I use one of the available inputs for creating a vector from the current vertex towards another vertex, and those calculations broke when the vertex was in the wrong space. It’s fixed now by using some other calculations…