In my game, there is a build system that uses a single static mesh (which is a combination of the full actor’s static meshes) for a hologram preview of the object that is about to be placed. I have found that some of the more detailed objects (the ones with 20k+ triangles) have a very severe performance hit (FPS drops from 60-ish down to under 20) when the hologram is visible and near the player.
I have tried changing the hologram material from transparent to opaque and that doesn’t change anything, so I have ruled out overdraw (right?). The full actor (with multiple static meshes instead of one large one) does not hit performance hardly at all (even with the added niagara particle effects and animated glowing that is not in the hologram). Turning nanite on helps a lot (fps only drops about 10 fps), but the model looks terrible with nanite on.
Another odd thing I noticed is that when there is no hologram GPU usage is at about 80%. As soon as the hologram is shown, GPU usage drops to about 30%. I expected this would be the opposite and GPU usage would max out which would be why FPS drops. CPU and RAM usage do not noticeably change between no hologram and having the hologram.
What could be causing this odd behavior? What tools can I use to track this down?
EDIT: The Unreal Insights tool directed me to investigate a check for supports in my build loop. The support check was looping through all vertices of the hologram mesh in every frame.
Thank you for the response, however as I mentioned, changing the material didn’t resolve the issue. I changed the material to a simple, solid color opaque material and still experienced the problem.
Is the hologram mesh properly optimized? How many polygons does it have?
Its would be best if you would record a session of unreal insights and measure what part of the scene rendering is causing the most impact. Perhaps Unreal does some preparation when creating the preview? Compiling of shaders etc.
Insights should show if it’s just the hologram or something else.
50k for a preview mesh is excessive. Especially if you are using transparency.
I would suggest using lod models for the previews with reduced poly counts. You will get a lot of overdraw in the case of full detail models.
The temporal dither aa masked method skips the overdraw problem.
You can also try messing with the render commands staring with r.oit
r.oit… (render order independent transparency)
Tweaking them might help with the frame rate slightly if you have overlapping transparent objects, though it probably won’t help with overdraw from within the same object.
if 50k is excessive, how are people using models with millions? Is there a trick I’m missing? Also, again, the transparency is not the problem and has a minimal, unnoticeable effect (if any) on performance. Switching to a material that is as basic as you can get, with no transparency (Blend mode: Opaque) does not change performance.
Nanite is the only thing that has improved performance (at the cost of quality). I appreciate you trying to help, but I don’t think you understand what the problem is.
I think the insights trace shows the issue, but I could use a second opinion. Theres a lot of info and I’m having trouble sorting through it. It looks like the problem is when I am checking for support under the hologram. It seems like it is having trouble sorting through the vertices. This would explain why it is only happening on the models with higher triangle counts. Can someone else verify (or explain what I missed in) my findings please? Frame 335 to 405 is where the problem is (when the hologram is visible). For this test, I have used an opaque, lit single color basic material.
Seems the rendering process is causing the hiccups.
You are getting hit with DiffuseIndirectAndAO calculations => which drill down to the process “LumenScreenProbeGather” that is eating up over 30 ms of your frame time.
Lights are also eating up around 13 ms. Are you overlapping many point lights? Try to keep overlaps down as much as possible as they can introduce heavy slowdown.
You might want to check your cvars regarding lumen. It seems they might be set too high for your hardware and it seems to be struggling.
World tick has a quite high frame time but I’m guessing it’s just waiting for the frame to finish rendering before the next tick. (the spikes in the graph seem to line up with the frame time more than tick)
I am not using any point lights. They are all Rect Lights and overlap a little to avoid large dead spots. I do have some lighting issues, but that’s a back burner problem for now. Where do I check cvars?
In any case, TheDiffuseIndirectAndAO and Lumen SceneProbeGatherer are fairly consistent throughout the entire trace and don’t increase in the problem area (frames 335 through 405), so I don’t think they are the cause of the problem I am looking to solve, unless I am reading this wrong. Agreed, they need to be looked into, but it doesn’t seem to be the issue at hand.
After a couple days of reworking the support check and moving most of it out of the build loop, I have confirmed that was the cause of the lag spikes. The support check was looping through all vertices of the hologram mesh every frame and on larger, more detailed hologram meshes, this was disastrous.
I may have also found the cause of the lighting performance hit as well. The post processing volume had Final Gather Quality in the Lumen Global Illumination section set to 5 (default is 1). I am pretty sure I set this to 5 when I was trying to eliminate noise from emissive material lights, before I switched to Rect Lights. I set this down to 2, but cannot test the performance impact until later tonight.
3dRaven, Thank you for directing me to Unreal Insights! That pointed me in the direction I needed for this issue, and the lighting issue I had intended to address later.
