Okay! I’m finally here. Sorry for the delay everyone.
@TheFlow3k: trace.start/trace.stop are new in 4.26 and will accept a comma-separated list of trace channels the same as you would with a MyProject.exe -trace=GPU,CPU etc.
The blueprints and scenes are still WIP and we’ll be releasing those as a sample later on down the road.
I mentioned in the stream that you can tell Unreal to output some info when a hitch occurs. That function is
stat DumpHitches
and will output a file into the Saved folder with that info any time a frame goes above
t.HitchFrameTimeThreshold
.
Someone mentioned having trouble with the foliage tool and collision: you’ll need to make sure that the StaticMeshFoliage asset you’re painting has opted in to Instance Settings -> Collision Presets set to BlockAll etc. By default foliage won’t collide so you gotta opt into it.
If y’all have any other questions from the stream, let me know!
@ozzymandias00 Hello, I dont understand or know what “visibility commands” under the “stat gpu” are. do you know this maybe? I cant find anything online. but its massivly tanking my performance and my map is tiny.
Finally got around to watching this performance optimization stream, yall talk this example project up and hold out. GIVE US THE KNOWLEDGE!! thx ilu <3
@Notoriousdude, totally missed this, sorry! VisibilityCommands is where we calculate what we’re going to render. I often see this number get really high in a scene with a lot of actors in front of the camera at a given time. It’s usually, but not always, high along with the number of drawcalls you see in stat rhi. Is that what’s happening in your scene or when you say small do you mean that you don’t have a lot of actors?
Hello, no worries, I did turn it into seperate levels, it has a lot of actors in it. its a house and when you stay outside it tries to render everything in it. thank you anyway. have a nice day.
Sorry to bump this topic up again but I’ve just watched the video on YT and found it very helpful.
I have very high numbers on RenderThread and GPU time going through my streaming levels, but those are only hitches that make my game stutter a lot.
Especially in the value PostInitViews_FlushDel in the stat render and in Visibility Commands and GPUSceneUpdate in stat GPU.
What are your advices for breaking down these stats?
Thanks a lot
Hey Cafo95! Those are usually related to a high number of objects in the scene and/or in the camera frustum. With VisibilityCommands, we’re trying to figure out what we can and cannot see before drawing pixels, so if you have a lot of actors in your scene, this can take a little while. I’d start with that! r.allowocclusionqueries 0 may help here, as it should turn that off altogether. If your total GPU time goes down with this off, that’s a good indication there’s too many primitives in the scene. You should also check stat rhi for the DrawPrimitive Calls value. I try to keep that number in the sub 10k range even for high-end quality settings.
@ozzmeister002 Thanks for the blueprints provided in demo level, they are very useful.
I just wanted to check re collecting trace files for UnrealInsights - are there any changes in 4.27 or UE5 that would make the processing of traces change?
Only difference is I’m running this in Standalone Game mode rather than building package and running after closing editor etc. might that be why my utrace files are outputting differently?
Hey Rossoe! I’ve actually got a article written up on the Dev Community that summarizes the video series I did with Quixel last year (which itself is a summation of the live stream). It’s also got some pointers about how things changed with the Insights console commands from 4.26 to 4.27 and 5.0. Check it out! Most importantly! The way I was suing trace.start/stop in 4.26 was replaced with trace.resume and trace.pause in 4.27 and beyond, so I had to go back and change my blueprint to do a trace.start CPU,GPU,Bookmarks,Log in the StartPerf event, delay a frame, then call trace.pause. Then in the DoPerfTest event I replaced trace.start cpu,gpu/trace.stop with trace.resume/trace.pause. Finally, in EndPerf, I’ll call a full trace.stop.
Ah sorry I should have spotted that in your article!
I’m fairly rusty with blueprints, I’ve just adding this blueprint into my own UE5 project, and I’ve assumed below changes from your comment above, however I’m not getting any utrace file generated into the Profiling folder.
Would you be kind enough to screenshot your StartPerf? as I think I might have messed the inclusion of new nodes -
** Update - seems to work fine now, when leaving the UnrealInsights open in background it seems to steal the trace to it’s cached location, rather than the usual Profiling folder! I also changed the Delay node on StartPerf to be ‘0’ **
