[RELEASED] GPU Instancer

Short answer is yes. Long answer is but you would not want to do that. Since the point of instancing use a tool like this is to have a lot of the same mesh. Like a ton of grass objects or rocks that all share the same mesh. That is were you get the huge speed bump because you can push these onto the GPU as a single draw call per UNIQUE mesh. You will get 0 benefit from pushing 100 different mesh objects because that would result in 100 draw calls. Pushing 100 instances of the same mesh would work out to 1 draw call.

You also run into an issue which I am working on right now which is you start taking some CPU hit the more UNIQUE meshes that you push through GPUI so you want to pick which ones you really get the most benefit from and not just push ALL of your objects. So its best to find those meshes that you use the most over and over.

In your case you seem to have a bunch of unique meshes so this would not be a good solution for that and would require some other idea like using the same mesh and GPUI but using a vertex shader to modify it after the fact (just throwing random things out there but you get the idea).

Hope that helps.

 

I see, ok, thanks a lot for the help and explanation. So I have to find a new path for what I want to do.

 

Well check back here with @LouskRad just to make sure I did not mess up the explanation, I am far from an expert on this, but as far as I can tell yes.

 

First off, you have an error in the console. Although it is not from GPUI it might be preventing GPUI's operations; for example if it effects the depth texture it might prevent GPUI's occlusion culling from working.

Next, please make sure you have updated GPUI to the latest (v1.4.4) version. On that, please also note that there is a rather disturbing Unity bug lately that might misdirect you into believing that you are using the latest version: https://forum.unity.com/threads/released-gpu-instancer.529746/page-48#post-6737122

If the problem persists, you can make a support request following this guideline. For more information on occlusion culling, you can take a look at this wiki article.

Hi there,

the DetailInstancingDemo scene that you show in your video has a scene script that overrides the settings you set on the Detail Manager. You should see the values you change are properly used in a scene that you make. Or you could delete the GameObject that has DetailDemoSceneController in the scene (disabling it won't help since the code runs on its Awake)

ShadowCastingMode.Off in a DrawMeshInstanceIndirect call is to disable shadow casting for the instances; but you'd better set it in the manager (by using the is shadow casting option) and leave it to GPUI to manage. The bold parameters in my code that you are referring (namely the "true" in the current code) stands for shadow receiving. This will be made optional in a later update. Having said that, there might be cases (such as in URP) that Unity uses this setting from the material rather than the renderer. In any case, both these parameters would be irrelevant to the flickering issue you mentioned before.

As for the second DrawMeshInstancedIndirect call, it is for some special cases of shadow casting (for example using a different material than the original) - irrelevant when you disable shadows.

The Detail Manager is not intended to be faster than Unity's terrain details at all times - since it adds a lot more visual quality (shadows, cross quads, PBR, etc.) than the latter. For more information on balancing visual quality and performance, you can take a look at this best practice article.

This difference is because Unity ignores the editor overhang and makes an estimation for build speeds in the stats window. The FPS utility that you are using calculates actual in-editor FPS instead; hence the difference in ms. You should see stats window like values in your builds.

The performance overhang from zero matrices would be negligible unless your removed instance counts are really high (like thousands). In those cases you can swap-back the last part of the buffer to remove your instances instead. And you would use SetInstanceCounts after. (For example, if you zero the last 3k elements from your original 8k array, and use SetInstanceCounts to set it to 5k). This would improve GPU times a bit (not CPU times).

Removing the compute shader dispatches would mean absolutely no movement. Neither camera nor instances. You would loose the performance gain from frustum and occlusion culling and LOD calculations unless you run the CS dispatch once and not move your camera after. Even then, any vertex shader modifications like rustling leaves would break the scene after - so really absolutely no movement.

In short, it would only be better in a static scene with absolutely no movement without any of the GPUI features - but then you could also take a screenshot and render it on a quad instead, which of course would be faster anyway .

Of course there could be project specific modifications that could increase GPUI's performance further - like some parameters you're not actually using are probably being sent to the compute shaders, etc. However, most of these improvements would be negligible in most use cases anyway - and further improvements in the lines of modifying things like these would break the generic-ness of this solution (especially given GPUI supports multiple target platforms).

In short, given Unity's implementation of the Compute Shader API and various minor engine related limitations, I can't advise any improvements in the low level system to improve your scene's performance. I would rather advise focusing on how you can lower your prototype counts and overall geometry in your scenes when using GPUI instead.

@holdingjason is right indeed that as a GPU Instancing solution, having unique meshes and GPUI would not play well. It is also true that you can use vertex shaders for this (like GPUI's foliage shader does) but it would of course be limited modifications on the mesh.

For detailed information, you can take a look at this wiki page where how GPUI works is explained in detail - in comparison with other optimization strategies.

 

@LouskRad Thanks again for walking me through this. Learning a lot. Ok so what you said makes sense especially about the part of frustum and occlusion culling and LOD calculations. SO let me just double check some stuff with you but think we are on the same page.

I ran my simulations and yes its not a free lunch. So I was looking at just the DrawCalls/Setpass calls and verts but we are still pushing tris etc to the GPU for processing so, and tell me if I am wrong here, the more instances and the higher those instances vertex count/complexity is your still going to be increasing the load on the GPU for each new instance even if its getting to cache the use of the same mesh.

SO that is where LOD and occlusion calling is needed to dump out those extra instances because they still are putting significant load on the GPU. So yes I can bypass the compute shader updates BUT then all those instances are getting dumped to the GPU every frame regardless of where they are in the scene. Now based on the project you main gain some performance improvement by just dumping those to the GPU and saving the CPU cost but that just depends on a number of factors. You could also implement a chunky occlusion system yourself if the project could be setup that way to again minimize that GPU overhead but its a balancing act and very project specific.

The only thing you said that did not seem to make sense was when you talked about was NO MOVEMENT including vertex shader changes ie rustling winds etc. This does not seem to be correct based on the example from Unity here.

https://docs.unity3d.com/2017.4/Doc...rence/Graphics.DrawMeshInstancedIndirect.html

So in this one we are rotating the objects via the shader around a center point so they are moving using the shader while we are NOT updating the compute shader but just recalling DrawMeshInstancedIndirect every frame.

Graphics.DrawMeshInstancedIndirect(instanceMesh, 0, instanceMaterial, new Bounds(Vector3.zero, new Vector3(100.0f, 100.0f, 100.0f)), argsBuffer);

I can also move around the camera as well with no change or impact in FPS etc as far as I can tell so the instancing seems to still work fine in both these scenarios but as you said you still have the other issue "Use this function in situations where you want to draw the same mesh for a particular amount of times using an instanced shader. Meshes are not further culled by the view frustum or baked occluders, nor sorted for transparency or z efficiency."

So if you agree with all that let me know, especially on the movement thing because that has me a bit confused, perhaps I did not understand exactly what you meant on that one.

Conclusion is fine you might be able to skip the compute shader stuff in some very narrow situations but your going to have to really see, based on your project, if its worth it and probably a fair amount of work to tweak to get that right.

Thank you very much for taking the time to walk me through this. I will continue to play with this and if I can find anything that would make sense in a more general way I will pass it along for you to take a look at as something perhaps that might be worth exploring.

 

Hello, FAQ states that i need GPUI_ShaderGraph_v5.x_or_Later_Node.unitypackage for shadergraph shaders but there is no such file in GPUInstancer/Extras/
fresh 1.4.4 version

 

Also, can someone tell me if i can use GPUI with Visual Design Cafe Nature Shaders?

 

Many thanks to both of you, I'm trying another way to get the optimization I need.

Is there a way to know which objects instantiated with InitializeWithMatrix4x4Array are enabled and which are disables? I've been looking for a long time now but I don't see how to get that information.

 

Hi Duende,

Sorry you lost me a bit here. Are you asking what GameObjects are enabled? What ones are being culled? Are you doing no gameobject flow with GPUI or are you letting GPUI handle it via gameobjects? If its just the normal flow then you still control the gameobjects so enabling them etc is handled by you. Same thing goes if your doing no game object solution. So in either case you would know what ones are enabled or not unless your asking about culling. Sorry just a bit confused as to what your asking for here.

 

This is what I'm doing: I have a GPUInstancerPrefabPrototype cube, then I initialize a Matrix4x4 array and randomly place positions for the cubes. Finally I run InitializeWithMatrix4x4Array with the prototype cube and array.

What I need to know is which of those cubes are being culled by the camera and which are not.

 

Gotcha ok that makes sense. Good question I have not come across that one yet so I don't know off the top of my head. Be a good one to know.

 

And if I don't use InitializeWithMatrix4x4Array? What if I initialize with RegisterPrefabInstanceList like in the asteroids example? How can I know which cubes are being culled and which are not?

 

Based on this reply looks like there is not anyway to get that data right now.

Hi there,

Since the culling operations are executed in the GPU, it would require a readback to determine if specific instances are culled. This would cause a major slowdown, so it is not provided as an API method.

If you need this for a test, the GPUInstancerGUIInfo component uses such a readback for debug purposes.

 

Now I have made a new scene, but the grass distance stops about 500 meters . What am I doing wrong ?:

 

Oh, in that case I have a problem. I really need to know which cubes are being culled.

In the DetailInstancingDemo scene the mower is able to remove the grass that enters its box collider. Somehow it has to know which of all the plants it should remove. Maybe a similar system to know which cubes are being seen? Even if I had to create a collider in the shape of the camera fustrum.

 

Well I think in that case its just clearing out the objects at that location. So in the matrix example it could find those object in the matrix and set them to zero. It knows where those objects are and it knows where the lawn mower is so its able to remove them from the list. This would not have anything to do with culling in that case. Culling would work on the GPU on the entire list to clear out the non visible objects in the pipeline but that is going on behind the scenes on the GPU.

 

First of all, thanks for keeping up the support and replying to everyone here!

I have after a decent amount of struggle finally gotten everything to work as it should using URP and Shader Graph. Adding/removing/updating at runtime, doing color and other variations, and even making amplify impostors hook in to the variation buffers so they act accordingly as well.

However, it turns out that GPUI very consistently crashes and freezes my builds on OSX Catalina. I procedurally generate everything directly at runtime, which includes instancing trees and other vegetation with GPUI. Sometimes it crashes or freezes there, and sometimes it creates the map and all instances as I expect. But then I can reliably crash/freeze it by reloading a map or generating a new one. I don't have issues with this at all in the Editor and when I don't instance anything with GPUI and only has the prefab manager sitting in the scene, I don't get any crashes. When it crashes, it crashes before generating a stacktrace, but I included two different logs of when it freezes. The only info I've managed to scrape together is this quote:

"Any crash inside malloc, realloc, free, or memalign is a 99.99% indication that you have heap corruption (which is the result of overflowing a heap-allocated buffer, freeing unallocated memory, freeing memory twice, etc. etc.)"

I only have a few hundred instances atm distributed over about 15 prefabs so I'm not doing anything crazy. I'm on the latest version of GPUI and Unity 2020.2.2f1. Unfortunately, I have no possibility of trying a build on Windows as of now. Let me know if I should send over a build or more info. Hope you can help, I've come so far now and really want it to work. Thanks!


EDIT: After much testing it seems that the Graphic Settings option "Graphic Jobs (Experimental)" enabled together with GPUI somehow causes the crashes. No issues at all since I disabled it!

 

Do you have a Planar reflection in your scene? If so, I have the same problem. If you deactivate Planar Reflection the problem disappears.

But you would lose the reflections for the ocean (Sky, etc), for example, which is what happens to me.

@LouskRad answered me this by email when asking for support:
"The planar reflection component uses (and modifies) the depth texture that GPUI uses for occlusion culling. This component has an option (" Clear Depth ") on it that is by default clearing the depth texture. Disabling this option keeps the previous depth texture but still the planar reflection component will be writing on the depth texture. This might cause some incorrect culling, so I would recommend testing your scene even if this option is turned off. "

But this solution does not serve me since when doing this the ocean does not receive the reflections of the sky.

@LouskRad I sent you an email months ago to your support email in reference to this problem and that the "Solution" that you gave me did not work for the reasons I said above "I do not receive the reflections from heaven" ... and requesting some other solution ...
But you still haven't answered me ...
Is it possible to do something with this GPU Instancer limitation to fix Occlussion Culling issue?

regards

 

Yes the update was bugged, i upgrade right on the 1.4.4 now, and yes the error is when MSAA is actived when he's disable the error gone and occlusion culling of GPU Instancer work correctly ... I use the last SRP and last URP version on Unity 2020.2.1f1

 

Hi,

Using variation buffers as per the documentation, I’m changing the color of all my instances at the same time at seasonal changes and noticing it gets really, really slow when the amount increases. For 7000 instances it takes 220ms and for 40000 instances it takes over 150000ms. All my meshes are low poly and I’m otherwise happy with GPUI performance gains. Is there any way to optimize around this, like changing the color of multiple instances at once and not having to iterate? I really don’t need more than 3 or 5 color variations for grass or leaf color for any given prefab. I would even be happy if I could quickly change all instances of one prefab to one specific color. Would DefineAndAddVariationFromArray() and UpdateVariationFromArray() end up being better for me? I’m not fully understanding the parameters in the API docs on it. Is there any example using them? Also, would going for a NoGO workflow help at all with any of this or does that only save time in not having to instantiate prefabs?

 

Hello. Can you give answer to my previous posts?

 

Exceeded 256 Shader Keywords.
When I install this, it adds some 27 new Shader keywords. So not able to use it.
Before Install - 89
After Install - 116

 

Hi,
I´m using GPUI MapMagic integration. How or where can I raise the value for the the max detail distance ?
I have tried to set the value (via playmaker... no coder, sorry ) but on every start it resets to the max 500.
Changing other values work, though (detail density for example).



Thank you !

 

Yes, in general it seems to be on the right track. The bit about camera movement was hypothetical; about the fact that if you run the dispatch once with compute shaders and don't make any other dispatches, the culled instances will still be culled - but when you move the camera, without a dispatch, the culled instances are in effect culled from wrong locations.

As for the vertex shader movement, what I meant was about culling behind what has been moved in the vertex shader. For example if an instance behind a leaf is culled, and that leaf moves in a vertex wind animation shader, the instances behind its previous position must be visible and the new hidden position instances must be culled. You can take a look at this time stamped video link for an example.

This might be related to the recent Unity bug about not actually having the latest asset version. Please tale a look at this post and see if it solves the issue. The file must be located under GPUInstancer/Extras among others:

We haven't tested or heard any reports about those shaders with GPUI - however, if that package has its own rendering system, there is a good chance they might be incompatible with GPUI.

This might be about resolution. Having a relatively small screen resolution (as it seems from your video), you might be hitting a barrier where the instances get too small to be visible (smaller than a pixel). You can test if this is the case by entering play mode and setting the Game window's to different resolutions (such as 1920x1080). If you see the grass rendering in higher resolutions, that means it will render in your builds at those resolutions as well.

Thanks for the info. Previously, the "Graphic Jobs (Experimental)" setting did not effect GPUI - but Unity might have made recent changes to it (apparently for Metal) that conflict with GPUI. Having said that, it might also be a general Unity bug can be fixed in a future Unity version.

To clarify, GPUI's occlusion culling feature needs to use the depth buffer. Anything that prevents the usage of the depth buffer (or that changes it) will therefore prevent GPUI from occlusion culling. Thus it is not a matter of "fixing" GPUI - rather, it's simply that HDRP planar reflection probes are currently incompatible with GPUI's occlusion culling. The "fix" to this then, would be if and when Unity changes how HDRP planar reflections work.

Those numbers seem to be way too high, and not knowing your actual implementation, we can take a look at it if you send us a sample project. Having said that, however, if you want to change the color of all instances to the same color, using a variation buffer would not be ideal. I would then suggest using either the ChangeMaterial API to set all instances' material to one with your desired color - or use a custom shader with a global shader property for its color that you can set at runtime.

As for using a no-go workflow, it's performance would be faster compared to using game objects - so it's more than saving time on instantiating GOs. For more information on this, you can take a look at this best practice wiki.

Unity allows for a maximum of 256 shader keyword variants in a single project - which is usually hard to exceed. If you get that error, it means that there are either a lot of shaders in your project or complicated ones (or both). The solution to this would be deleting the shaders that you don't use from your project - but if that is not possible, and if you don't need the GPUI shaders, removing those would also help. You can take a look at the GPUInstancer/Shaders/ folder to remove those that you won't be needing.

Thank you for the feedback. We will make this work the same way with other managers in a future update. What you can do for now is to search the GPUInstancerMapMagicEditor.cs file for the keyword "500" and replace it with a higher number. This would effectively increase the slider's max end.

 

Just adding to this.. in Unity 2019.4.19f1 the limit was raised to 384 (while they work in a solution that don't require a limit).
Also, the limit was already 384 for the current Unity 2020 version, I think.
Anyway, sometimes you can get that message and when restarting Unity it just goes away.

 

Hey folks,

Has anyone dealt with moving GPUI to a different root folder? Its much easier for me to do this because of our repository setup.

It mostly works just fine but what I would like to know is where the shaders are auto generated so I can inject my path changes rather than manually resolving them.

E.G I want to edit where this line is generated: #include "./../../../../GPUInstancer/Shaders/Include/GPUInstancerInclude.cginc"

Also any chance of accounting for inlining in the next update? Unity shamefully doesn't inline, especially for properties. So things like .Length and .Count on arrays and lists count as a method call rather than just a variable read so its best to call them once and loop over the result instead of calling .Length in the for loops.

Feels like you could get a little performance back if you did this in the GPUInstancerPrefabManager for example

 

Also it constantly remaking the shader after stopping play mode is pretty annoying. It means we now always have file changes detected by our repository tools :/

Edit: just found the setting to disable auto conversion

 

Hi

I have 3 pre-sales question. I see from the description on asset store, that this GPU Instancer asset works great with Gaia.

1) However, does it also work with Gena Pro? I'm thinking of purchasing Gena Pro to scatter/spawn vegetation onto my meshes (yes meshes, not terrain) in URP and also HDRP, and I would like to buy and use GPU instancer in conjunction with Gena's scatterer. Is that possible?

2) Will GPU Instancer work with HDRP and raytracing?

3) Do you have a Discord channel?

 

Does this asset support lightmaps in 2021?

 

Thank you for the feedback.

GPUI should be adapting the include line generation when you change the location of the GPUInstancer folder (unless you deleted any files).

You can take a look at line 2739 of the GPUInstancerUtility.cs (in version 1.4.4) to see how it works.

Thank you for your interest.

1) Any tool that only distributes prefabs in your scene is compatible with GPUI since GPUI isn't concerned with how the instances are distributed.

2) GPUI works with HDRP. As for raytracing, we haven't tested it with GPUI, but we have had reports from our users that they are incompatible.

3) No.

Lightmaps are not supported in any version of Unity. You can take a look at all the known limitations from this wiki link.

 

I'm using unity 2020.2f with URP single pass and VR (Gpu Instancer last version, and it happen with both eyes mode activated and deactivated), is there any fix for this?

 

I have recently setup a new project with Unity 2020.2 and MapMagic1 1.10.
I´ve imported the extension package and added the script to an emtpy object. Although there is a mapmagic object in the scene I get this. Any idea ?

 

Transparent objects don't seem to work with the latest version of unity and HDRP. I've tested this with a brand new project. After loading just the GPUI demo scenes, change any of the material's "surface type" to transparent and the object will fail to show up. Only the shadows are displayed.

 

hey hi, i'm trying to make it work on the nintendo switch, is there a turorial ?

 

Hi there, GPU instancer does not support the single pass instanced rendering mode; reason being they are two conflicting GPU Instancing solutions. It looks like in Unity 2020.2 they removed the non instanced single pass version, so the only way to use GPUI as such is with the multi pass rendering in 2020.2.

If you are sure that you extracted the correct integration package (MapMagic 1 and 2 have different packages), please make sure you have the MapMagic scripting define is added to your Scripting Define Symbols as such:

Please make sure that you are using the latest GPUI version (v1.4.4) since we have fixed an issue related to the latest HDRP in the latest update.

Having said that, transparent objects do not work well with GPUI, as is written here in the known limitations (there are various problems, see this for an example).

GPUI does not support Nintendo Switch (NVN is not supported).

You can take a look at the minimum requirements here.

 

ok ok , the thing is, Nintendo told me that GPU instancing work on switch, as you are "GPU instancer"
i was hoping for that, but thx

 

Just tried that on a fresh project. Manager says 1.4.4 too. Transparent surface type materials still don't show at all in HDRP. Only the shadows are showing up. This should be straight forward to replicate (using Unity 2020.2.4.f1). I understand the limitations, been using GPUI for some time, this has just been a show stopping issue porting things to HDRP. Everything else works great still .

 

Never mind. I was mistaken. It was an issue with a different asset.

 

I have a few questions about GPU Instancer being incompatible with Single Pass Instanced. I don't have enough knowledge about instancing so apologies!

Is the incompatibility because Single Pass Instanced doesn't support DrawMeshInstancedIndirect? And could Unity add support for it? Or is the issue that there is no performance benefit?

If I had an example that would greatly benefit from GPU Instancer, would it be better to stick with Single Pass Double-Wide Rendering and GPU Instancer, or go with Single Pass Instanced and no GPU Instancer?

 

Just found this error on a prefab where the material is already the instanced version.

Repro:
Turn off automatic shader conversion
Manually convert the shader using the assets drop down menu
Apply the shader to the material used by the prefab
Drag the prefab into the CrowdManager (Note, using the crowd add on)
Check the box to say I want to render this instance.

Edit: ah this looks like its because the assets menu isn't converting the shader for crowd animations but for standard GPUI. Is there an equivalent for the crowd shaders?

Edit 2: just found the docs on upgrading shaders, seems straight forward. This just wasn't clear because the core system has an auto updater so I was expecting an equivalent (I get why it doesn't though).

Might be worth updating this error text to point to the relevant page in the docs

 

@LouskRad Can you please update GPUInstancer to support the newest MapMagic 2 update?
It is complaining about the IMultiBiome thing within GPUInstancer. So I can't do Biomes until this gets fixed

I've tried to contact the developer over there to see what the replacement was but he's so swamped with fixes with the new update he must have missed it perhaps.

Obviously Biomes are still part of MM2, so he just had to apparently replace it with something, idk yet what lol.

EDIT
I am also getting this message a ton (as soon as I press play).
I'm in 2020.2.4 (not sure if it's related to the MM2 integration.)

Drops about 10MS in performance from this as it spams the error console.

Which leads to this specific line
(the line the error is leading too when double clicking it).

Code (CSharp):

1.                 Graphics.CopyTexture(unityDepthTexture, 0, 0, _tempDepthTextureForTex2DArray, 0, 0);

Error Code Below.

Code (CSharp):

1. Graphics.CopyTexture called for entire mipmaps with different memory size (source (Depth) is 2924168 bytes and destination (R32 SFloat) is 5848336 bytes)
2. UnityEngine.Graphics:CopyTexture (UnityEngine.Texture,int,int,UnityEngine.Texture,int,int)
3. GPUInstancer.GPUInstancerHiZOcclusionGenerator:UpdateTextureWithComputeShader (int) (at Assets/GPUInstancer/Scripts/GPUInstancerHiZOcclusionGenerator.cs:261)
4. GPUInstancer.GPUInstancerHiZOcclusionGenerator:OnEndCameraRendering (UnityEngine.Camera) (at Assets/GPUInstancer/Scripts/GPUInstancerHiZOcclusionGenerator.cs:248)
5. GPUInstancer.GPUInstancerHiZOcclusionGenerator:OnEndCameraRenderingSRP (UnityEngine.Rendering.ScriptableRenderContext,UnityEngine.Camera) (at Assets/GPUInstancer/Scripts/GPUInstancerHiZOcclusionGenerator.cs:196)
6. UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)

 

We did some tests on this, and it looks like HDRP 10 transparent materials (Lit and ShaderGraph) do not work with the DrawMeshInstancedIndirect calls - effectively meaning they don't work with GPUI. We will investigate this further, but it's highly likely that this is a Unity bug which can be fixed in an HDRP update.

Yes, Single Pass Instanced does not support DrawMeshInstancedIndirect. Specifically, Step 3 in this article breaks GPUI: https://docs.unity3d.com/Manual/SinglePassInstancing.html

Could Unity add support for it? Yes; but I don't know if they have plans for it.

However, whether it would be better to use Single Pass Instanced or GPUI would heavily depend on the project specifics (such as instance counts, etc.) and I would suggest testing comparatively.

This is related to the latest update made by MapMagic2. You can use the attached package (to this post) to fix this. It will also be included in the next GPUI update so you can safely update GPUI.

As for the other error you have mentioned, it was caused by the latest HDRP update. This in turn was fixed in the latest GPUI update. However, please note that there is currently an inconvenient bug with Unity that might misguide you into thinking you have the latest asset update where you actually do not. For more information on this, you can take a look at this forum post.

 

@LouskRad Thank you so much mate.

 

Hi, Just wondering if you have come across any issues using this system with sectr complete or worldstreamer. Any potential issues I might come across?

We are also using HDRP with many Nature Manufacturer and speedtree assets, will the transparent problem be an issue?

 

How to fix this error in unity 2020.2.6f1 Which Happens when occlusion culling is checked

Graphics.CopyTexture called for entire mipmaps with different memory size (source (R32 SFloat) is 5426400 bytes and destination (Depth) is 2713200 bytes)
UnityEngine.Graphics:CopyTexture (UnityEngine.Texture,int,int,UnityEngine.Texture,int,int)
GPUInstancer.GPUInstancerHiZOcclusionGenerator:UpdateTextureWithComputeShader (int) (at Assets/GPUInstancer/Scripts/GPUInstancerHiZOcclusionGenerator.cs:260)
GPUInstancer.GPUInstancerHiZOcclusionGenerator:OnEndCameraRendering (UnityEngine.Camera) (at Assets/GPUInstancer/Scripts/GPUInstancerHiZOcclusionGenerator.cs:247)
GPUInstancer.GPUInstancerHiZOcclusionGenerator:OnEndCameraRenderingSRP (UnityEngine.Rendering.ScriptableRenderContext,UnityEngine.Camera) (at Assets/GPUInstancer/Scripts/GPUInstancerHiZOcclusionGenerator.cs:199)
UnityEngine.GUIUtilityrocessEvent (int,intptr,bool&)

 

Works ok now. Tested on a 100 000 x 100 000 In Unity 2019.4.20. Maybe some bugs in 2019.4.16 Picture in left is the end of the 100 000 x 100 000 terrain, so grass is coming when camera see to that area.

 

We have problem using GPUInstancer and post-processing stack, ambient occlusion, in particular (marked by round frame in the image below). Semitransparent dark polygons in camera view. If turn off GPUI manager, artefacts are gone. I saw GPUI places invisible objects around the camera, is it possible to move these objects very far away?

 

Having a slight ... bug ?

When I try to paint detail on the terrain it doesn't show in the editor as the Terrain is selected; going back to the Detail Manager or Playmode it shows. Using TVE Grass. Turning on/off simulation doesn't seem to help in anything.

Using StandardRP/2019.4.17

Any idea why it does this ?

 

Unity 2020.2.7f, HDRP 10.3.2

Extra assets Amplify Impostors, The Vegetation Engine GPUI mode, Vegetation Engine Impostors Addon.

Do anyone experience same problem where GPUI dont render impostors if they are part of LOD group? My current setup on trees uses LOD 0 mesh as LOD 0 and Impostor as LOD 1. Additionaly in GPUI i add custom billboard which is Impostor. Impostors are made with TVE addon.

My setup

Tree prefab



GPUI





Ingame result




When i change the lod slider that lod 1 is rendered at lower % the trees are far more visible.

I am now not sure if its either TVE or GPUI issue on HDRP. Any help is apprecaited.

 

As far as I know. SECTr works by enabling/disabling mesh renderers - which does not work with GPUI. We have reports of our users using GPUI with Worldstreamer, but we don't have an official integration with that asset.

GPUI works with HDRP, SpeedTree 7 and 8, and so far with NatureManufacturer assets as well.

You can fix this by Updating GPUI to the latest version (v1.4.4).

If you are using the standard pipeline, you can look at the following for troubleshooting.

• I See Artifacts / Instances don't Show / Show at Incorrect Locations when Using a Custom Shader
• With Projectors in my Scene, I see Artifacts/Performance Hit
• Screen Space Post Processing Effects (e.g. Ambient Occlusion) Look Wrong

If these doesn't help, please make a support request using this guideline.

Please make sure you are using the latest version of GPUI (v1.4.4). You can use the Keep Simulation Live feature to keep the simulation active when you deselect the Detail Manager in your scene.

I'm not sure I follow the question, however, while using GPUI with Amplify Impostors, you can either use the impostor as part of the LOD group (like the LOD 1 in your example) or use the custom billboard feature with the billboard generator - but not both.