Graphics.DrawMesh/DrawMeshInstanced fundamentally bottlenecked by the CPU

@DanMeyer009 if it is coming in straight from your modelling app, then your individual grass meshes wont batch because they are (probably) seen as unique meshes. (even if they are visually identical). Manually instancing a single one at each empty position like you described will probably fix your issue.

 

@Prodigga When I export my meshes they all link to the same mesh instance in blender. It keeps my fbx files much smaller the link is maintained upon import into Unity as each objects renderer still point to the same mesh. Ran some quick tests using the list<Matrix4> overload and gave me some great improvements in frame time.
-First screen grab is from using individual Gameobjects (How I was originally doing it). Still batches a significant amount. Both are using identical materials with 10k instances of the object.
PS...ignore the half finished models....

-Second screen is when I'm using the DrawMeshInstanced. Note that my total saved batches skyrocket. Read that using DrawMeshedInstanced doesn't respect culling so everything gets rendered at once (Actually keeps my fps stable because it's predictable and has the added benefit that I don't have to limit the draw distance).


I do have my doubts that I'm using drawmeshinstanced correctly however. Since I am trying to render 10k objects I attempted to use a single list and got the error that I can only call 1023 instances in one shot so I had to split up my list and call drawmeshinstanced 10 times with 10 different lists to draw them all. Please tell me there is a better way to do that. So far I have to say this is pretty awesome. I never expected that much of an improvement. If anything it just made me have extremely high hopes for the new terrain tools. Unity Team keep up the good work!

 

@zeroyao I noticed that this was automatically handled in Unity 5.4. I can call DrawMesh thousands of times, each DrawMesh call using the same mesh/same material/different MaterialPropertyBlock's, and in the FramDebugger I could see the there were multiple Batched (Instanced) operations to draw my thousands of meshes. Take the exact same scene and bring it to 5.5, I need to start using DrawMeshInstanced and I have to populate my own MaterialPropertyBlock arrays 'manually', but my scene wont render because I now 'exceed the 1023 limit'.

A step backwards if you ask me?

 

Absolutely not, since if you use 'DrawMesh' it's still automatically batched (or it should be). But with 'DrawMeshInstanced' you have finer control and you can make ABSOLUTELY sure that you ARE using instancing.

Even the fact that you told us that you are exceeding the '1023' limit smells fishy to me. You should break down your scene into chunks, check those for visibility and only submit your visible meshes. If you are not interested in doing that just use 'GameObjects'.

But if you are doing what @DanMeyer009 is doing, I CAN assure you that you are doing it WRONGLY. For a working grass/tree system check out my systems. Even with millions of grass/trees you should not exceed more than 3000-5000 visible grass blades per frame, that can be sent to the GPU in chunks.

For some concrete examples check out my grass/tree system (the tree system is open-source). I would also recommend siggraphs and other research paper (I would also highly recommend the SpeedTree sdk documentation). You probably want to implement a tree/grass/terrain detail or want to render many animated characters (am I correct?) and there is plenty of info for that, using instancing.

I can assure you that this time, the Unity guys did an awesome job with the instancing, because I know how my grass/tree systems worked before the instacing support. At the moment I got at least a x5 (up to 10-15x) performance improvement.

 

Slow down, what I mean is why do I need to be told about a 1023 limit? Let me submit 3000 instances and, on the engine side, submit them to the GPU in lots of 1023 for batching. I'm still 'absolutely sure' of what I am instancing.

 

I am using instancing in my game Along Came Humans, see image bellow:



Each 'hex' tile on the planet is made up of 6 triangle submeshes - "Triangle Tiles". As seen in this image (ignore the animation, I am just reusing this gif to show the triangle tiles)

So, I have hundreds (and on large planet, thousands) of visible triangle tiles. The tiles on the planet do not change very often, but they *can* change at any time for any given reason. For this reason, static batching isn't an option because I would have to enter the batched planet mesh and insert/remove 'tiles' from the giant mesh and resubmit the whole thing to the GPU every time a change was made (which is slow as hell and causes a stutter every time the player does something, like place a structure on the surface).

In 5.4, every update my 'PlanetTilesetManager' script iterates every hexagon on the planet surface, and draws the appropriate 'triangle tiles' for each 6 of the traingles in every hex using DrawMesh.

If I am using a GPU Instancing compatible shader, everything is automatically Instanced. It doesn't matter how many elements I submit via DrawMesh, and the order in which I submit them doesn't matter either. Unity handles everything. It groups like meshes together, and draws them in 1023 'blocks' for me.

In 5.5 this doesn't work anymore. Now I am forced to do this weird micromanagement that I didn't need to worry about before and I honestly don't see what advantaged this level of 'control' gives me.

PS This is also why I am so excited for DrawMeshInstancedPersistant -the triangle tiles will be 'static' 'most of the time' on the surface of the planet, so it is a waste for me to have to call DrawMesh on everything every frame.

 

If that is the case, you must know that even in 5.5 it still 'should' be automatically instanced even if you are using 'DrawMesh', it should be exactly the same like 5.4. The 'DrawMeshInstanced' is only and addition and automatic engine batching 'should' still happen. (I haven't read anywhere that there will be modification to that part, in the release notes...)

If that is not the case I strongly suggest that you quickly submit a bug report before 5.5 is out so that the fix will be available in the final release of 5.5.

I made many reports at key rendering features and they all fixed them all, so you should do the same.

 

Making one call DrawMeshInstanced call per an array of 1023 objects is so much faster than making 1023 calls to DrawMesh. I agree that it'd be simpler if you could just submit an array/list as large as you want and Unity would take care of it, but it's not that much of a drag to handle it manually. If it was done automatically, there could be extra allocations and whatnot when the arrays would have to be split each frame.

 

I agree with the sentiment in the thread that if there's no downside, draw instanced should take any amount and do internal splits every 1023, as a feature request but only if there are no downsides.

 

@Assembler-Maze Ya that was strictly for testing purposes, I wouldn't be drawing an entire scene's worth at one time. And I have to second that internal batches would be nice but definitely not necessary. I've already been thinking about ways that I can implement a quick and dirty visibility system for my own culling. Great times are ahead.

 

'DrawMeshInstancedIndirect' would be very very nice indeed. Having to set those world matrices and pass them in, cause somewhat of some CPU overhead when drawing my grass, having to copy back and forward those matrices. I only need a Vector3 world position, and computing the scale and rotation procedurally on the GPU.

And for the maxcount of 500, i'd quote the manual:

"D3D constant buffers have a maximum size of 64KB. For OpenGL, it’s usually 16KB. You will reach this limit if you try to define too many per-instance properties. The shaders may fail to compile or, even worse, the shader compiler might crash. To work around this, you have to balance between the size of the batch and the size of per-instance properties. Defining UNITY_MAX_INSTANCE_COUNT with an integer before including any .cginc file allows you to limit the maximum number of instances an instanced draw call can draw. This allows for more properties per instance in the instance constant buffer. You can achieve the same result when using a surface shader with #pragma instancing_options maxcount:number. The default value of this max instance count is 500; for OpenGL, the actual value is one quarter of the value you specify - so 125 by default."

So, if we target OpenGL we should take that maximum '125' batch size instead of '500'.

 

I did a protoype grass renderer based on the DrawMeshInstanced with lists and the results is great. Low cpu use and fast rendering.

 

Coming from a traditional 2D pixel-art animation background (and being more of an artist than a programmer), I haven't even scratched the surface of what shaders can do for me just yet, but I know just enough to know something like this might be useful to what I'd like to do.

To be clear, I'm aiming to optimize drawing a huge number of terrain-tile prefabs (similar to what minecraft does with voxels) in various places in the world onscreen. This seems like it would be useful to some extent for that. Am I correct in my thinking on this?

After reading over the thing about C#, shaders, lists, and 1023 instance limits, I'm still trying to understand exactly what type of setup code I would need to draw a (virtually) unlimited number of prefabs with this? I would also need to procedurally rotate some of these prefabs before drawing them.

Could this even be used for that? Would I need a custom shader?

 

This would work good for your use. The 1023 limit is only per call of the DrawMeshInstanced function, you can do this as many times as you want. You can make lists of all your meshes, one list for each meshtype. and draw them like this.

if you need some of them rotated just rotate the Matrix4x4 in the list.
public static Matrix4x4 TRS(Vector3 pos, Quaternion q, Vector3 s); to make the position, rotation and scale of your drawn mesh.

 

@LennartJohansen

Thanks for your quick response! That clarifies things a lot.

Totally new to the Matrix4x4 thing though, and how it would relate to, say, a grid of tile prefabs, so may I go slowly and clarify first the steps I'd take to best-optimize something like this?

Alright, so if I'm understanding this correctly, the correct approach would be something like the following (in a new C# script):

1. (Prepare all prefabs for drawing by removing their MeshRenderer components in editor?)
   
2. Get all the prefabs in the view of the camera
3. Add these prefabs to smaller lists of 1023 instances each
4. Add these smaller lists to a large list
5. In the OnPostRender function, use DrawMeshInstanced to draw the non-rotated prefabs from each list, pulling from the larger list
   
6. Use a Matrix4x4 and DrawMeshInstanced to draw the rotated tiles

Does that sound correct?

I'm not sure if that would cover the optimizations that I would need, so any further advice would be great!

 

Think of Matrix4x4 as something you fill with data to pass to the graphics API without really worrying about how it works under the hood. I created a global array of Matrix4x4 in my C# class and I reuse it every frame. I send the latest data into my array of Matrix4x4 and then submit that using DrawMeshInstanced.

To use DrawMeshInstanced, you do not think in terms of prefabs and camera views. Think in terms of meshes and locations in the scene for those meshes. If you want to, you can concern yourself with camera view and implement your own custom culling to reduce the number of items to send to the graphics layer, but you don't really need to do that.

In my case, I have a C# class that manages each type of projectile in my game. There are not GameObjects and prefabs for the individual projectiles. My C# class has an array of a custom struct that I created for tracking location and rotation of each projectile, and my C# class computes movements and collisions for projectiles each frame.

Here is a video of my game using Graphics.DrawMeshInstanced to render all of the projectiles in my scene:

I intentionally cut my projectiles into groups of 500 for sending them into the API. Groups of projectiles (such as the 3 large blue lasers from heavy turrets) are pre-baked into a single mesh to further improve performance.

 

@ShilohGames
That's quite a cool-looking game you got going on there! Totally loving it.

Alright, I'm a little slow here, but I /think/ I'm following more now -- As I'm understanding it, what you're saying is that a Matrix4x4 is, in this particular case, a single transform's positional/rotational data of whatever mesh instance in your scene you want to draw, right? You store a limited (large) amount of these, then update/display this data each frame?

Still not sure if I'm following correctly, but I hope that's correct.

I'm still unclear, though, on how to use this in practice. I'd highly appreciate some example code showing how to use this DrawMeshInstanced command in the proper context if you could please spare the time.

Right now, I'm struggling with how to handle the collision data with this sort of thing being used as terrain. What could I do to optimize it in terms of collisions for a pretty decently-sized world? How are you handling collisions with your lasers? That seems like a lot of overhead, even if you are doing it all through code!

 

Each laser uses a raycast to look ahead about a frame's worth of distance to check for a collision. That is true no matter how a laser is implemented. I would need to do that if I set up an instancing pool (like in my recent video), but I would also need to do that if I set up individual game objects for each projectile and managed those with an typical object pool. Either way, each laser needs to do a raycast to look ahead for a collision. If a collision is found, there is logic for applying damage to the object the laser was running into.

There is no collision check for things hitting a laser, though. Lasers cannot be shot out of the air by other lasers. As such, there is no need for a collider or rigidbody on individual lasers.

Since lasers don't need to accept a collision, a laser (in my game at least) only needs a position, rotation, an a velocity vector. I can store that data for each laser in a struct and then create an array of that custom struct. All of my lasers can be defined that way. Then each frame, my code processing movement and collision checks for each laser, updating the data within the array of the struct as it goes.

Then to render the lasers, I wrote additional code to write the relevant data into an array of Matrix4x4. I use the SetTRS method on Matrix4x4 to set the position, rotation, and scale for each item in the array I wish to draw. Then submit that to the graphics API through DrawMeshInstanced.

To make it simpler, I don't worry about keeping the items in the laser projectile array lined up with specific items in the array of Matrix4x4. I use the array of Matrix4x4 as a re-usable submission blob. When I need to submit fewer than 500 items, I still use my existing 500 item array but I define how many items to accept in the DrawMeshInstanced command. This lets me re-use the same array every frame without any additional allocations/deallocations.

When I need I have more than 500 lasers, I submit the array of Matrix4x4 multiple times. I submit a full 500 instance batch, then I re-use the array of Matrix4x4 for the remainder of the group.

This stuff works great. I have scenes with thousands of lasers flying around where I easily get over 100 FPS.

 

If you need to use a typical object pool and a bunch of GameObjects, you can. For example, if you need to have collisions and physics working for all of the objects, you can do that. This will not perform quite as well as my instancing pools for my lasers, but this would give you the rendering benefits of DrawMeshInstanced while still being able to have game objects with colliders and rigidbodies.

What you would do is run a typical object pool, but remove the mesh renderer from all of the objects in that pool. The objects would be invisible, but could still contain colliders and rigidbodies. Then in your object pool manager class, enumerate all of the objects in the pool once per frame and grab the location and rotation information from the game object transforms. Use the location and rotation information to populate your array of Matrix4x4 that you submit using DrawMeshInstanced once per frame.

 

Has anyone done a performance comparison on using
CommandBuffer.DrawMeshInstancedIndirect VS the Graphics.DrawMeshInstance @1023 increments? Is there a big performance difference or is one just easier than the other? I wonder if the Graphics.DrawMeshInstance calls of the same mesh/instance combines the call for all the 1023 sets or if each is its own..

 

Also, as mentioned earlier, persistence in the instance drawing would be great. I want to be able to tell unity exactly when to stop persisting and take a new set of draw info so that it isn't constantly dumping info that will be the same for some time.

 

The feature is absolutely amazing for my case and help me get back a lot of memory. I can't wait to get the persistent version.

 

Agreed! Any news on the persistent feature @zeroyao?

 

And not only the persistent version.

There could be done significantly better improvements like DrawMultiMeshInstancedIndirect (OpenGL equivalent glMultiDrawArraysIndirect) where you can pack multiple meshes inside a single VBO and send multiple commands (DrawIndirectCommand with a instance count, a base vertex, a base instance and a vertex count) with one draw call.

But I think we'll have to wait quite a lot for that, it's clear that those not being useful for mobile they're on the secondary requirement list. After all for 2017 mobile got about 30 bills in profit while PC got 20 bills in sales. Why bother with pc with those mobile scores...

 

Thank God!

Something like Unreal's 'Instanced Static Actor' (if i can remember correctly) Component?

 

I'm literally flailing in ecitement. Can't wait! Any rough ETA!?

 

Sounds wonderful. If you guys could keep the non-Unity (aka mesh) Terrain in mind for this too, it would be appreciated.

 

Please please please consider that we might want to add or remove things from the batch at run time, an efficient way to do this without repopulating and resubmitting lists of data containing thousands of items would be grand. Maybe a method to append items and a method to remove a range of items from the current batch so we don't have to resubmit all our data and incur the marshaling performance cost.

Everything I'm hearing points towards a set and forget system which is good for some cases (grass, a field of asteroides, etc) but sounds like it'll be unworkable for anything that needs items added and removed from the persistant instance batch. (Ie Demolishing or placing some structures in a strategy game that is rendering a city with hundreds of structures instances, for example)

 

Thanks zeroyao, looking forward to trying it out when it is ready! Good luck!

 

Good luck zeroyao!

(I'd like to see some of Unity's internals exposed on Bitbucket or Github, perhaps we could get these sort of issues sorted out way faster and take the load off of the Unity team.)

 

Freaking give us the code!

 

AWESOME!

This feature really got me excited (we need it)! Good luck guys!

 

Hello!

Why not work Frustum Culling with DrawMeshInstanced (frustum culling before Batching)?
It's really do?
You can make it optionally when you call the function.
I think it will improve performance.

I can do my FrustumCulling, but I do not know how to solve this problem: http://answers.unity3d.com/questions/1287755/how-can-i-determine-that-a-invisible-object-can-ca.html

Sorry for my English.

 

Yea, we should have the frustum culling optional (just as an extra parameter) since we really want to have full control over how we instance stuff.

And yes, we should also have the possibility to see if an object is casting shadows inside a frustum. I am still trying to solve that issue, but I am kinda short on time and I found some (bad) workaround.

The complete solution to shadow caster culling is stated here, just that I don't have time to implement it (at the moment):
http://www.terathon.com/gdc06_lengyel.pdf

Maybe someone is luckier.

 

It looks like this might be part of the open sourcing of Unity's engine (Scriptable Render Loop): https://github.com/Unity-Technologies/ScriptableRenderLoop

Some insane stuff is going to happen when that is released

 

frustum culling may be faster on gpu, if Unity is testing this...

 

Yea, some other guys out there use a full GPU driven pipeline while others moved certain rendering systems that require a lot of culling on compute (anvil/frostbite/unreal).

 

Yes so we would probably be best of waiting for that. I'm sure Unity knows we want it.

 

Thanks for this. I was getting an intermittent 500 ms lag spike from GC in my render routines due to Unity's allocation of these planes. Now I am completely allocation free. Why are there not public NoAlloc methods for these types of things? This should be a standard practice, IMO.

 

Indeed and thankfully this will now feature in the next release. From the 2017.3.0b7 release notes... https://unity3d.com/unity/beta

 

I hate to bother anyone here, but could someone please provide an example of using this to, say, draw 100000 cubes/gameobjects on screen in various locations? Say these cubes were already placed in the scene, but you just want to replace their drawing with an instanced version -- what method could be used to do this efficiently?

DISCLAIMER:

I *get* the concept, but the biggest issue I have is that if I just call the function in a for loop and use Matrix4x4.SetTRS() as an argument, changing only that to match all instances in my scene I'd need to call, I can't understand how calling that in a for loop would lead to much performance gain since I'm still using the CPU for every instance... Would anyone be willing to clarify?

Also, what about depth-sorting -- is this handled internally, or would I have to handle that manually too?

 

is there any news on this? Every time i google i end up in this thread..
Also in regards to the SRP?

 

Bump.

Any update? I'd like to use Graphics.DrawMesh for some custom chunk-based rendering such as terrain, voxels, grass, trees etc. This is targeted at mobiles without instancing support, so being able to use Graphics.DrawMesh without unnecessary overhead would be very useful.

 

I'd be interested too