[RELEASED] GPU Instancer

Hi Sebastiano,

There are two issues with your shader:

(1) When ASE generates a shader which uses its SRP templates, it injects the GPUI setup pragma and the GPUInstancerInclude.cging above the LWRP include files. These should be below the LWRP includes since the GPUI setup method references Unity macros and variables:

Code (CSharp):

1. #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Core.hlsl"
2. #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Lighting.hlsl"
3. #include "Packages/com.unity.render-pipelines.core/ShaderLibrary/Color.hlsl"
4. #include "Packages/com.unity.render-pipelines.core/ShaderLibrary/UnityInstancing.hlsl"
5. #include "Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/ShaderGraphFunctions.hlsl"
6.  
7. //--------------------------------------
8. // GPUI Setup
9. #include "Include/GPUInstancerInclude.cginc"
10. #pragma instancing_options procedural:setupGPUI

We have updated our wiki document on this to reflect this issue.

(2) In the Unity Editor, you need to add a prefab with a material that uses your shader at least once to a Prefab Manager for GPUI to register your shader to its shader bindings. Since you are doing these in runtime, GPUI cannot register the shader as having a valid GPUI setup. We will provide an alternative method to this (possibly using the context menu) in the near future.

 

yes thanks for the recommendation! I actually realized both of them, but I believe that even following both cases, I still have to regenerate the GPU precompiled shaders (after I did that it worked)

 

Hi again. I finished implementing partitioned collision checking by using a quad tree and it works great, thanks again for the suggestion.
I was wondering if you had any suggestions for implementing your own detail system using GPU Instancer. My terrain system is made up out of chunks (meshes) and so generating positions for grass patches like I do with trees would easily require storing over tens of millions of instances. I'm not sure how Unity's terrain generates detail positons around the camera, but I was wondering if you had any input on this. Thanks!

 

Hello
Can you explain what that means? Why some of my prefabs show that and some does not?

 

Hi there,

You could try looking at the GPUInstancerDetailManager.cs and customize the generation logic for the GPUI prototypes according to your needs.

 

Hi there,

As the warning message indicates, the prototype you have added (highlighted in red) has a very low amount of instances in the scene, and GPUI is warning you that you would not gain much from GPU instancing when using this prefab as a prototype.

GPU Instancing gives you good results when there are many of the objects that you are instancing. For more information on this, you can take a look at the Best Practices wiki.

You can also watch the Prefab Manager Tutorial video in which we also talk about this.

 

Can i use Gpu Instancer combined with Mesh Animator?
https://assetstore.unity.com/packages/tools/animation/mesh-animator-26009

 

Hi there,
we have not tested GPUI with this asset, but most likely they would be incompatible.

 

​

Hi everyone,

We have opened a new forum thread for the GPU Instancer - Crowd Animations. This asset will provide support for using GPU Instancer with animated characters in your projects.

Please check the forum thread for more information:
https://forum.unity.com/threads/gpu-instancer-crowd-animations.669724/

​

 

Hi there!

I'm building some procedural decorators for a projects and quite often I'm in the situation where I have 1 pool (eg: 3000 units or so) for every decoration rule.
Yet, every decoration rule lets you pick among different meshes (random variations).
You don't know in advance how many instances of each mesh you're going to end up using.

Is there a way to support simple mesh swapping using the same pool from the same Matrix4x4? Maybe adding native API support for this, like you did for materials?

(I'm running into some issues with Amplify Impostors and, in general, with some parts of the code, had to change the source for unknown reasons (adding already existing keys to dict). Most of the issues are things like GPUI not distinguishing among a prefab and a prefab variation (they get added as the base prefab, so you can't have both the prefab and the variant as separate entities), and duplicated prefabs (that is, just pressing CTRL+D) being considered the same prefab. Another time, I haven't been able to make a prefab show up, no matter what. Reconstructing the prefab from scratch worked perfectly. Another time I launched Unity and the GPUI Manager was completely reset!
I can't provide any extra info, I may have conflicting assets in the project. Just leaving a note, maybe there's still some unhandled corner case scenario lingering around

I'm using the no-gameobject workflow.

 

Hi there,

We will add an API method to switch meshes at runtime. Currently, you can target the low level code to achieve this effect. You can find an example of how you can implement this in the example scene of this package.

As for your prefab issues, GPUI works by adding a component called GPUInstancerPrefab on your prefabs to keep track of its prototypes. Since this component references the data object for the prefab, duplicating the prefabs without removing this component on the new prefab may cause unexpected issues.

 

Thanks for the blazing fast reply, and for the example scene, I'm going to look into it right now!

Yes, I surely messed up something while I was still learning to use it, was trying to test normal instantiation, ECS and GPUI as alternatives when building a project using the same scene decorator (but different approaches)... and probably something blew up in the process

Yes, I know about that component, I already watched all videos, tested all the scenes and read about 30% of the whole available docs+FAQ (there's a lot, which is a good thing )

I'm still somehow stuck using LODs but pretty sure it's in the FAQ (while creating a LOD group, is there any difference between setting the LOD transition there or in the GPUI Prefab Manager?).

Is there a performance hit when using Impostors? by using some meshes (30K bushes and low-poly leaves) it feels like it slows down when using LOD0+a single Amplify Impostor when compared to just using a single LOD0.
Am I doing something wrong, or it happens because the mesh I'm instantiating is relatively simple (under 200 verts) so the overhead makes this not convenient?

 

LODs are usually a great way to improve performance further when using GPUI, and especially Impostor LODs.

However, impostors would be better when used with high poly meshes. You are right that the mesh you are using is simple enough that reducing it to an impostor LOD probably would not gain more than the overhang introduced by an extra draw call that would be issued for each LOD level.

 

Thanks!

I tested the sample scene, that's pretty interesting and inspiring for sure (thinking of a sketch-like world using 3D meshes instead of the typical sketch-like drawings - but probably could be obtained with a shader as well).

If I got it right, it continuously shifts all the meshes contained in the GPUI Prefab Manager to give the illusion of an animation.

I would like to do something different and would like to know if it's already almost-out-of-the-box feasible with GPUI.

Details:
1) Let's suppose I have a wall of bricks (which actually is a prefab of nested prefabs of bricks, each one with a collider and a rigidbody, to make the wall destructible - but this is not the point)
2) A brick is a single prefab (also in the GPUI Prefab Manager)
3) There are like, 6 different brick meshes to add some variation (I would also add random +1/-1 scaling on each of the axis to add even more variation - if it doesn't blow up the physical simulation. The pivot is at the very middle)
4) Without GPUI, I simply attach a script that runs at Start, picking a random mesh from a list, and kill the randomizing script (yes, I could have done it with a single script on the wall prefab by looping all the child bricks. I'm still experimenting, easy to refactor)
5) As a result, the wall visually has a lot of variation and doesn't simply feel like an array of copypasted bricks

I'd like to replicate this with GPUI, using a single brick prefab (without nesting LODs or more meshes inside), using the automatic runtime replacement, but maybe using variants and a buffer(stored in the wall prefab? Or maybe on a per-block basis?), changing the mesh and forgetting about it at start. In a way similar to the included example scene with colour/scale variants.

Would it be technically possible, or I should be replacing each block with a proxy, and instantiating randomly chosen block prefab variants?

I'd prefer to just keep it minimal, that is, just having a simple list of meshes from which the brick could pick at start time, without the need of creating any extra prefabs/templates/variants.

 

How do I get a list of the total instantiated prefab count through script? So that I can later remove them?

I see the total instance prefab count on the GPU Instancer GUI...just don't know how to access tehm and transfer them to a list through script?

 

Hi there,

I have two questions/issues:

1) I expect to drag and drop the prefab on the GPUInstancer manager once and then be able to share with the other team mates the bindings in such a way they don't have to interact with GPUI at all. We haven't figure out how yet, I am currently forced to chase people complaining for broken shaders and ask them to drag and drop the prefabs. Please advise (I noticed that the shader variants are re-generated every time, should I commit them? How are they used?)

2) The amplify issue is not totally solved yet, we are forced to modify the source code of the file. I am not sure if it's our fault, however regardless the issue, my real problem is that currently I want to be able to use the same shader outside GPUI too, how can I achieve this? Should I keep to versions of the shader?

 

Hi there,

The mesh switcher sample scene is intended to exemplify how you can switch meshes for all the instances of a GPUI prototype. Different meshes per instance is not possible given how GPU instancing works.

Using a variation buffer to change meshes at runtime would not work since the draw calls are issued for a mesh/material combination and the buffer can only change the material. Thus, to achieve the effect you want, all the brick variants must be defined as separate prototypes in the Prefab Manager. If you have the brick wall as a prefab, and the variations as children prefabs under it, then adding the variants (bricks) as prototypes would be enough.

However, an alternative is manipulating the vertices of a single mesh in a shader (instead of using a different mesh) and sending the parameters to do this in a variation buffer. But of course if your brick mesh variations are complicated, it could be hard to replicate this effect by manipulating the vertices in the shader.

One last note is that negative scaling would not work with GPUI because of the way in which matrices are calculated in its compute shaders.

 

Hi there,

you can manage your prefab instances in any way you like, and instantiate/destroy them at runtime through Unity as you normally would do without GPUI. If you enable the Auto Add/Remove instances option in the manager GPUI will track these changes and handle their rendering for you. Alternatively, you can also manually add remove instances through the GPUI API.

For detailed information on the ways in which you can use the add/remove feature, you can take a look at this wiki document.

 

Hi Sebastiano,

1) GPUI internally keeps track of the shaders it generates and if the original shader is modified it re-generates them. GPUInstancerShaderBindings is an internal object that keeps track of these shaders. GPUIShaderVariantCollection is referenced to keep track of which shader variants are used to include them in your builds. These are re-generated by the managers if lost, but they also help GPUI to keep track of which shaders should be used without you having to change the shaders on your original prefabs. In short, you should commit them.

2) When you have the GPUI setup directives in the ASE editor, since each time the shader is saved with ASE it re-generates the shader file, you would manually have to move the GPUI setup code below the LRWP/HDRP references when using SRP. Alternatively, you can omit the GPUI setup directives in the ASE editor and have GPUI auto convert the shader for you. Since GPUI would re-convert the shader when ASE re-generates it, it would save you the trouble of manually editing the shader code each time.

Please note that for the auto-conversion to happen, there must be a GPUI manager in the open scene. Please also note that since the original shader has been marked as setup for GPUI in your case, you might need to clear the shader bindings the first time you do this.

 

1) that's what I thought and we commit it, but it still breaks on other people machines, I'll keep an eye on it. BTW I still don't understand if I have to do something with the variants! (add in the list of the precompiled shaders)
2) GPUI auto convert it sounds good to me! Why isn't this true for shader graph as well?!

 

Hello, any fix on this bug : ArgumentException: Empty path name is not legal.

System.IO.StreamReader..ctor (System.String path, System.Text.Encoding encoding, System.Boolean detectEncodingFromByteOrderMarks, System.Int32 bufferSize, System.Boolean checkHost) (at <ac823e2bb42b41bda67924a45a0173c3>:0)

Has this one been resolved yet?
Thanks!

 

Thanks for the exhaustive explanation! That part about the negative scaling saved my quite some headaches in advance (is it in the FAQ already?)

Since I can't know how many meshes of a certain kind are going to get instanced, and since I'm using the no-gameobject approach, I'd have loved to not allocate a whole array of the bricks for each mesh variation.
Yet, as a workaround, I could just decide that the mesh gets randomly picked from different arrays, depending on which one hasn't been used in full yet. I guess that's the easiest way to handle same probability random mesh instantiation. Isn't it?

I understand this is not really the purpose of GPUI, but I guess a lot of people using GPUI with no gameobjects would have the same "same prefab and behaviour, different meshes" problem, since generally some variation is desirable when using big numbers.

So if you could add support for this not-so-corner-case scenario somewhere in the roadmap, I'd greatly appreciate that

 

Hi. I'm seeing a strange effect. I have a sword that's 1 meter long with the Instance Remover script running the Detail Instancing Demo. What's happening is the sword is removing instances as if it was infinitely long. When I lift up the sword, and entire row of instances are disappearing. I use SteamVR and Unity 2018.3.12 if that makes a difference.

Thanks in advance,

 

I just found out this is on sale! I was just looking at this as something I can really use so it turns out to be perfect timing for me.

 

I'm interested in using this on our PS4 game Honor and Duty: D-Day which is a PSVR title. We have one level in particular that is having some performance issues and I'm hoping this will help. We don't have thousands of prefabs so I'm wondering what the threshold is where you start to see an improvement. We probably have 100s of instances of certain prefabs so I don't know if that's too low to see a benefit.

 

Hi @sebas77
1) Since the GPUIShaderVariantCollection file is inside a Resources folder, it is not required to do anything extra. It should be included in your builds automatically.
2) ShaderGraph API does not provide methods to do an auto-conversion currently and classes/methods are changing very frequently. For example access to the class that let us make a custom node in 4.x was not available in version 5.x. So in short, ShaderGraph needs to develop further to be able to make an out of the box integration.

 

Hi @vinnygombici

GPUI does not have any known and unresolved bugs currently. Can you please provide the full error log (stack trace) so that we can see where the error is originating from?

 

OK. I thought the auto conversion was based on the generated shader and at that point had nothing to do with shader graph or amplify.
So just to be sure I understood correctly: with amplify I won't need to add the custom node, I just use the shader and GPUI will update it for me

 

Hi @NeatWolf
If what you need is to not to create a prefab for each variation, you can use the DefineGameObjectAsPrefabPrototypeAtRuntime API method. This lets you define a prototype at runtime without creating new prefabs. You can check the AddRuntimeCreatedGameObjects demo in the package for an example usage.

 

Hi there,

Nice idea! Looks like GPUI enchanted your sword

Can you please send us how you set up the Instance Remover and the type and size of the collider(s) it uses? So that we can test it on our end to recreate the issue.

 

Hi there,

It is important to first figure out what is the main cause of the performance issues. For example if the cause is that you have too many draw calls/batches or if you are getting spikes because of Unity's culling system, GPUI will help you. If your scene is suitable, you can also see benefits from occlusion culling, or you can further optimize shadowing by using different LOD levels for shadows or by setting custom shadow distances with GPUI.

It is not possible to say an exact number where using GPU instancing will start being beneficial. There are a lot of different factors that effect the end results. But 100s are usually enough to see an increase in rendering performance.

You can check the features and best practices for more information.

 

True. If you do not add the GPUInstancerInclude.cginc in the ASE shader, it will be auto converted. You can check the GPUInstancerShaderBindings file to see the list of shaders.
We are also adding a new context menu item and API methods to access auto-conversion without using GPUI managers which will be released in the next update. It will allow you to convert a shader with a right-click, or script it in custom editors.

 

Here are the relevant screenshots while running in play mode.
The null reference points to this line.. _hiZMaterial.EnableKeyword("HIZ_TEXTURE_FOR_BOTH_EYES");

 

Hi @rmon222

Looks like there was an index error for box collider calculations. Can you please change the following line and see if this solves the issue?
In GPUInstancer/Resources/Compute/Include/Collider.compute Line 46
from this:

Code (CSharp):

1. float3 k = BoundingBox[4].xyz - BoundingBox[7].xyz;

to this:

Code (CSharp):

1. float3 k = BoundingBox[0].xyz - BoundingBox[7].xyz;

I believe the null reference error is originated from the DetailDemoSceneController.cs which is because of the changes you made to the cameras in the demo. You might want to remove the SceneController object and set your new camera to the GPUI Detail Manager.

 

Hello developer,

I just bought your asset and everything seems to be working well except that the meshrenderer of the instances are disable when I run the game so I can't see the instance. I am using HDRP in Unity 2019.1 in case that this is important.

I have a school of fish made out of the instance that I added to your GPUI Prefab Manager. They are in the scene and I can see that your Manager have them, but in the scene as I said I can see that your manager disabled their MeshRenderer.

Could you help me please.

Regards,
Carlos

 

Unfortunately, changing line 46 above made it such that the sword collider did not remove any instances at all .

The null reference is solved by re-enabling the demo cameras and deleting the SceneController as you suggested.

The bigger problem of the collider removing more instances than expected is still there.

 

Also, I am trying to use a grass shader with wind that I created for HDRP but your instancer ask me to add the GPUIInstancer Setup Node, which I don't find in the Shader Graph. Where is this Node for HDRP Shader Graph?

Regards,
Carlos

 

I went ahead and purchased this and tried it on the level with the worst performance and I'm happy to report it made a big difference. I targeted any prefab with over 50 instances and had maybe about 10 prefabs which ranged from 50 to around 350 instances and it definitely brought the performance up. It's certainly a viable option for PSVR projects.

There are probably other rendering areas we could improve and I've used the profiler successfully for the CPU side but don't really know what I'm looking at on the rendering side. Can you recommend any good resources for rendering profiling and diagnosing bottlenecks?

 

Hi there,
by fixing the lines about the bounding box, the remover may now work too accurately. That is, to be removed, the pivots of the instances must now be exactly inside the collider of the remover object - and it may be the case that some grass instances have their pivots slightly under the terrain.

To solve this, you may want to use the Offset property of the GPUInstancerInstanceRemover component. Increasing this offset would result in a larger collider, you may think of it as scaling the collider up uniformly.

Alternatively, you could add another collider on your sword and mark it as "trigger". You can then set this collider to the remover and increase the size of this collider until you are happy with the result.

 

Hi there,

GPUI disables the Mesh Renderer components on the GameObjects and uses the DrawMeshInstancedIndirect API on the background to issue draw calls. So the disabling of the Mesh Renderers is the expected behavior.

Unity 2019.1 uses ShaderGraph 5, and the setup node currently is for ShaderGraph 4.x only. The reason for this is that ShaderGraph is still in development and the custom node classes are not public anymore in the 5.x versions. To provide support for ShaderGraph 5.x, ShaderGraph API needs to develop further.

 

Hi there,

You can use the profiler for diagnosing the GPU by enabling the GPU section in the profiler. Other than that, you can use the Frame Debugger or a separate tool like RenderDoc.

 

Thanks for the reply but I've looked at the rendering in the profiler, I just don't know what I'm looking at or what to look for. I was looking for some info on how to take what it shows and diagnose problems. Just looking for some info on what all the sections mean and what might be a problem and what is normal.

 

LouskRad,

Thank you for the answer. So why aren't my fish school appearing in the game? if your instance is using some call for rendering?

Regards,
Carlos

 

Hi! Loving the results that gpu instacer offers!

However I have this weird graphics issue and I don't really know whats causing it.

Could you please help Mee out? https://imgur.com/gagOe9E

The issue is coming from a point light.
Also I'm having this weird graphical issue related to ambient occlusion https://imgur.com/qW8zW0y

Using the ppb: detailed instacing ppp

 

For you interest I tried to do a build with Nintendo SDK 5.3.0 and Unity 2018.3.0f2 and got the following errors:

1.
Shader error in 'GPUInstancer/Standard': invalid subscript 'fogCoord' at Assets/GPUInstancer/Resources/Shaders/Include/GPUIStandardInclude.cginc(27) (on switch)

Compiling Vertex program with UNITY_PASS_FORWARDBASE DIRECTIONAL LIGHTPROBE_SH FOG_EXP2 _ALPHABLEND_ON
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_ENABLE_DETAIL_NORMALMAP UNITY_COLORSPACE_GAMMA UNITY_LIGHT_PROBE_PROXY_VOLUME UNITY_LIGHTMAP_RGBM_ENCODING

2.
Shader error in 'GPUInstancer/Standard': Fragment program 'fragBaseAllGPUI': HLSL Compilation failed.
(on switch)

Compiling Fragment program with UNITY_PASS_FORWARDBASE DIRECTIONAL FOG_EXP2
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_ENABLE_DETAIL_NORMALMAP UNITY_COLORSPACE_GAMMA UNITY_LIGHT_PROBE_PROXY_VOLUME UNITY_LIGHTMAP_RGBM_ENCODING

3.
Shader error in 'GPUInstancer/Standard': Vertex program 'vertBase': HLSL Compilation failed.
(on switch)

Compiling Vertex program with UNITY_PASS_FORWARDBASE DIRECTIONAL LIGHTPROBE_SH FOG_EXP2 _ALPHABLEND_ON
Platform defines: UNITY_ENABLE_REFLECTION_BUFFERS UNITY_USE_DITHER_MASK_FOR_ALPHABLENDED_SHADOWS UNITY_PBS_USE_BRDF1 UNITY_SPECCUBE_BOX_PROJECTION UNITY_SPECCUBE_BLENDING UNITY_ENABLE_DETAIL_NORMALMAP UNITY_COLORSPACE_GAMMA UNITY_LIGHT_PROBE_PROXY_VOLUME UNITY_LIGHTMAP_RGBM_ENCODING

Do you think this is resolvable or is it a more systematic problem?

Kind Regards,
Chris

 

Hi there,

Are your instances moving during runtime? If so, you need to Enable Runtime Modifications in the Prefab Manager, and also enable the Auto. Update Transform Data option. If your instances are still not visible at runtime, and if you are using a custom shader on your school of fish, it is possible that there might be a shader error. If this is the case, you can check this wiki link for setting up your shader.

 

Hi there, and thanks!

Looks like you are using Forward Rendering with shaders (or effects) that use camera depth/normals. In such cases, you need to use the version of the depth/normals built in shader that includes the GPUI setup. You can take a look at this wiki link to resolve this issue.

 

Hi there,

Form the errors it looks like the Standard Shader is not supported in Nintendo Switch. You might try using a different shader on your instances, but the real concern would be if the platform does not support compute shaders - or even if it does, there might be some platform specific restrictions (such as buffer limits, etc.) that could amount to a systematic problem.

 

I came around to testing this today. It works. Thanks.

 

Hi! I am unable to find the shader in the gpu instacer folder. Do you have a download link for the shader by any chance?

Also I am quite new to the rendering path and the benefits (which I am reading up on now). Which path works best with the gpu instacer if that matters at all.

Thank you for the very fast reply!