[Unity5] Graphics.DrawMesh with reflection probes

Unity Engine
1

I’m trying to render a large stack of items using Graphics.DrawMesh in order to avoid creating a GameObject for each item.
I have found that by default, meshes rendered using Graphics.DrawMesh ignore all reflection probes. (They use the skybox as a reflection source instead)
The only overload of Graphics.DrawMesh that does use reflection probes is the one taking an anchorProbe parameter. Unfortunately the only version of this overload does not take a transform matrix. It only supports position and rotation (but not scale)

Here’s a small code snippet illustrating the issue: (disable all but one Graphics.DrawMesh call)

[ExecuteInEditMode]
public class TestComponent : MonoBehaviour
{
    public Mesh mesh;
    public Material material;
    void Update()
    {
        if( mesh != null && material != null )
        {
            // Ignores reflection probes
            Graphics.DrawMesh( mesh, transform.localToWorldMatrix, material, 0 );
            // Ignores reflection probes
            Graphics.DrawMesh( mesh, transform.localToWorldMatrix, material, 0, null, 0, null, UnityEngine.Rendering.ShadowCastingMode.On, true );
            // Uses reflection probes
            Graphics.DrawMesh( mesh, transform.position, transform.rotation, material, 0, null, 0, null, UnityEngine.Rendering.ShadowCastingMode.On, true, transform );
        }
    }
}

Is this intended behaviour or is it a bug? If it is intended to work like this, is there any chance we can get an overload of Graphics.DrawMesh that takes both a transform matrix and a probe anchor as parameters?

public static void DrawMesh(Mesh mesh, Matrix4x4 matrix, Material material, int layer, Camera camera, int submeshIndex, MaterialPropertyBlock properties, Rendering.ShadowCastingMode castShadows, bool receiveShadows = true, Transform probeAnchor = null);

Cheers,
Hyu

2

This seems to be a bug.(Have the same issue) But thanks for the workaround with the right method call .

3

Perhaps there’s an ancillary problem that could be solved - What problems are you seeing with having one game object per mesh?

4

Graphics.DrawMesh is not necessarily going to be faster than one game object per mesh. From my understanding, every call to Graphics.DrawMesh is a separate draw call - where as separate game objects will be dynamically batched if they are under ~300 vertices. I was doing some work with asteroid fields a while ago and found that Graphics.DrawMesh was actually many times slower than just making lots of game objects.

5

Actually, from my experience, Graphics.DrawMesh uses the same dynamic batching that separate gameobjects uses.