GPU Instancing

Have you considered moving the tile sheet/map system to a shader?

And 5.4 should have texture array support!

 

thank you this is exactly what i ended up doing, i have outstanding performance.

 

Cool could you share with the community?

 

Eventually when its more polished, i still havent tested it enough

 

The API sounds great! Few requests though:

-A "count" parameter, so we could set it up to only use a part of the matrix buffer. Would save reallocating that matrix buffer all the time to fire off the draw

-A similair API but in a CommandBuffer fashion. Instanced deferred decals sound pretty sweet

 

Just to confirm 5.4.0b10 does not include a standard instancing shader, yet?

 

When do you plan to make it work on Android ?

 

The API looks great.
At some point, it would be nice to have automated split in batches of 1023 adjacent instances as well as an override that accepts separate TRS -- to offload the mono backend.

 

That's a good start, tho it doesn't allow us to have a per-mesh MBP. This means that in my game, I could use it for perhaps 30% of the machines (which is a good start, mind you!)

So these will be great : https://pbs.twimg.com/media/CJzcuixWEAAQpvQ.png:large as they don't have any per-machine MPB (which is used to modulate the glow), however, these aren't instanceable with that system:

http://hydra-media.cursecdn.com/for....jpg?version=d8cbca2a1ff2b8feb69b280869568ece

 

Despite having used MPBs for the last 3 years, I've actually got no clue what you mean here. Help?

 

This is great! My only request is to please change Matrix4x4[] to IList<Matrix4x4> so that I can re-use my matrix buffers when changing the number of meshes I'm drawing. Garbage collection will kill off my performance gains otherwise.

Thank you for your work on this feature - very excited to incorporate it into my application.

 

Nice! Made a small test with a rock model I had lying around. I don't know if I get any ground breaking performance increases but it seems to run at ok frame rates at least.

(btw, sorry for the potato quality but I feel like that's not our focus right now)

Scene is:
1x Dir Light
1x "Instanceable Object" that holds the rock mesh (250 verts/496 tris)
Everything else on default (lighting setup etc.)

then I just scattered a lot of empty objects (18432 to be exact) with ~random transforms around the scene which are not rendered directly but fed into the behaviour of the instanceable object.

EDIT:
@zeroyao: Two questions by the way
1. Is it possible to get hold of the built-in assets for the beta. I'm kinda new to Unity but I can't find them here: https://unity3d.com/get-unity/download/archive
2. Perhaps this has already been answered somewhere, but do you know when the next beta will be released? I guess this API (or similar) will be included in that. I would really like to try out instancing for a proper build.

 

To answer your first question, the built-in resources for the betas can be found at the beta page down below: http://unity3d.com/unity/beta

 

I've been running Cube Mark for a couple of years and just got scores from 5.4.10b.

5.4b10 Running 3 x @ 2560 x 1600 full screen on my PC. (DX 12)



Using combine static mesh utility to reduce draw calls.



Using the instancing shader.

And for comparison with the latest build of 5.3.4

 

I found the zipped instanced shader, as mentioned in previous post #114 to give it a test run in my Cube Mark app.

I was using the combine meshes utility in the previous version and tried it in DX12 in the 5.4 beta, found that it is a lot faster than 5.3.4.

Then tried it again with the instanced shader and because I was already using combine mesh the performance degraded, you might want to do a test in combine mesh's to see if it's a material with an instance shader.

So removed combine meshes and with the instance shaders got a slightly faster result than with combine meshes but only just. (see # 114 above).

The benchmark simply instances cubes with normal map shaders, once with colliders, without and again but with quads.

Would it be faster for the without colliders test to use the Draw Mesh Instanced function?

Also is there a fast way to 'instance' lots of colliders for instanced meshes?

 

Is the Instance shader provided with 5.4? I haven't updated yet but I'm interested to see it.

 

This post links to the one I used -> http://forum.unity3d.com/threads/gpu-instancing.376635/#post-2486837

 

This is exactly what I'd like to do. Either an IList<Matrix> or fixed array with a count is acceptable, similar to the SetVertices etc. methods that were added to Mesh in 5.3.

I would be very happy to never see a Unity API that takes a raw array without a count parameter again. These are terrible for those of us trying to fight the garbage collector.

 

On the road-map it says:

-> OS X and mobile platforms support might come in 5.4.

Is there any news on this, or work has not even started due to the fact still trying get stability for existing platform.

 

Imagine trying to a decalling system or similair. With the current API I'd need to reallocate the matrix array whenever the nr. of decals changes (say, a new bullet hole, could be really frequent). Rather I would like to just allocate one huge array, fill that in with the currently used decal matrices, and pass in the count of decals actually used. And yeah people who need to manually cull for some reason will have the same problem.

Command buffer API Sounds great

 

OS X support was added in beta 8.

 

It just adds a set of spinning cubes to a scene (to a spinning root transform) and monitors the fps -> https://arowx.itch.io/unity-cube-mark (WebGL)

What about adding colliders for instanced meshes is there a quick way to do that, I'm noticing a massive difference between the scene with colliders and the one without?

 

Do you know if it will be available on all platforms or if there are limitations (gpu, dx or opengl version ...). In case of limitation how will you handle fallback method ?

 

I'd prefer an API where I can specify a startIndex and count. This allows me to use the same pre-allocated array for different things. Only having a count parameter implies that it has to start at index 0, which isn't really that powerful.

 

If I understand this right you use SV_InstanceID and all the per instance data are stored in constant buffer. Wouldn't it be better to let us modify secondary (per instance) vertex buffer instead of constant buffer? I mean constant buffer is limited to 64KB. That's 1000 instances if they differ only in world matrix. It will be lot less in real world scenarios. Vertex buffer is limited to 128MB if I remember correctly. Not a big deal for sure, just a thought.

Also, am I doing something wrong or instancing doesn't work for unlit shaders + deferred? Standard instanced shader works ok and both work in forward rendering.

 

My game has wide areas. And bottle neck is always cascade shadow map.I dont care G-buffer pass. I want to reduce shadow cast draw call. Is GPU instancing applied in Shadow only renderer?

 

@zeroyao

I have a question about instancing but especially about SpeedTree billboards and objects that use light probes. Do you think that instancing/batching for billboards that use light probes will come at the same time when SpeedTree billboards instancing will be added? At the moment in 5.3 SpeedTree billboards that not use light probes (light probe usage turned off) are lit by one static ambient lighting 'snapshot' that is not affected by changes in ambient light source so it's impossible to use dynamic ambient lighting with them.

Do you think that we will see instancing for billboards/objects that use light probes in 5.4 or one of 5.4.X releases maybe?

Thanks

EDIT: I've just noticed this in the instancing docs:
"Objects that use lightmaps or affected by different light probes / reflection probes can’t be instanced."

Does it mean that objects/billboards that use light probes can be instanced already but copies of object X that are affected by light probe A would be instanced together and copies of same object X that are affected by light probe B would be instanced together too but in two separate 'sets'?

 

Sorry it took me so long but we have abandoned 5.4 for performance reasons. Instancing makes our game even more cpu bound for some reason... Anyway, here's the "unlit+deferred" repro project. There are two scenes, InstancingLit and InstancingUnlit. Instancing works for both scenes when forward rendering is used. And only InstancingLit works with deferred renderer. 5.4b14.

 

I've become a tad out of date. Where are we at in regards instancing being added to the standard shaders and speedtree shaders that are included with 5.4? Thanks.

 

Are you sure about instancing working for both scenes? Testing in b14 I find unlit doesn't instance in either forward or deferred.

As to performance I concur, its pretty poor, though hugely better than simply rendering all the objects with a draw call each. GPU usage is pretty low, its cpu that gets hammered with the 8000 gameObjects you have in the test. However I guess thats just how it is, since Unity is having to track the gameObjects to instance that means its iterating through all 8000 every frame to build the instances matrix array and any other MaterialPropertyBlock values.

It still feels rather high though, I wonder if anything can be done to improve it? I wonder if its having the gameObjects in the scene that is causing a significant overhead?

I suspect you could get much better performance by writing a custom commandbuffer or DrawMeshInstanced version that avoids using gameObjects entirely. However in general terms it wouldn't be quite as straightforward to work with as having gameObject transforms.

Edit:
As a quick test I added two methods to auto-rotate each capsule. The first method was to add a monobehaviour to each capsule gameObject that rotated on update, the second was to store an array of transform references to the gameObjects in your init function and in its update rotate the references. In both cases performance dropped from 55 fps down to 18 fps and 25 fps respectively.

This is not really unexpected, though still more of a drop than I would have expected. It suggests to me that in many cases one might want to perform the rotation in the shader instead of via a transform for so many objects. For example if you were making an asteroid field or something.

I can't help but wonder if what is really needed is an API to control the internal Unity instancing? Some means of say over-riding Unity so it doesn't iterate through all the gameObjects and rebuild the matrix each time, but instead allows developers to feed it the matrix array? Or to provide a list of gameObjects you want instanced if perhaps that could reduce some of the overhead?

I'm not sure, while it sounds attractive it might just make more sense all round for developers to simply write their own custom instancing system and shaders if they are running into performance problems with Unity's generic version.

 

Did you change the rendering mode directly on the camera? It probably isn't set to "Use Player Settings", so changing it in player settings does nothing. It works in forward for me (according to Frame Debugger).

The performance increase in the test scene is nice. Nice for more or less single-threaded renderer anyway. I mean I would be happy for this kind of improvement but we can't get anywhere near that in our game (game with hundreds of trees, rocks, bricks etc). I didn't perform the benchmark myself but I'm told it runs worse than the same version without instancing. I'm going to have to investigate it when I have time.

 

Ah, that's it, didn't realize you'd changed it on the camera. Yeah unlit works in foward.

How are you getting good performance normally? As I said I suspect for specialized cases you'll have to get more creative and not rely on Unity's generalized internal method. Though were have to wait for DrawMeshInstanced() to be implemented before we have a 'relatively' straight forward way to test. You could do it now but only via DrawProcedural() which means converting the mesh into computeBuffers and dedicated shaders.

 

We aren't It is an open world sandbox game where user can build pretty much anything. Draw call count can get astronomical at times. I was hoping instancing will help us but I'm told that's not the case. I'm assigned to a different project atm but I plan to get back soon and do proper profiling to see why instancing is so slow. Hopefully it is just a bug and it can get better.

Yeah, the more low level access we get the better. Custom instancing would obviously work the best. We'll see how it evolves.

 

I suspect it's the actual physics colliders, causing a massive reduction in instancing benefits.

Try Cube Mark (link in sig) and note that I run 3 tests one without colliders that gets a massive cube count and another with colliders (the third draws quads) that gets way less in the way of performance.

It's unfortunate that the PhysX system in Unity does not have the hardware acceleration mode available, although my understanding is that it works better or only on Nvidia hardware.

Potentially if you combine colliders or reduce their number this should speed things up a bit.

 

Pretty sure @Michal_ is comparing the same scene with and without instancing.

 

I hope nobody minds me asking this again.

 

http://forum.unity3d.com/threads/speed-tree-batching-bug.398911/

 

I note that there is still no real answer to my question, or even a clue, and its been about a month since someone from Unity posted in this thread. This makes me very sad, what happened?