Setting a cameras DepthTextureMode breaks dynamic batching - is that right?

Hey guys. I have a scene with 100 cubes. If my cameras DepthTextureMode is set to none, I have 1 draw call with 99 saved via batching.

Now if I set the DepthTextureMode to DepthTextureMode.Depth, I gave 101 draw calls, with 99 saved via batching. Basically, its 1 draw call per renderer on top of what it already rendererd (1 draw call (99 batched) + 100 draw calls).

Is this correct? Enabling the depth texture on the camera means 1 draw call per renderer?

Edit: The title is a little misleading, whoops… :frowning: I should have titled this thread something like ‘When DepthTextureMode is set to DepthTextureMode.Depth, dynamic batching does not take into effect when Unity is re-rendering a camera to generate the depth information’

Bump - anyone have any insight on this? I would report it as a bug but I am not entirely sure if it is how its supposed to work. I don’t want to waste Unity QA’s time! :slight_smile:

Report it as a bug anyway. AFAIK just rendering depth should batch as well.

Ok, thanks man! Going to create a repo project now

Submitted, it can be viewed here: http://fogbugz.unity3d.com/default.asp?660303_i6rcv9htb4e7mbof

Will post updated in this thread as it develops.

So, uhm, can someone look at this? It is still set to open.

Did you ever get a reply from QA that they could reproduce the issue? If not then this may have slipped through the cracks or is a duplicate of a known bug and they just haven’t bothered to mark it as such.

However I just made a quick test using the latest 5.1 beta that suggests this is fixed for all rendering paths except the old Legacy Deferred (light Prepass). In all other paths the cube test is batching down to a total of 3 or 4 depending on path, but Legacy Deferred isn’t batching anything at all, every cube in both passes is rendered individually! Not sure if that’s always been the case or not?

So might be worth waiting to see if 5.1 fixes the issue for you or if you need to use legacy Deferred then report a new bug using 5.1.

We’re having the exact same issue with unity 4.6.4 through 4.6.5 We can’t upgrade to unity 5 for stability reasons at this point in development. Is there a fix or work around?

I don’t use legacy rendering and have not checked to see if this bug was fixed in 5. Thanks for looking in to it and updating us! This fixes the issue for me.

I wouldn’t hold my breath for a 4.x fix.