[RELEASED] GPU Instancer

Hey, I don't have a ton of experience with indirect instancing. I'm curious if the following things will break GPU instancer instancing:

-A shader with multiple passes
-A mesh with multiple materials applying to one submesh

If these things do break instancing, do you have an idea of the most common workarounds?

Thanks a lot for your time!

 

Hi there,

Yes, you can use GPUI in both of these cases. In fact, one of the strong points of GPUI is that it allows the usage of Indirect instancing in such complex scenarios and simplifies this to a few button clicks.

 

Wow, that's pretty awesome

Thanks for the super fast reply!

Have you tried getting your instancing working with something like Microsplat's terrain-mesh blending?

I imagine it could be complex, since the Microsplat Implementation involves using material property blocks and two materials on a mesh with the second material using a generated shader.

 

Yes i fixed this part, but i edited my message, since i did that fix i had a news error ( on the last screen ).

 

Well, we have not tested with that specific asset, but if it uses instance based MPBs, it could require some work to make it work with GPUI. In any case, I can't guarantee if they would play along out of the box.

 

From the errors it looks the camera is not being set correctly. We can help you identify the problem and fix it if you send us a mail at support@gurbu.com with the lines of code that set the camera.

 

Is it even possible that GPU Instancer could support instance based MPBs? Is it an absurd amount of work/rewriting or is it something doable that you just haven't had the need/gotten around to implementing?

Very interested in building an art style around a lot of terrain/mesh blending, so would love to know if it's something I could implement on my own using GPU Instancer as the starting point.

 

it is definitely possible, and we have a demo scene that showcases this:

It is not much work in terms of amount, but could require a solid understanding of GPU buffers. We are currently experimenting on ways to simplify this process. We have an API method DefinePrototypeVariationBuffer<T> that you can use for this. You can check the method in our API documentation page.

Yes, sounds very interesting. Please let us know if you need any direction or have further questions.

 

Hello, is it possible to use a vertex pintеr (for variation) on individual instanced object (let's say 100 instanced brick objects in one brick wall, vertex painting modyfing color like clean or dirty bricks (or more better texture blending),...if that is possible with your sistem?,... would you show an example ... this would affect many people and opens an incredible "operating space."

 

Hi there,

If you mean to paint vertices on a mesh for variation, that is indeed possible and it would be a very good approach for variation on your instances. However, please have it in mind that because of the way instancing works, all the instances of a prefab are sharing the same mesh and it is not possible to have different vertex colors for the instances (of this prefab).

Actually, we use vertex colors for the default foliage shader as well, and the wind movements and color variations are calculated based on these vertex colors and world positions.

 

Hi everyone!

We have just submitted the v0.9.0 update to the Asset Store! This is a major version update and it includes many new features and fixes.

To start with, as promised, we are introducing SpeedTree support with this update. The v0.9.0 comes with a whole new manager dedicated to Unity terrain trees. The Tree Manager works just like the Detail Manager and it will grab the trees that you have on your Unity terrains and render them with GPU Instancer's indirect instancing system. All the GPU culling features (frustum, occlusion and distance culling) of course work for the trees that are registered to the Tree Manager as well.



To accompany the Tree Manager, we are also introducing a whole new 2D Billboard Generator system that will automatically create billboards for your prototypes and add them as the last LOD level in GPU Instancer's rendering pipeline.



Please note that the Tree Manager and the Billboard Generator system are currently in BETA, and they will be frequently updated.

Next up, we have the new Gaia Integration. GPU Instancer now integrates directly into the Gaia GX menu, and allows you to choose your prototypes directly from the defined Gaia resources. From the GX menu, you can add all the GPU Instancer managers (including the new Tree Manager).



Also, the v0.9.0 update includes the new Prefab Scene Importer tool that you can use to view prefab instances in your scenes and add a Prefab Manager to your scene with the selected prefabs defined as prototypes on it. You can use this tool to select the prefab instances with a minimum instance count as well.

​

For ease of use, you can now also add prefab instances in your scenes by dragging and dropping them to the manager as well. This will add the prefab (that the instance is of) to the prefab manager as a prototype.

​

We have also added new LOD options such as LOD cross-fading (with animation or transition width) and the LOD bias adjustment option that you can use to modify your LOD distances without having to modify the original prefab.

Furthermore, we have made massive improvements to the way prototype instances can be manipulated at runtime. The Prefab Manager now has new runtime settings for its prototypes that allow you to use these new features:

• When the "Auto. Add/Remove Instances" is enabled, the Prefab Manager will add a script called "GPUInstancerPrefabRuntimeHandler" to the prefab object and this will handle all runtime changes automatically.
• When the "Auto. Update Transform Data" is enabled, the Prefab Manager will detect the transform position, rotation and scale changes of the prototype instances and update them accordingly without the need to write any additional code. The updating of the transform data for the instances is lightning-fast, and provides full support for rigidbodies.

Also, you can now Instantiate the GPU Instancer prototypes without having to instantiate Game Objects. The new API methods allow you to pass in Matrix4x4 data to render your prototypes, which will allow you to get the most out of GPUI in a runtime generation scenario. We have also added a new scene to demonstrate how this works.



In addition to these, the new update also comes with various new API methods, better shadow rendering performance, a mobile version of the asteroids scene (with mobile controllers) and various internal code changes and fixes targeted to improve the performance of your scenes even further!

We hope you like the new update; it should be live soon for you to download.

 

does the demo builds have speedtree demo ?

 

Hi there,

We currently have demos for the asteroids scenes; showcasing prefab instancing with rigidbodies for multiple platforms. Tree Manager is currently in beta, and we have plans to make a combined demo scene with details and trees when it (the Tree Manager) is out of beta.

 

I'm currently experiencing bad results of 2FPS and 46482 batches as apposed to 60FPS and 1300 batches without using GPU instancer. I don't understand why its performing so badly. I have a procedural world made up of 1000 different game objects.

Does your solution only work on a few different kinds a game object mass duplicated with the same material? I was hoping to simply gpu instance my game objects to take advantage of the occlusion culling aspect.

 

Hi there,

This looks like you are not registering your procedurally generated game objects to GPUI. Things to consider are:

How are you registering your prototypes?
Are there any error/warning messages?
What are the amount of registered prototypes and their instance counts the manager is showing at runtime?

Essentially, GPU instancing works by sending mesh/material data to the GPU in a single draw call. This reduces the amount of batching to one even if there are hundreds or even thousands of the same mesh/material combination. This removes the bottleneck that occurs when sending mesh and material data from CPU to the GPU, and results in higher fps if there are many of the same mesh-material combinations. That is, GPU instancing helps in scenarios where you have many instances of the same game object.

GPU Instancer further builds on this concept by applying various culling and LOD operations directly in the GPU and rendering only the relevant instances on the screen. This is why frustum and occlusion culling systems included with GPU Instancer are designed to work with GPU instancing only. What they do is to reduce the number of objects drawn for each prototype that are defined on the GPUI Managers. So let's say you have 1000 instances of a prefab - to draw these, GPU Instancer makes only 1 draw call with the count 1000 (this count is stored in GPU memory). When you use frustum and/or occlusion culling, this count is modified in GPU according to culling results. So it makes 1 draw call with a count less than 1000 - and rendering speed up further because there are less objects that are actually rendered.

In short, it is GPU instancing itself, and not culling that reduces the number of draw calls. Instead, culling reduces the number of objects drawn with each draw call. So neither GPU instancing nor occlusion culling would help increase your FPS if the amount of instances are only a few to start with.

If you wish, you can send us an email at support@gurbu.com with the details of how you are using GPUI and we can help you from there.

 

hi,

gpu instancer will work in unity 2018 ?

 

Just bought the asset without knowing that it is not going to work with lightmaps..
Humm.. So If I bake my terrain, or mesh ground using lightmap and say have part of the scene covered in shadow, the grass that are instanced will be rendered using realtime light only?

I guess it is not going to pickup the ground shadow color ...? I am a bit confused on this.

Also, I am currently using static batching but I am not sold 100% that gpu instancing will be better.
Sending static batched mesh to GPU should only happen once at load time so I am not sure what the advantage is for the GPU instance other than saved memory? If the object count is really large, then maybe it can best the static batching, because it needs a lot more memory and more draw calls, but if the object count in the given screen is not so high, then wouldn't static batching be just as good in terms of performance?

 

This update sounds great! Can you please confirm that Skinned Mesh Renderer support is the very next feature you will work on?

I am really curious to see if we can finally get large counts of crowds on screen in a town for example (procedural game) with buildings acting as occluders and instancing taking care of the rest.

 

Hi!
Yes, GPUI works with all unity versions starting with Unity 5.6.5 and up. The latest we have tested with is Unity 2018.2.11f1.

 

Hi there,
Thank you for supporting GPU Instancer.

Currently, GPUI indeed does not support lightmaps, but recently Unity introduced support for lightprobe usage with GPU instancing. We are currently working on integrating this to GPUI and will add this feature soon.
In its current state, you will get the best results from GPUI in deferred rendering and realtime GI. The limitations for forward rendering and GPU instancing were removed by Unity in versions 2018.1 and up, but still deferred would be faster if you have multiple lights (because of the g buffer).
The GPU Instancing support is being constantly improved by Unity and as its limitations are being eliminated, we are also making improvements to the GPUI workflow.

There are multiple reasons why you might want to use GPUI over static batching:

- As you said, memory is a concern if you want to have a massive object count.
- Static batching works by combining meshes, so frustum and occlusion culling cannot work on the statically batched objects.
- Because of mesh combining, you are limited to 64k vertices per batch (and even less on mobile platforms).
- Any runtime transform modifications would break static batching; so you can't use rigidbodies on them or update their transforms.
- Using static batching with procedural, runtime generation scenarios would be much slower since you need to mesh combine real-time.

In short, in static batching your Game Objects indeed need to be static and this brings further considerations on top of these as well. On the other hand, using GPUI, you can even use a no-game object workflow and still have much control on individual instances without compromising performance.

 

Thanks!

I can indeed confirm that skinned mesh support is in our roadmap as the next big feature update, but it is still early to give a definite release date. We do have other improvements and smaller features we are currently working on, but these are mostly designed to improve the core system and they will add to the power of instancing skinned meshes as well.

 

I believe that Unity static batching disables rendering of the gameobject that are out side of frustum, thus not over rendering them. However, I am not 100% sure what happens internally when static batched objects are not drawn. On the outside on the inspector the combined mesh does not change, but maybe internally the polygons are flagged somehow to not draw.. Or maybe internally they rebuild mesh to not draw the ones that are out side of frustum ? If this is true, is this why you think static batching is slower? I use static batching in run time, but only during loading time and it is pretty quick.

 

Also, I was wondering why prefab instances can't be occlusion culled? The only detail ones seems to have this option.

 

Well, I don't know for sure what Unity is internally doing for statically batched meshes either - but I'm pretty sure they internally provide some optimizations on the combined meshes that would allow for a similar effect to frustum culling. The description for the StaticBatchingUtility class indeed states that in effect, objects are being culled individually. However, for this to be possible, some sort of a manipulation on the statically combined meshes must be at work - and this sort of manipulation does not exist when you use GPU Instancing. The former would definitely be slower when your object counts are massive.

In any case, the reason why I said static batching is slower than GPU Instancing when the object counts are massive is empirical. We have tested the same scenarios with both static batching and indirect GPU instancing and the latter was always faster in modern GPUs.

Also, the fact remains that the objects must be static in static batching, and you have the freedom to update them in GPU Instancing. This case is added upon when you consider our hi-z occlusion culling solution:

You can use occlusion culling in the Prefab Manager as well. There is a global setting, and if it is not disabled globally you can see the "is occlusion culling" toggle for the individual prototypes as well:

​

 

This asset looks very useful.

I see source code is provided, which is great.

I've been doing some custom rendering work using CommandBuffers to draw objects in a customised way into the Unity gbuffer.

Do you think it's feasible for someone to modify your Asset's code to draw at that point in the pipeline using a CommandBuffer.DrawMeshInstancedIndirect call rather than the Graphics.DrawMeshInstancedIndirect call? If I made a modification like that, would things like occlusion culling still work, or could there be a lot of problems doing that?

I have something working with CommandBuffer and DrawMeshInstanced, and am now turning my attention to culling... if I could use your asset to do that work for me, it would be fantastic.

Thanks for any insight!

 

Hi there,

With a few fairly straightforward changes, you can indeed use a CommandBuffer and keep the functionality of GPU Instancer. Please note, however, that any GPUI update would of course break your changes and you would need to re-do them. Also, you might need to have two buffers: one for meshes, the other for shadows.

If you need guidance on where to look in the core code while doing this, you can send us a mail at support@gurbu.com and we can direct you to the necessary lines.

 

Thanks so much!

 

I have a really big question here I thing some people might share.
The thing that attracts me the most about this system is the possibility to have all the speed trees cast their full shadows at a distance. That makes the realism of the scene stand out. Will that be possible. Will a scene cast the shadows of thousands of densly populated speedtrees?
Thanks

 

Hi there,

This is indeed possible, and more than that, it is in our roadmap. For the v0.9.0 update, we have seperated the main rendering system from the shadow rendering system. Currently the managers do not provide options that you can change the shadow settings, but as we develop the Tree Manager, we will be adding various options for you to use. This will of course not be limited to the Tree Manager as well.

The system will provide settings for shadow distance and quality based on which LOD to use for shadow, etc. Of course, the decisions you make with these settings will both result in higher or lower quality shadows, and their performance will change accordingly.

 

great news!

 

Glad to see the rendering without gameobject stuff I emailed you about to make it in! I recently modified the code to support animation using animation baked submeshes. Would something like this be part of the asset soon?

 

It looks amazing, great job!

Do the foliage and the tree shaders work only on the Unity terrain or can we use them on any mesh? For example, on runtime generated procedural meshes?

 

Sure. We have plans to add some new API methods soon to make switching meshes at runtime easier. For now, you can have a look at this example to see how you can make animation with baked meshes using the internal variables:
https://gurbu.com/gpuinstancer/demopackage/GPUI_MeshSwitchDemo.unitypackage

 

Thanks!

You can use all of the included shaders by creating materials and assigning them on procedural meshes. And if you are not using a Unity terrain, you can use the GPUI Prefab Manager for your vegetation. Prefab Manager does not have to use prefabs if you set the instances from code. So it is possible to use runtime generated meshes-materials as a prototype for the PrefabManager with a few lines of code.

Many of our users are using the Foliage shader for their custom grass meshes, and we saw some really good examples.
For trees, most of the included shaders are there to support indirect gpu instancing for built-in unity shaders. Except for the default Soft Occlusion shader, where we added wind effects to make it look nicer. And there are also some other shaders for rendering Tree billboards.

Also, since v0.9.0 update, there are API methods to render objects without instantiating GameObjects. This saves a lot of memory and speeds up initialization times, also it is very optimized to make runtime updates. It might be a good choice for dense vegetation without a terrain to go with a no-gameobject system.

 

What does "It will not accept prefabs that are generated when importing your 3D model assets" entail? Aren't most prefabs going to be generated from 3d models that have been imported?

 

Am keen on getting this but does this entail that each object added to the GPU Instancer manager would need to have materials that have the GPU Instance checkbox? i.e. each material would have to have a compatible shader?

 

Hi there,

There are 2 different kinds of prefab assets:
1- First one is a user created prefab, which is created in unity editor when you create a prefab from a GameObject: PrefabType.Prefab
It looks like this in the editor:


You can find the prefabs in your project by searching "t: prefab" on the search box:


2- Other one is a model prefab which is created when you import a 3D model asset to unity: PrefabType.ModelPrefab
Imported models look a bit different and SpeedTrees have their logo:


You can find the model prefabs in your project by searching "t:model" on the search box:


Prefab Manager requires user created prefabs (first one), because it adds scripts on it to manage runtime modifications. It is not possible to add scripts on ModelPrefabs. You can create Prefabs from ModelPrefabs by dragging and dropping one from the Hierarchy window to the Project window. Then you will be able to add them to the Prefab Manager.

Note: It is also possible to use Prefab Manager without prefabs, but it requires coding. Because it can not keep track of the instances automatically without prefabs.

 

GPU Instancer automatically converts shaders to enable gpu instancing support. You do not need to enable gpu instancing checkbox on your materials or make any changes on your shaders.

 

Many thanks for your responses; it clears everything up
(Ignore the email... am just getting to the crunch of a project and really looking for something to assist with the FPS).

 

This leads to another question having looked at the tree (Conifer_Desktop); it is a model prefab and I assume that the LOD details in this are not required as GPU Instancer does its own LOD depending on distance?
Also, would I need to create new user prefabs for each LOD in the hierarchy (that appears as a user prefab) and therefore transfer the colliders to each of those for them to be added to the GPU Instancer manager?

 

GPUI works with prefabs that have LOD groups and calculates the LOD distances according to the settings you have on your prefab. You do not need to do anything additional on the Conifer_Desktop except to create a prefab of it and define it on the Prefab Manager:

https://gurbu.com/gpuinstancer/gif/conifer.gif

 

Sorry... last question (honest); this may be a bit of a silly question but it references that the prefabs that get loaded into the GPU Instancer Manager "This button can be used to register the prefab instances that are currently in the scene"; does this imply that all the prefabs must be loaded from the Hierarchy of a Scene and not from the Project? I only ask as it is also used that way in the tutorial videos too.

Thanks for the *gif*; I didn't know it would be that easy to convert!

 

(Have just bought it, thanks for your patience and support).

 

After you define the Conifer on the Prefab Manager it will check the Hierarchy of the Scene and register all of the Conifer's that are added in the scene to the Manager. And when you add more later you can use the "Register Prefabs in Scene" button to apply the changes to the Prefab Manager.

If you are adding more trees during play time, from code or with a third party tool, you can use the Runtime Settings to tell the Manager to check for runtime changes by enabling "Auto Add/Remove Instances".

 

The levels in the game are procedurally generated, so I would need to keep an active prefab in the hierarchy somewhere it couldn't be seen? (Or disable it at the startup of the scene?)

I am also getting an error in Unity when importing the package:

Shader error in 'GPUInstancer/Standard': 'FragmentSetup': cannot convert from 'float4[3]' to 'half4[3]' at Assets/GPUInstancer/Resources/Shaders/Include/GPUIStandardInclude.cginc(145) (on d3d11)

Compiling Vertex program with DIRECTIONAL 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 SHADER_API_DESKTOP UNITY_LIGHT_PROBE_PROXY_VOLUME​

I have no idea about shaders (hence the need for the tool), is this something that can be resolved? I previously had an issue on the night before a demonstration where a shader error caused the build to fail

 

You do not need to have any instances in the Hierarchy if you do not need one. I added the one in the gif to show you how to make a prefab, you can remove it. When you have a procedurally generated system, the trees will be automatically added to the manager at runtime when you enable "Auto. Add/Remove Instances".

Which Unity version are you using? GPU Instancer supports Unity versions 5.6.5 or higher.

 

I am on Unity 2017.1.3f1

Thanks for the response again; it is really helpful to delve into a new area of game development to get feedback.

 

I sent an e-mail with a fix, please import the package into your Unity project, and tell us if this fixes the issue.

 

Hi, @GurhanHazinedar,
I bought your Asset. And satisfied.
This is probably the best GPUI-related asset in the Asset Store.
I saw your code and I ask you a few questions.(I'm not a programmer)

1. Will your assets be introduced later with ECS or Job System? If you look at other GPUI related assets, there use ECS and Job System. However, your asset is dose not use them, and use GPUI on LateUpdate().(I guess most of them are implemented as 'D-Rendering', and you are differences implemented as 'F-Rendering'.)

2. is Mesh Animation on your roadmap? 'Skinned Mesh Renderer support' is Bone Animation. I thought of one idea. When setting the LOD, the nearest LOD is the Bone Animation and the far LOD is the Mesh Animation. I want to hear your opinion about this.

3. If you draw an asteroid gameObject in GPUI, Is there a way for each gameObject to access the results of LOD and OC in GPUI? For example, whether it is currently LOD0 or LOD1.

P.S. I am not an English speaker. I used a translator. I am sorry my poor English.

Edit : I corrected some of the translations because they were problematic.

 

Hi there, and thanks!

GPU Instancer is at it's base is a rendering system which uses indirect gpu instancing for better performance, and we expand on this by adding features that will help increase the performance (like culling, no-gameobjects, etc.), or expand the features of a unity system (like terrain details). And it is becoming bigger with every update with new features.

Our plan for the near future is to mainly break the current limitations like skinned mesh renderers, light limitations, etc. So that with different kind of renderers or scene settings you have, you can set it to render with GPU Instancer.

Also we are keeping up with new Unity systems (SRP, new terrain, nested-prefabs, and also ECS and Job System). For example, we will introduce SRP support on the next update and we are already preparing new ones for others.

For the Job System, it is not really required in our core system (rendering) to use it because we use Compute Shaders for complex calculations and GPU's thousands of concurrent threads beats the CPU's because we do not need to read the data back to the CPU. But it would be very useful on the users side where they can make their transform calculations on CPU with threads and then set it to GPU Instancer for rendering. We plan to make some examples and share it in the future, it would be really powerful to combine Job System and GPUI together. Threads everywhere .

The reason why we make the draw calls on LateUpdate is not about rendering, instead it's so that the managers can make the necessary changes made on the Update methods. DrawMeshInstancedIndirect works similar to DrawMesh in sense of rendering order, and here is the Unity's explanation about it:
"DrawMesh does not draw the mesh immediately; it merely "submits" it for rendering. The mesh will be rendered as part of normal rendering process."
So it does not really matter where you make the DrawMeshInstancedIndirect call, it will still be drawn after the CPU thread finishes.

Yes, it is possible, but we do not prefer to use LOD's other than their intended purposes. Because you need to break the LOD workflow to achieve this and also when your animations start to get complex, you will start to have memory problems because we create a buffer for each LOD.
Some of our users are using baked meshes and switching them at runtime. We also made a simple example for it:
https://gurbu.com/gpuinstancer/demopackage/GPUI_MeshSwitchDemo.unitypackage
But in this case, you are limited with one animation stage for each prototype.

So, we think the best will be to manipulate vertex positions on the GPU and have unique animations for each instance. This will be the best option with minimum memory usage, and it will not be a hack that breaks another system

It is stored in a compute buffer under GPUInstancerRuntimeData.instanceLODDataBuffer. It is a float4 array where float4.x is the LOD number, and if it is higher than 8 means it is culled. But this data is not being read back to CPU. You can read it back with ComputeBuffer.GetData, but it will be very slow. And also keep in mind that it's logic changes with updates. We can not guarantee that if you use these variables, they will work the same with the upcoming updates.

If you wish to see the total number of rendered LOD's you can add the GPUInstancerGUIInfo script in your scene and enable "Show Rendered Amounts" on it. It will show you the total number of instances being rendered for each LOD, but it will cause some overhead because of GetData call.