Quest for billboards

I keep coming back to an ancient problem I have for my game which is sprite billboards. I'm doing a sprite based fps game (think of Doom 1 or Blood) and of course I require to use a lot of billboards for many elements of the game, from enemies to items or just simple props.

I'm using the common way to have working billboards which is rotating codewise the sprite facing the camera but that brings up some other problems, I'll try to list pros and cons of this method:

PROS
-Is a fairly cheap calculation that can be culled in case sprite isn't on screen and stop the rotation if needed
-Doesn't require shaders to be made on prupose of billboarding

CONS
-Things like enemies that need their own direction to move around can't have the billboard on the same object
-Forced to make the billboard sprite a child object to avoid main object rotation
-Pain in the ass for references on component with split objects like that especially for 8 direction sprite animation sheets

Of course this method is fine, it works, it batches and doesn't weight much on cpu. Still I'm looking into alternatives if they exist to try simplify it and make it more pleasant to work with.

Main problem to try solving is the child gameObject needed to avoid main one to rotate. First idea is to use a shader, which I have been looking into and end up always with the same old problem which is losing the ability to dynamically batch the sprites.
My second idea which I didn't try yet was to have a "fake" transform for the sprite that get the mesh vertices and rotate them instead, based on main gameObject transform, but I have no idea how performant could this be or how I could approach this.

Other concerns is about overdrawing, as of now I'm using Unity sprites to render stuff which I wanted to replace going back to meshes. Using a simple quad would be enough but I'm worried about overdrawing with many transparent elements (which could be up to hundreds at once) and making a slicing tool I have no idea how.
Before anyone ask, here the reasons why I want to stop using Unity sprites:
-Split componets for rendering (SpriteRenderer to deal with)
-Split shader types which in the end would do the same damn thing
-Runtime sprite creation requiring a texture in the overload which brings more problems: since my game is all runtime "created" assigning the sprites becomes a long process as they are sliced on the spot by assigning the texture and have unity do the work. This also limit texture swapping of the sprites externally as the rects depends on the texture size, if for example I want to switch a texture with ah igher resolution one without rebuilding the sprite rect it will not work, and thats where normal meshes are mroe handy working with just uv coordinates.

But anyway I'm done, if anyone has time to waste to read this and give a hand would be great.

Thanks.

 

might be of interest: