Before we dive into how batching can save us draw calls, let's explore a useful tool that can help us to determine how batching is affecting our scene—the Frame Debugger.

We can open Frame Debugger by selecting Window | Analysis | Frame Debugger from the main window or clicking on the Frame Debugger button in Breakdown View Options in the rendering area of the Profiler. Either approach will open the Frame Debug window.

Clicking on the Enable button in the Frame Debug window will allow us to observe how our scene is being constructed, one draw call at a time. The following screenshot shows the user interface of the Frame Debugger, with a list of GPU instructions in the left-hand panel and more detailed information in the right-hand panel:

There is a lot of information in this window that can provide us with useful information if we want to debug the behavior of a single draw call, but the most useful area to look at is the Drawing section in the left-hand panel, which lists all of the draw calls in our scene.

Each item in this section represents a unique draw call and what was rendered by it. An amazingly useful feature of this tool is the ability to click on any one of these items and immediately observe only the draw calls needed to render the scene up to that point in the Game window. This lets us see visually the differences between two sequential draw calls. This can make it easy to spot exactly which object(s) were rendered by a given draw call. This can help determine whether or not a set of objects were batched together by looking at how many of them appear during that draw call.

As we can see in the preceding Frame Debugger screenshot, one draw call is being consumed to clear the screen (the item labeled Clear), and then our eight meshes are being rendered in eight separate draw calls (the item labeled RenderForward.RenderLoopJob).