Hello there, I have submitted a bug report (Case 903451) that is related to the 2D sprite system today.
This was the original description:
Case Description
- What happened
When placing my worksite items, I get spammed with:
Dynamic batching: index buffer destination is NULL (first IB byte 0 count 0 first vertex 0 offset 0)
Dynamic batching: index buffer source is NULL (first IB byte 0 count 0 first vertex 0 offset 0)
- How we can reproduce it using the example you attached
Run the Scene scene and select ‘’'Build WorkSite" from the menu on the left bottom (bottom most button). You can then drag the mouse over the terrain to place it (it can only be placed on the dirt and not on the grass, this is a game constraint of mine)
A quick summary of the setup:
//
The workSite being placed are a bunch of 'Furniture’s, one for each ‘Tile’ in the game. The workSite furniture is configured to look at neighbouring tiles and their furniture and adjust their sprite based on present neighbours (therefore ‘connecting’ visually as can be seen with the walls)
Choosing the correct sprite based on neighbours is done in the SpriteManager’s GetSpriteForFurniture method. It basicly appends the NESW characters to a sprite name and gets the sprite with that name from a dictionary. The dictionary is populated on Awake with a Resources.LoadAll call within SpriteManager.
//
Usually when a sprite could not be found by it’s generated name, I would catch that case on line 59 of SpriteManager.GetSpriteForFurniture. However, now I am getting these weird errors without a stacktrace from dynamic batching. Turning the batching off seemed to help but the errors returned (possibly after editing the source atlas png in which all the WorkSite sprites reside, not sure). It now throws the dynamic batching errors even without it enabled.
These errors are prossibly triggered by a programming error on my side, but I guess it should not spew out random errors midway in the rendering engine without a proper stacktrace in the first place.
After playing with it a little bit more, I found out what is causing the errors throwing:
The bug happens when a sprite that has no visible pixels (eg, a fully transparent, empty sprite) is assigned to the sprite renderer. When I edit my source sprite to have at least one visible pixel in each ‘subsprite’ from the multi-sprite sprite asset, the errors won’t show up again. That might be useful information for the bugfix ![]()
So, why do I want to spawn completely invisible sprites then? Well, I dont have a smart system in place that skips spawning sprites for neighbour combinations (see case description) that have no sprite, so I am just spawning empty ones. I did not expect Unity to break in this way with empty sprites ![]()