I don’t normally post in these forums but this one has me stumped. In my HDRP project in an empty scene it idles at around 4% GPU usage. Adding a single empty Visual Effect jumps it up to 96%, both in the Editor and in play mode. I’m using a GTX 1660 Ti, low-mid range system in all respects.
I have:
Tried Application.targetFrameRate = 60 in an Awake function.
Updated to March 19th 2024 NVidia drivers.
Set the Nvidia profile for Unity3D to cap framerate, on/off/application controlled.
Set Vsync in Project settings (tried all settings, reset each time.
Tried empty VFX, added different VFX graph particle effects, messed around with relevant vfx settings (instancing etc).
Profiled the editor and play mode
Tried every combination of the above.
Obviously there is something wrong somewhere, as a single empty scene with an empty VFX takes as much to render as a full post-processing volumetric scene with all the bells and whistles turned to max. The profile hits UpdateScene > GUIView.RepaintAll.PlayerLoopController before total utilisation drops from ~97% in editor mode with an empty scene and 1 empty Visual Effect.
Did you check the profiler? Also deep profiling?
Did you try the latest LTS?
Did you enable vsync? (running even a simple graphic 600 times a second is rough)
Hey look, I appreciate the effort but if you read my post you would know the answer to half the questions you asked. I’ve tried vsync in-engine via settings, out of engine through Nvidia and limiting via runtime in script.
I don’t want to update to the latest LTS because the last few times I’ve done that it introduced a whole slew of new bugs (null reference to unity self, UI positioning being reset, camera clip plain randomly going infinite, etc etc).
I checked the profiler already, nothing useful. If you know of something useful in the profiler I should be looking for and why, it would be more helpful to suggest that than list things I’ve already stated I checked.
Something strange is going on though. When I toggled the empty vfx on and off, a white rectangle flared in the editor scene then the scene cam stopped rendering anything at all in the game view screen. This is in an empty scene in my current project.
Going to test it all in a new project and update unity. I don’t think I have a choice atm.
Aaaand to no one’s surprise, updating Unity to the latest version did nothing other than break some materials and custom shaders.
Made a completely new, empty project, restarted, made a new project with sample scene assets - same issue each time. Other than completely uninstalling Unity and reinstalling it, I guess that’s about it then.
It seems to me that it may be due to vfx component visible in view forcing a refresh of the editor by default. So if refresh rate is not clamped, it may cause high GPU usage.
In the scene view “toggle tab”, both Always Refresh and Visual Effects Graphs will cause this behavior. (Always Refresh will trigger refresh uncondionally and Visual Effect Graphs only if a VFX is visible in scene (even empty).)
So you can try enabling “Always Refresh” in an empty scene and see if it reproduces. If it does, this is due to editor refresh.
Alternatively, you can disable “Visual Effect Graphs”, VFX won’t be simulated and rendered in scene view anymore but it will remove the force refresh on the editor.
Thanks. I disabled Always Refresh / Visual Effect Graphs and set the Interaction Mode to Monitor Refresh Rate. I haven’t restarted the project yet because I’m in the middle of shooting footage, but so far it hasn’t made a difference at all.
I heard somewhere that VFX graph allocates memory/GPU resources even when empty/not displayed, in other words it doesn’t matter if it’s shown or not, if the game object is enabled it takes GPU resources regardless, which is consistent with what I’m seeing - disabling the VFX graph drops GPU usage to basically 0% in an empty scene with an empty graph (disabled, as opposed to an empty graph that eats 98% GPU).
Haven’t benched it in build yet because I’m working to a deadline I can’t afford to mess around with too much stuff at the moment.
It could just be that my settings are too high somewhere in the HDRP profiles and I’ve done this to myself. It’s fine though because other than having a large electricity bill and sending my gfx card to an early grave, it doesn’t seem to have much impact on actual performance.
I would suspect incorrect task manager reporting if the fans weren’t blasting away, so obviously something is being processed somewhere where it shouldn’t be.
Much like the OP, I don’t tend to post on forums much either. However, I wanted to report my findings. Having tried what @JulienF_Unity suggested (Change Interaction Mode in “Preferences > General” to Mointor Refresh Rate. My PGU usage went from 99-100% down to ~50% in both Scene View and Game View. While NOT running the game.
When running the game it jumps up to between 70 - 90% Which is a slight improvement. At least I can now edit my game without the editor crashing and Blue Screening my PC.
I won’t get into the Dedicated GPU Memory usage sitting at 9.5/10GB though… I need to look further into that…
I have experienced this issue for the last few Beta/Release versions of Unity.
It’s definitely a bug somewhere. Previously If I turned off Visual Effect Graph, it would disable the CPU cycles in the editor, and all would be good. But somewhere in the last 12months or so, I now need to manually disable the parent object of the VFX in the editor to stop CPU activity. (And my fans constantly spinning)
It’s a real pain, as I have to remember to reenable all my VFX before compiling each time, or have constantly spinning fans and CPU activity.
I just did a test watching CPU usage in taskmanager: (AMD 5900x)
1)With Visual Effect Graph Enabled: 25-30% CPU Usage via taskmanager in my scene idle.
2)With Visual Effect Graph Disabled: 25-30% CPU Usage via taskmanager in my scene idle.
3)Manually disabling the VFX parent object: CPU Usage via taskmanager. 0-0.5% CPU usage.
The Visual Effect calculations are obviously still running, even when they cannot be seen, the only way to stop it is to disable the object completely.
Also a related but separate bug (and may be the root cause) is if my root object is set to Center Pivot in the editor, my Root Transform Handle (Red/Green/Blue Gizmo) moves like it’s following a childs Visual Effect. (Have no idea why Unity have linked the two?)
For example: Here I have simple Cube, with a Child Object (Cigar) The Cigar has a Child Visual Effect (SmokeVFX)
For some reason when selecting the Cube Root Object, with ‘Center’ selected, The Transform handle moves (drifts away) in the editor, like it’s following the smoke VFX (even is visual effects are disabled). I have no idea why this should ever happen, but it to is one of the many VFX bugs added in the last 12months.
I would bet money that the CPU usage VFX bug is somehow related to the moving transform handle bug. The root handle should not be moving like a Visual Effect ever AFAIK.
And for Bug Number #3
Somewhere again in the last 8-12months Unity broke something with VFX Graph. It’s evident even in included samples from the package manager.
Fore example here is the Bonefire Prefab in Unity 6 Beta:
While in theory this is correct, I simply don’t have time file bug reports for every issue that Unity has. It would be a full time job to file reports on all the current bugs I know that have been an issue over the last 2 years.
All three of these bugs are easy to reproduce, I mean the 3rd one affects half of the samples in the VFX Graph Samples from the package manager. How these can go unnoticed for 12months, is mind boggling to me. It feels like nobody at Unity, has actually ever used Unity.
Currently using DX12 and XR, for 12hrs per day for the past 18months, I crash 40 times per day, every new version brings dozens of new bugs, but rarely fixes any.
If someone here posts a bug, and others confirm it, as has happened here. That should be enough for someone at Unity who is being paid, to look into and reproduce the issues and sort a fix.
I’ve reported 6 other bugs over the Beta versions on the forums, which thankfully have been fixed in later versions, And 3 current bugs in XR toolkit, two of which have been marked for a fix.
The forums should be a way for Unity to monitor and improve. Rather than a single bug report, we have multiple users discussing and confirming the issues on the forums, which confirms the issues are reproduceable.
My current project is too complex and large to make small bug test projects to send to Unity.
The bug that ‘CaptainSupreem’ reported here. Is obvious, it should take someone in QA, 30seconds to see the issue is real and reproducible. It took me 30mins just to make the screenshots and download the samples just to make the above post.
Those have now been fixed, but the bigger issue for QA is how these are going unnoticed for such a long time. I would like to see Unity improve QA by a massive amount. It’s really, really bad currently.
Back to my project and the constant crashes in DX12
With constant repaint crashes as mentioned by others in beta forums, 2 years everyday! I have had to deal with this crap.
I very much understand those frustrations, but you do seem to put a lot of effort into these posts. Copying that text in a bug report might already be good enough
Let me try to explain what is going on there, and maybe we can find a way to improve it.
First, about the CPU usage:
Currently, the meaning of the Scene visibility toggle for VFX graph is exactly that: VFX will not be visible (rendered) in Scene view. It does not apply to the simulation, which is still run, as you can observe if you open the Game view.
I acknowledge that it can be improved if we skipped the simulation when the VFX is set to simulate when visible and there is no other camera rendering it. We will look into that.
Regarding the Center selection:
When using this mode, the gizmo will be placed at the center of the bounding boxes of all the selected objects and their children. The fact that the VFX is not rendered in scene, does not change that it still exists and it has a bounding box. Even if we end up not updating it like I said before, it will still have a bounding box that will offset the center.
One thing you can do to stop the movement of the gizmo is to use a fixed bounding box for the VFX when possible.
About the samples:
Honestly, not sure what happened there. We improved the Flipbook Player node recently, and there is a chance that something went wrong when upgrading from the previous version. We will look into that as well.
Finally, as DevDunk mentioned, the best way to get something fixed is by reporting a bug. It may take time, as we in VFX graph are a small team, but it is the only way to ensure that it will be properly tracked.
I also understand your frustration, but be sure that we are working hard to improve VFX graph, keeping a balance between adding features and fixing bugs.
As per the OP, The issue is that this is not how it used to function in previous versions of Unity. It changed somewhere I think in the previous Beta series. (12months or so from memory).
To confirm I went back to an old laptop with Unity 2021.2 for example, and the issue is simply not present.
When I disabled the Visual Effects toggle, the CPU usage dropped to almost zero, without any need to disable individual objects.
I also checked the ‘Game View’ as you mention. In 2021.2 for example. The VFX are still active in the GameView, even when the toggle is disabled. When switching to Game tab, the CPU instantly ramps up, but otherwise is zero, when in Editor view.
This is expected and (good design) unlike the current version. I suggest that something has changed inadvertently in the behaviour?
So it seems like a bug and not a feature IMHO. Having excess heat, electricity, and lesser editor performance due to a CPU being hammered continuously by something that was previously easily disabled by a single click, and now requires me to disable a bunch of objects manually, seems like a large backward step from how previous versions functioned, and I would argue is definite bug.
As mentioned the above appears to be exactly how it’s previously worked in versions like 2021.2 for example. (I’m not sure what the last version that works correctly) But if you compare 2021.2, it works perfectly well in Editor and Game view without the performance and usability problems that are now present.
Again this is only a recent change (6-8months) and happened during the Beta series.
Checking again in 2021.2, this behaviour simply doesn’t exist. The transform never moves, it stays static at the center. (as I would expect)
Why should the root objects transform handle ever move? It makes no sense. When trying to move or adjust things, It makes it virutally impossible grab the transform to make adjustments, it’s like constant game of ‘Whack’a’Mole’
I would question:
A) Why should a Root transform handle, ever move? (I cannot think of a single benefit of trying to select a transform handle that makes it so hard to select because it’s moving across the screen like a particle)
B) Why is a parent objects transform inheriting movement from a childs visual effect?, I again cannot think of an example where this would be expected or desirable behaviour. I could perhaps see the Visual Effects transform itself, moved (although I don’t even see a use case for that), but why should it move the parents transform handle?
And again I reiterate that both these changes occurred during a Beta series. It didn’t happen in one Beta version, than I upgraded to new Beta, and behaviours just appeared and have stayed.
I will check 2022.2 and 2022.3 when I get some spare moments. But certainly in 2021.2, neither of these issues, were issues. They simply didn’t exist, I’m happy to be convinced that it’s an intended change for the better if it offers some kind of advantage, but from where I’m sitting these are both recently introduced bugs.
I did try and look why it was happening, but I couldn’t actually find the reason why it appeared to affect flipbooks and not others. Several of the samples have the issue. But I have some of my own VFX and not all of them were affected. I will leave that one with you. Thanks for confirming.
I get that and I do when I can… But sometimes it’s beneficial to have discussion and have multiple people confirm the issue. Here we seem to have an issue that is confirmed by me and the OP, but yourself is suggesting that it’s the intended behaviour. Based on previous versions I definitely disagree.
I certainly didn’t mean any offence, I know Unity devs are doing their jobs and dealing with a large and complex code base, where issues will always arise.
Sure. I was trying to describe the current behavior, not the previous one, or the ideal. It was not my intention to minimize the issue.
I think the behavior changed when we improved the culling. It was relying on the OnBecameVisible() callback before, now it is properly plugged in the internal culling system. What we missed is that VFX are passing the culling test even when their scene visibility flag is disabled.
FWIW, I did look into it, and found an easy fix for the case I described (only scene view and VFX is flagged as update when visible).
I also don’t see any benefit on this movement, but this behavior is just a consequence of how the system works (external to VFX graph).
This feature relies on bounding boxes to find the center of the selected object and children. If the bounding box changes every frame, the gizmo will move.
Once the previous issue is fixed, the invisible VFX won’t update and therefore the gizmos will not move. But it will still move if the VFX is flagged to always simulate, or if the VFX scene visibility is not toggled off.
The best way to avoid this is to have a fixed bounding box for your VFX, which in some cases will be beneficial, but not always.
Again, this is just a consequence of how the gizmo system works, not specific to VFX graph, and not something we can change. It gathers the bounding boxes of the object AND children to find the center. The movement is just an unexpected side effect of a dynamic bounding box.
For sure the discussion is beneficial, this issue is a perfect example of that. This is what these forums are for. But if something is only reported here, it is very easy that it will be lost while we are working on different tasks.
Sorry if it sounded like I was dismissing the issue. We are always interested in constructive feedback to improve VFX graph.
None taken!
One last thing. While your message definitely helped finding the issue (thanks again for that), it is not always the case that we can find a quick and easy solution. I hope that this does not become an example of how bugs need to be reported to ensure that they are fixed.
But please, keep reporting these things, in any case!
Morning, regarding the Bonfire and other Prefabs with Flipbook that are broken:
Updates have been made to the Flipbook Settings and Flipbook Player block. Update that allows the user to set the Flipbook settings once in the Output and this information can be used by the Flipbook Player. In the past, users needed to set this information twice.
Now, for this to work, the Flipbook setting changed from a Vector2 to the Flipbook type. If you had a VFX asset with Vector2 wired to this Flipbook Setting, it might have broken during the update.
The easy fix is to create a Flipbook Property:
A bug has been created, and I will share a link when the public one is available. We need to do a big cleanup pass on this particular “Additional Sample,” as it was made a long time ago and definitely needs to be updated/cleaned.
