BatchMan is a new tool, designed to batch skinned and static 3D meshes at runtime but aswell at edittime. It does by default work with any unity shader and aswell the majority of custom shaders. It lets you aswell specify which textures of a certain material should be atlased and batched. By default it looks for follow material properties: MainTexture, NormalMap, Illumination, Decal, Detail and Parallax, though, you can modify them depending on your need. If you wish, you can aswell just specify a shadertype, supply the maintexture and let BatchMan generate any further texture for you, e.g. properly packed normalmaps.
It properly batches the full geometry of meshes and, if wanted, can re/compute additional data like normals and tangents. It preserves animations, though, intuitivly only skinned meshes which share the same bone hierarchy can be batched.
For further performance increases, you can aswell build BatchParts, which will layout the geometry to be instantly usefull by BatchMan, saving costy milliseconds.
BatchMan is the perfect tool to generate dynamic optimized player characters at runtime. Perfect usecase’s are RPG’s/FPS’s where players keep equipping different visual gear which can be dynamically added and removed from a batch.
All in all, BatchMan is an allround talent which delivers proper batching at run/edittime for minor performance overheads!
Features:
Runtime and edittime batching
Skinned and static mesh batching
Animation preserving
Proper geometry generation
Supports any material
Supports batching of any bonus textures like normalmaps, detail, parallax, etc
Customizeable or just work
Full geometry batching
Leaves your source assets untouched
Dynamically add/remove meshes at runtime
Batch static/dynamic meshes to a single bone of a skinned mesh (for weapons, etc)
Includes transformation matrices if wanted
Intuitive editor and instant previewing
Dramatically decreases drawcalls!
UV based tiling/offset
Texture based tiling/offset
Material color by texture baking or by vertex colors
Shortcut (fast) batchpart generation
Upcoming:
Lightmapping
Atlasing only (besides full geometry batching) to support unity’s static/dynamic batching
Scene batching
Shortcut (fast) baking/batching
Version history:
1.1.1 (Upcoming)
Improved multi batching (via shortcuts)
Texture atlasing only (bake textures but dont combine geometry for unity’s static/dynamic batching)
Scene baking (bake textures but no geometry or both)
1.1.0
Material tiling/offset - Texture based / geometry (UV) based
Material colors - Texture based / geometry (Vertex color) based
Fixing out-of-bound UV’s, clamping, repeating, tiling, offseting with the techniques above
Runtime atlas implementation for noticeable runtime performance optimization
Improved unity atlasing
Improved multi setup of batchparts (via shortcuts)
All standart unity surface shaders converted to account for vertex colors
Heavy improvements to BatchPart inspector
Heavy improvements to BatchPart creator window
Heavy improvements to geometry batcher
Moved lots of methods to be extensions of Texture/Mesh classes
To receive instant access to BatchMan via DropBox (for pending packages), just mail your invoice number to our support. We will either give you a link and/or include you to the folder sharing list depending on your needs!
Well, there are of course quiet some limitations given from unity when it comes to batching of skinned meshes.
Those mostly consists of bone handling:
Meshes do have a bone associated with each vertex. The boneindices need to match those of the skinned mesh renderer.
A skinned mesh renderer with intact bone hierarchy must be supplied in order to work.
Meshes must have set a proper bindpose reflecting the bones of the skinned mesh renderer.
So to summerize what should be cared for and how BatchMan proceeds.
Specify a skinned mesh renderer which holds the bone hierarchy and root bone.
Specify which bindpose should be used.
Make sure your meshes do use the bones of that certain skinned mesh renderer.
BatchMans part.
4. Combine geometry.
5. Batch textures into atlases on a per shader basis.
(6. Dynamically add/remove parts)
For the first three points, batchman does already do most of the setup itself. The only thing you really need to care for is only batching meshes which do hold the same bones.
Tho, there is one exception to this, static meshes which would normally be rendered without bones and which wouldnt be animated. BatchMan grants the chance to set a meshes boneweights to one single bone which you can specify. This effectivly attaches the certain mesh to one single bone and is a perfect solution to equipping stuff like weapons.
The big problem with batching is materials. Are you building at texture atlas at runtime? For the bones, I’m still not quite sure how you are making it batch. I’ve seen a solution where it builds a new skinned mesh by attaching the all the skinned meshes together. That doesn’t seem like what you are doing though.
Why is batching materials a problem? BatchMan does use the shadername of a material to replicate it and batches any texture of it into an atlas. Furthermore, if you add a mesh using the same material, the textures of it get aswell atlased into the previously set up material. And yes, they are build at runtime fully dynamic.
As of material color, offset and tiling, aswell as lightmapping, those are not yet implemented, but will follow pretty fast in v1.1.
Acctually that comes pretty close to what im doing. There is no problem in batching skinned meshes as long as they all share the same bone hierarchy in their boneweight array. The bones are btw stored in the SkinnedMeshRenderer itself. So yea, as long as the mesh reflects those bones, you can simply continue and combine the geometry and it’ll work. Of course there are a few more tricks to get around some limitations but yea, thats basically how it works.
Im going to sell this tool underpriced, for only 25$, since I somehow feel that something like this shouldnt be too costy in order for everyone to use it since batching is a problem which targets close to any game. Feel free to get a copy and look into the source code after release, which is btw fully included.
How does this work with the Unity’s batching system and OC?
Also, how difficult it is to prepare an indoor scene (horror game taking place in corridors, rooms) for BatchMan?
how many extra drawcalls you had in your tests and in which cases.
How it works with unity’s batching system and occlusion culling? That somehwhat fully depends on how you set it up to work. For instance, if you share the produced materials by batching with other objects than you will be able to use unity’s static batching.
However, I’ve just noted a point on my list. I’ll implement the option in the next version to not batch geometry but only textures and respective mesh UV’s, so you can move the batching process to unity even more if you wish.
Occlusion culling is based on how much you batch together. Thats a rule of batching, the more you batch, the less can be culled. Thats something any batching tool has to deal with, unfortunatly. But yea, it fully depends on you.
As of preparation.
Edittime batching:
Drag in any game object you want to batch into the editor. Batchman will automatically fetch meshes and materials for you.
Adjust the positioning of the meshes inside the editor. (This will be automatically done in the next version if you want so)
Batch it, done
Runtime:
Group your objects to be under the object which holds the static batching component.
Run the game and done!
(However, I’ve just noticed that i disregarded transformation matrices at runtime, gonna add that fast)
Drawcalls? Same as in unity, every submesh with a material will produce a drawcall. Every mesh with its respective materials will be combined into one big mesh/atlas. BatchMan produces one submesh per different shader type. That means, if you use a Bumped Diffuse, Diffuse and Transparent Diffuse shader, it’ll produce 3 drawcalls. Im just talking about shader types here btw. Materials with the same shader type will be combined and atlased into one, means your textures get batched on a shader type basis.
Version 1.1.0 is now pending on the asset store! If you want direct access to it, just send your invoice number to our support and you’ll receive a dropbox link!
1.1.0 (Pending)
Material tiling/offset - Texture based / geometry (UV) based
Material colors - Texture based / geometry (Vertex color) based
Fixing out-of-bound UV’s, clamping, repeating, tiling, offseting with the techniques above
Runtime atlas implementation for noticeable runtime performance optimization
Improved unity atlasing
Improved multi setup of batchparts (via shortcuts)
All standart unity surface shaders converted to account for vertex colors
Heavy improvements to BatchPart inspector
Heavy improvements to BatchPart creator window
Heavy improvements to geometry batcher
Moved lots of methods to be extensions of Texture/Mesh classes
Hi a couple of questions and suggestions. I’m making a game for psm vita and having an issue with performance because of all the drawcalls. In my game I’m using some custom shaders I’ve written to move around a bunch of coloured glass blocks. The glass includes refraction and is a multipass shader so it doesn’t appear to batch automatically at all with unity. As a test I also combined all of my glass blocks into one mesh and then the performance was OK proving it is the drawcalls.
As a result your package sounds like a good solution to this. My questions are firstly would it be possible to recompile this package to run with Unity 4.3 as psm is currently using an older version of unity. Secondly how well does this play with custom shaders and will it combine meshes even if they have multipass shaders ?
My game has hundreds of glass blocks in 9 different colours. Each block currently takes 2 draw calls with it’s multipass shader. Would this package be able to combine the mesh even if the blocks were different colours and combine the entire thing into one mesh at runtime and make the entire thing 2 draw calls ?
Also what happens if the blocks have to be moved or some destroyed ? Is it suitable to batch moving objects at runtime and update the combined mesh ?
Also would it be possible to perhaps make a free trial version that is fully functional but displays a watermark so that people can test whether it is suitable ? Since most people would be buying this asset simply to improve performance of their project it would be annoying to buy it and then find out it wasn’t suitable or made it slower in their particular case for some reason. A trial or other way of testing it would solve this issue.
First of about unity 4.3, yes it does work on that version aswell. However, I acctually wanted to upload the pending version with 4.3 but somehow forgot to do that. Noted!
Using multipass shaders or custom shaders in general doesnt have any effect on batchman. Batchman by default works with any shader. In case you have textures set which are not used by unity by default, you have to specify them in the setup and batchman will include them. So acctually no setup at all.
However, keep in mind when combining multiple objects into one mesh, you effectivly only have one material and therefore any property set on it will be set globally for all the objects.
Different colours? No problem. BatchMan lets you prebuild so called “BatchParts”. You can either create multiple versions of your block which use a texture which’s color is lerped by the material color (this will clutter up the final atlas) or you can bake the color into the meshs vertex color array (perfect and saves space). However, last method will need your shader to account for vertex color. By default, I’ve included all vertex color counterparts for unitys default surface shaders. and getting vertex colors to work in your own shaders is not a big deal either. Its aswell fairly documented.
If I havnt said it yet, yes batchman can comine all your objects into one, leaving those objects with 2 drawcalls absolute.
Now coming to moving/destroying parts. Its generally possible. You would need to write a little support script which keeps track of the batchparts of each object. So if you add a glass you need to store the returned batchpart in order to remove it again. Moving would be nothing more than removing an object and readding it with a new transformation matrix. Which lets me get to the next point, I need to add the possibility to specify a transformation matrix when adding batchparts at runtime.
All in all, BatchMan does the job. However, I think it might need v1.1.1 to resolve some minor issues which I havent accounted for yet.
As of a trial, im always a bit scared of such since you effectivly give out your product for free. For an editor tool, a watermark does not really prevent people from using edittime features and neither does it prevent people from just decompiling your assembly. Gotta think about this.
On the other hand, 25$ (the price of 1.1.0) is not really much compared to what batchman delivers. Under normal circumstances a tool like this would be sold for 50-75$.
You don’t have to make a free version of the tool. Make a demo on what it can do .Eg. you mentioned its good for rpg combining equipment. Make a demo/video to show that workflow. What are the limitations? (Other than sharing same material).
You say it can handle tiling, offset. Do you rewrite the UVs in the combined mesh?
BatchMan features two ways of handling tiling/offsets.
Texture based : Simply tile and offset the texture by the specified values. This does effectively duplicate parts of the texture and might clutter up the final atlas.
UV based : An algorythm which multiplies the texture UV’s and offsets them by the specified values. It proceeds by inserting new splitting vertices on the UV borders. So if an edge is crossing the U border ( vertex a U = 0.9f , vertex b U = 1.1f for example) the edge gets split into two by inserting two vertices, one for the lower UV area, one for the upper UV area. This produces UV based tiling and offset within the UV map of the mesh and therefore doesnt need to mess with the texture, saving atlas space.
However, this algorythm might produce errors under some circumstances and needs to be fireproofed.
Limitations? It depends on what you are doing since the limitations are not fixed for each problem/situation and are carried along by unity itself. For most stuff batchman has rules of thumb/gotchas and not real limitations. Few of these are for example:
Different materials will produce one drawcall each (depending on passes ofc)
Combining geometry will break occlussion culling if huge parts of a scene are batched.
Constantly rebatching at runtime is considered performance heavy.
Batched meshes with the same material will share one material. (Obviously) Means material properties will be global for that certain mesh.
I acctually cant think of much more right now, but you see, those are more like rules already delivered by unity itself and stuff is acctually just logical and intuitive.
Hopefully it gets processed a bit faster this time.