[RELEASED] GPU Instancer

hmm,
i was quite curious about how you handled things especially regarding detail rendering on the terrain.
after having looked into your detail demo though i was quite disappointed: having untiy rendering a vast amount of detail patches of approx. 1x1m size is not really comparative.

 

Hi there,

Thank you for your comment. In the DetailInstancingDemo scene, GPU Instancer is rendering the same amount of grass as Unity terrain does. GPU Instancer also uses a more complex shader, adds shadows and makes cross-quad meshes depending on the settings you use. Can you please explain why do you think it is not comparative? Which terrain settings would you like to see?

 

hi there,
it was a little bit late when i looked into the demo. too late actually to write a relevant comment on your asset.
i will have a deeper look into it and come back to you later.
thanks

 

My second requests will be to add mobile support open gl 2 and 3. Is this even possible ?

 

Hi,
It is not possible to use GPU Instancer with OpenGL 2 or 3.

 

ok, but your availability feature says its support OpenGL Core 4.1+/ES3.0+ on Windows, macOS, Linux, iOS and Android??

 

Hi there!

Yes, GPU instancing works for ES 3.0. But to dispell any possible cofusuion: the problem here is that, since GPU Instancer makes extensive use of compute shaders, the requirement for android devices is at least the Vulkan API or OpenGL ES 3.1. We have actually tested with modern android devices (with Vulkan on Galaxy S8 and S9+) and saw good results; however, other than these, we haven't tested extensively on mobile.

 

@LouskRad Hi there, this looks awesome. Can´t wait to try this but I have a couple questions:

1. Would this work with the LWRP (lightweight render pipeline) shaders out of the box? Or do I have to manually modify my shaders and include the "GPUInstancerInclude.cginc" as mentioned here?
2. What would be the best approach when my project has multiple loaded scenes in additive mode? Can there be multiple GPU Instancer managers?
3. It would be a great time saver if the GPU Instancer Manager had an "auto-detect prefabs on scene" button.

Cheers,
Juan

 

Hi there, and thanks.

Currently GPU Instancer does not convert SRP shaders automatically. If you need to use GPU Instancer with SRP, you need to modify your lightweight shaders manually by including the "GPUInstancerInclude.cginc", here is how:

Code (JavaScript):

1. HLSLPROGRAM
2.  
3. ...
4.  
5. //--------------------------------------
6. // GPU Instancing
7. #pragma multi_compile_instancing
8. #pragma instancing_options procedural:setupGPUI
9.  
10. ...
11.  
12. #include "LWRP/ShaderLibrary/InputSurfacePBR.hlsl"
13. #include "LWRP/ShaderLibrary/LightweightPassLit.hlsl"
14. #include "Include/GPUInstancerInclude.cginc"
15. ENDHLSL

You can add as many managers to your scene(s) as you like. They will work additively as well. For best performance, you could be careful not to have the same prototype in multiple managers. Note that you can activate and destroy managers anytime you like.

Well, if you mean auto-detecting the prefab instances in the scene, GPU Instancer already does that when you click the "Register Prefabs in Scene" button (or the first time you add a prototype). If you mean adding all the game objects in your scene that have prefab definitions (in order to define them as prototypes), we could add this in a future update where you could select the prefabs in your scene from a menu to import them as prototypes.

 

Hi, I'm very interested in this asset, but I got a question:
Does this asset contain a colliders pooling system? (Only enable or create object's colliders which is close to camera)
For if every object in the scene has a collider, it will be very costy even if all the rendering are GPU instanced.

 

Hey, I purchased your asset and dropped it into a single player action-platformer style project that I've been working on and have had quite a few speed bumps along the way. I went through your video tutorials which were very helpful for overcoming the initial setup with the specific instancing and setup for rigidbodies that you recommend and things have gotten better than my initial experience. However, I am still having problems getting a positive performance out of this. It actually jumps to several hundred passes higher every-time that I look in the direction of the like 50 bullets that I've instantiated. It is also much slower than the scene was before implementing this asset. One thing I am trying to do is use your instantiation method as an object pooler. If you have a tid bit of code to access the instantiated prefab list in order to pull individual objects out of it using transform.position, that would add a lot of usefulness to this for me. As it is now, I'm a little perplexed on how useful this asset will be in my current project. I'm not entirely sure what the best practices are for it or what factors are limiting it from achieving better results. I understand that it is probably best used in scenes with a lot of similar objects, but doesn't seem to function very well in more diverse scenes. Perhaps I am doing something wrong or using this asset for the wrong purpose. Any advice would be useful. Also, any idea what could be causing an "Array is out of range" error, stemming from line 444 of the GPU Instancer Prefab Manager script? Could be the key to figuring out my personal issue.

 

Hi,
We have such an optimization option for rigidbodies at the moment; but currently not a collider pooling system. It will be included in a future update as an optional feature for prefabs (and also for terrain trees after we add the tree manager).

 

Hey @kyleshell,

The instantiation method is not intended to be used as an object pooler: the InitializeGPUInstancer method should not be used repeatedly, it is intended to be used after level load. We were not able to make a video tutorial for adding and removing instances at runtime yet; but for adding and removing instances at runtime you should use AddPrefabInstance/RemovePrefabInstance methods. For updating transform data, you can use UpdateTransformDataForInstance. We will make a tutorial video for these in the near future, but for now, you can take a look at the API documentation for more information.

GPU Instancer does not destroy the game objects in your scene when initialized, so you can (and it's the best way to) access the object normally through its transform.position in your scene. If you need to identify this prefab in GPU Instancer instantiated prefab list, you can use its GPUInstancerPrefab component.

The performance would be better with the same meshes and materials, but would scale better with more objects in any case.

This error seems to be caused by using the enabling/disabling functions in the API in a manner that they were not designed for. This error happens when GPU Instancer is not able to find the instance in the internal instance list. We will handle this error and display a sensible error message that explains what is wrong in a future update.

Can you send me a pm with the relevant parts of your code where you use the GPUInstancerAPI? If we know better how you are using GPUInstancer in your project, we can go over the specifics and help you increase your scenes performance. If you could also send me the stacktrace from where you get the error, we could also help with that too.

 

Hi everyone!

We have just uploaded two demo builds for Windows PC and VR. You can download them from our website at:

http://www.gurbu.com/demobuilds

These builds are intended for benchmarking GPU Instancer. You will be able to test the asteroids demo scene with various asteroid counts (10k, 50k, 100k) while flying around with the spaceship. You can also turn GPU Instancer on and off for comparison. The VR build is for OpenVR and Oculus at the moment.

Cheers!

 

Great！Now definitely looking forward to this asset!
I'll keep tuned.

 

In reference to the above question from Harekelas, how do you get the asteroids scene to be so performant when every asteroid has a collider? Just curious if there's anything making the colliders in the scene less of a hassle or if the boost comes from purely rendering and deactivating the rigidbodies.

Additionally, I added 4 Amplify post-processing behaviors to the asteroids scene and only lost about 5 fps at 40,000 instances so I would definitely say that they are very compatible to this asset.

Also, thanks for the quick reply. It helped me straiten out the nature of what this asset is designed to do. I was initially going to use it purely to help with spawning instances of objects into my game such as bullets, crates, enemies, ect., but it seems that it would far better serve to render the individual cubes and building blocks that make up my level as opposed to the more complex code-driven objects in the game. To fully use this, I'm going to have to remake a good deal of my map using prefabs, instead, but this could definitely add a lot to the performance as far as my understanding goes. Will also be more dependent on terrains in some sections.

Also, I'm sure there is a better way to recycle object instances without destroying them that could come in handy with the whole bullet thing, such as instantiating them as needed, then transforming their position to an unseen location, where they can eventually be reused in a continuous loop.

I do find that you should not assign certain prefabs with certain scripts though. It can lead to some odd bugs. It even altered the audio quality on the sound I had attached to my bullet prefab to where the sound sometimes stops short or essentially goes from a cool blaster sound to a pea shooter. It's very odd lol. Additionally, it messed up the script on the bullet which causes the player to be damaged, but this was fixed after removing the prefab script and changing the damage value. Yet, the Destroy part of the script seemed to work fine, which was confusing as S*** lol. Just a lot of odd bugs when incorporated with other scripts, so if you plan to use this in a serious project, I recommend prefabs that are very simple, with a rigidbody and simple collider at most, built from the ground up to support this feature. The rest of the action will have to be rendered with the CPU.

LouskRad, feel free to correct me if any of this advice is misplaced.

 

>Also, any idea what could be causing an "Array is out of range" error, stemming from line 444 of the GPU Instancer Prefab Manager script?

I encountered this error with more than 3 LOD levels.... I had 6 initially. So that's a thing.

edit:
Really looking forward to the promised occlusion culling feature. Guess that's the thing I'd love most to make this asset truly awesome.

 

Alright, sorry. One last bit of feedback because I've finally figured it out and it really is like magic. I've essentially replaced a good portion of the standard cubes that make up my level with identical, instanced prefabs and the result is pretty incredible. The fps has become quite consistent and its hard to deny the noticeable impact it's having on the smoothness of the game and even appearance, which is advertised, but it's so true. Once again, it's having absolutely no issues jiving with 4 Amplify PP effects at the same time and rendering the map feels so much more light weight and I absolutely love it! I'm honestly really glad I could jump on this asset early because I know that it's only going to get better. But honestly, what you have here is pretty awesome. It has a bit of a learning curve at first, which should improve with time and more tutorials. Although that is true, I can also really appreciate the lengths you took to make this very complex, albeit, useful graphical process into a completely user-friendly experience. Can't have been easy and the hard work and creativity is much appreciated.

I'll have to do further experimenting with certain types of objects, but, so far, the GPU instancer prefab script seems to mess up every other custom C# script that is also attached to the prefab, so that limits a lot of big possibilities with instancing anything meant for more complex purposes. It also doesn't work with GPU instancing particle effects as far as I can tell, but that would be a serious game changer. Just trying to give a more clarifying view of what this asset is to anyone whose curious, because it is a little cryptic and hard to understand. But, what it does, it does incredibly well. And that is to optimize the simple and redundant prefabs you use throughout your game. Also, I'm sure there are many simple work arounds to these scripting issues using code.

Point is, if your game needs more performance, buy this asset.

 

Thanks for the info. We will fix the error and add a new structure to use higher LOD levels. Currently GPU Instancer is designed to support up to LOD4 (5 levels). As you did, users will need to limit the number of LOD levels for the prefabs they use with GPU Instancer until we make the update.

We already came a long way with occlusion culling, and planning to add it in the next feature update. So hopefully you won't need to wait long

 

Happy to hear that you found a good use for GPU Instancer with your project. GPU Instancer is easy to use and add to your scenes. However, as you mentioned, figuring out which settings to use and which objects are better suited for it would require some knowledge and testing.

Right now GPU Instancer might not perform well with objects that has scripts updating their properties frequently. But we will improve our API, automatize some updates and add more tutarials in the future to make it easier and more understandable.

 

The performance improvement comes purely from the rendering and minimizing the data being send to GPU. There is no optimization for colliders right now. Ridigbody feature is an option you can use for simulating physics partially. Even with this rigidbody simulation, you will see in most cases GPU Instancer is performing better compared to default rendering without any rigidbodies.

 

So would this allow for pooling enemy ai characters?

The VR demo is incredibly impressive.

 

Currently GPU Instancer does not support skinned meshes and animations. It will be added in a future update.

 

Do you have a timeline for something like that and do you think it can be done? Also can the AI be used from the gpu?

 

We do not have a specific date yet for this update. It can be done. We have working prototypes for all of our planned features. We will not have a system for AI so it will be calculated in CPU with your own system. But we will have methods to send the information required for rendering to GPU like transform and animation data.

 

Hi, about the unity tree's integration you mentioned before.
Do you plan to add the function that allows us access every specific tree instance in runtime?(As to remove, replace or add trees from collision, so we can make chopping tree functions and growing forests)

 

Another quick question:
If I only use the attached scripts to update data with no effects on the visual on the prefabs, but will need raycasts to identify the instance and return data to me, can this asset manage that?

 

Well, if you're using trees as game objects, you can already do this. Our planned feature for trees is to instance terrain trees the same way that we currently instance terrain details. If you mean those trees, then we do not plan to give additional access to them - but it is certainly possible.

Certainly. Your raycasts will work as normal as well (if you have colliders on the object), since all GPU Instancer is doing to the actual game object is to turn its mesh renderer off.

 

Thanks for the reply!
And what about the performance dropping rate when many prefab prototypes are added?
I currently have more than 50 prototypes and intend to add more than 100 to my game. I see there are only 4 prototypes in the asteroid demo, my models does not share a same material and some even contains multiple materials, how does it affect the performance when GPU instancer is enabled?

 

The performance will always scale for the better with the amount of prefab instances. That is, for example, if you have 100 prefab types and a lot of instances for each of them, your performance would increase a lot when using GPU Instancer in comparison to not using it. However, if you make use of 100 prefabs in your scene and only use, say, 10 of them with a lot of instances in the scene, then you only would need to use those 10 as GPU Instancer prototypes to see a significant performance boost.

In short, you do not need to use all your prefabs as GPU Instancer prototypes. It is enough to define only the prefabs with a lot of instances as GPU Instancer prototypes; but if you have 100 prototypes with numerous instances of each, then you will yet again see significant performance boosts when using GPU Instancer as opposed to not using it. This is also true for meshes with multiple materials or prefabs with different materials, LOD Groups, etc.

 

Comprehended, I'm only planning using GPU instancer with static natural resources like trees, plants and rocks and I need them to be interactable as well. Take following pictures as reference:






These are three different biomes I've created with more than 50 prefabs, they all in a single scene but may not always be visible at the same time(one biome is quite big), but also can be shown in one screen(when you stand at the blending area of all three biomes).
The trees are made by speed tree, they contain shader based dynamic wind animation, rocks are common mesh renderers.
How does GPU instancer handle SpeedTrees and their wind?
And how many prototypes can GPU instancer support?

 

Those screenshots look amazing, nice job

From your shots, I believe this scene would get a good performance increase by instancing your terrain details (also, you could have a lot more grass and plants in your biomes - see the detail instancing tutorial video), and indeed your static natural resources.

The GPU Frustum culling feature (and the upcoming Hi-Z occlusion culling feature in the next update) will help a lot here if these biomes are all in the same scene.

Please note that GPU Instancer currently does not support SpeedTree; it is a planned feature and it is scheduled for a near future update. GPU Instancer currently has a detail manager system for terrain details, and a prefab manager system for all sorts of prefabs (e.g. we also instanced the quads that work as the asteroid haze in the demo build). In a near future update, we will introduce a tree manager which you will be able to use in a similar fashion to the detail manager, and will support Tree Creator ans SpeedTree trees. Of course, this also includes the wind support for SpeedTree.

There is no limit to the prototypes you can define in GPU Instancer; you can throw in as many as you like. The rule of thumb is, as I said in the previous comment, to see a performance boost, define a prototype if it is necessary.

 

If I get it right, the tree manager will not be able to let me interact with each tree instance, right?
So if I use all my speed trees as prefabs, will the prefab instancer be able to deal with the wind animation?
Or the tree manager can allow me interact with individual trees?
And I read the description says GPU instancer automatically generate billboards for prototypes, do the billboards only presented as a single rendered picture or several for different angles?
What about the billboards' normal maps for dynamic direction light?

 

True.

Exactly. The prefab manager will detect that the prefab instance is a SpeedTree and will use the appropriate internal shader for it.

Currently the billboarding is only for texture type terrain details, and it is a camera facing, single quad billboard. We are, however, working on a different-angled approach for prefabs and trees (pretty much like an imposter system) and it will be available in a future update.

The current texture terrain detail billboard quads use a unified upward facing normal as you would expect, but for the future feature prefab and tree billboards that I mentioned above, there will most likely be snapshot normal maps for different angles. This is still in prototype stage though, so it can change.

 

So glad that these mentioned features are in the list.
I recommend you take a look at Vegetation Studio, I'm currently using this asset for all my natural resources, it has a superb billboard solution for vegetation. But it is a stand alone system controlling all the prototypes, not as flexible as GPU instancer in my opinion. And it has a huge performance hit every time a new terrain is enabled with all its vegetation, and when I need to mask out some area of the vegetation instances(like a building mask out grass), seems a whole sector is re-rendered.
It seems GPU instancer can be more flexible when dealing with game objects, but I'll need some certain features mentioned up there to achieve the same functionalities I currently have, so I'll keep an eye on this asset and see if I can add it to my project in the future

 

***Tried to send private message but it wouldn't let me***


So, I was wondering how to achieve something like this:

Zombies and models like this in sheer numbers.

Can GPU instancer help me with that?
Will it be able to in the future?

Any and all information you provide would be greatly appreciated. Thanks ^_^

 

Hi Neviah,

Skinned meshes like these need a special infrastructure to instance, there are various not-so easy to implement techniques. A common technique is to bake the bone structures (rig info) and animation states to texture sheets and use compute shaders to process this info and use GPU Instancing afterwards.

Currently such a feature like this is not available in GPU Instancer. This is one of our planned feature updates, and is scheduled to be added later on in our roadmap. Of course, when it is available, GPU Instancer will do all that complex baking and instancing compute shader stuff for you in the background and make it easy to use.

 

I'm confused about what this asset is supposed to be, can you please share more details? It caught my attention and I was hoping for lots of objects moving around like that asteroid field. Or lots of flocking birds, butterflies and such. But when I continued watching the introduction video, this turns out to be a Vegetation Studio clone, which I don't have use for. Apart from the vegetation stuff, is there more to this asset than the Asteroid field?

 

Hi Rowlan,

GPU Instancer has two main parts: prefab instancing and terrain detail instancing.

With prefab instancing, you can
- optimize the scenes where you have many instances of the same prefab
- use extreme numbers of objects on your scenes with high FPS numbers
- move those objects around through our API
- use physics and rigidbodies on them
- have material variations within the single draw call while rendering these objects
- use custom shaders and materials on these objects while rendering as such

The asteroid scene is an example usage. GPU Instancer currently does not offer flocking-like specific behaviors, but gives you the option to have a lot more objects on screen than you would normally be able to have within desired FPS (Which is also a big deal in VR). The techniques used for such optimizations require extensive knowledge and use of compute shaders and GPU programming - the purpose of GPU Instancer is to reduce all this time consuming work to a few clicks and generalize the usage for every possible scenario this would be required. Our roadmap includes increasing this performance further with future updates and adding support for skinned meshes (with which you can use this system for rigged and animated meshes). As for flocking-like or similar default movement behavior, if there is demand for it, we could implement such presets for instanced prefabs in a future update.

Detail instancing bit is the vegetation stuff, and basically applies these same principles of prefab instancing to terrain details (and trees in the near future) without taking over the Unity terrain system. This results in accelerating the performance and enhancing the look you get from Unity terrains with custom shaders, terrain specific optimizations etc. without switching to an alternative terrain/vegetation system.

I hope this clarifies a little more what GPU Instancer offers.

 

For fps multiplayer purpose does gpu instancer allows multiple camera ??

 

Hi,

If you mean switching between cameras at runtime, then yes, you can easily do that through the SetCamera method of the GPU Instancer API (you can also find an example at the DetailInstancingDemoScene).

If you mean two cameras rendering at the same time (something like a splitscreen multiplayer), then partially yes: frustum culling and the (upcoming) occlusion culling both depend on a single rendering camera, so you can use your prototypes without them. Note that this would reduce the performance increase, however.

Well, if you mean different players at different computers, you can surely use GPU Instancer as you normally would - nothing extra is necessary.

 

yes i meant this feature. i am planning on making a multiplayer fps shooting game and i was not sure if this technology is available for such use.Thanks

 

Let us assume we place objects using another plugin. Example: I take a rock and scatter it using another plugin. Now I want to GPU instance them, so can I just put the prefab in your plug in, click update. Now will all of those instanced prefabs count which were placed with other plugin?

 

Personally I'd prefer to have environmental stuff like lots of butterflies, birds or even bats flying out of a cave. Those are animated. But also rather static stuff like pollen flying on a grass field. Flowers which lift off and rotate because of the wind.

 

Yes. You can use any tool you like for placing your prefabs in editor. When you click "Register Prefabs In Scene" button on GPU Instancer Prefab Manager, all the GameObjects referencing to the prefab will be saved for instancing.

However, if the tool you use breaks prefab references or makes changes on meshes or materials (like combining meshes), then the instances will not register.

 

Thanks, so honestly speaking this is a tool that redirects on GPU instead of CPU which happens on Unity Instancing.

 

Indeed. The main purpose here is to take off the load from the CPU and transfer it to the GPU. Going beyond simple instancing, GPU Instancer also does all the rendering operations (culling, lod determination, detail partitioning, transform updates etc.) all on the GPU, which allows for the rest of your game to leverage the CPU as much as possible. Also, since the bottleneck while sending data from CPU to the GPU each frame is removed (via indirect instancing) the GPU does not need to wait for the CPU to sync so can perform better.

 

Another question, if I use different meshes with same material, how does it affect GPU performance? How will this help with GPU Instancing

 

Batching dynamic GameObjects has certain overhead per vertex, so batching is applied only to Meshes containing fewer than 900 vertex attributes. Is that still the limitation?

 

Well, what you are instancing is your prefab and not the prefab instance, so any change would mean another prefab. Behind the scenes GPU Instancer uses the mesh(es) and material(s) of this prefab and sends them to the GPU. So normally, you wouldn't be able to use a single prefab with variations - however, we remove this limitation by allowing material variations through material property blocks. So if you need to use variations in your prefab's material, you can still do this by defining those variations via the GPU Instancer API. How this is done is exemplified in the ColorVariationsDemoscene, so you can take a look at the code there for starting off.

You can think of each mesh-material combination in a prefab as a draw call (including submesh indexed materials' combinations with the mesh). So, sharing materials between your prefabs is not really necessary.

Dynamic batching limitations do not effect how GPU Instancer works. So with dynamic batching, the vertices of smaller meshes are combined together in the CPU to be sent to the GPU. The limitations come from how Unity sorts grouping these vertices together. On the other hand, in (indirect) GPU Instancing, you take control over the graphics buffers and directly handle what is sent to the GPU. What you send are not combined meshes to minimize draw calls; instead, you send as many meshes as you want to the GPU in a single draw call and tell it how to handle these meshes. You will notice when using GPU Instancer that the "saved by batching" property in the stats window does not show the tri counts for the instanced prefabs at all. This is because GPU Intstancer takes over the draw calls for the given prefab completely and since everything is happening in the GPU and never making its way back to the CPU, Unity has no way of reporting this. This is also why it works so much faster in comparison to standard mesh combining/batching solutions.

So to answer your question: yes, the lower than 900 vertex limitation still exists for dynamic batching but this does not effect GPU Instancer.