I want to confirm that this issue affects 4.16 as well. My HZB spikes up to 5,000 ms after migrating to 4.16. Previously in 4.15 it was consistently at 8-10 ms. Epic, please send us some guidance around this issue, if it is unfixable…
Yay yay yay,!
7ms on a scene…
The performance on vr preview is horrible! but not at all in a cooked .exe so maybe the HZB is only affecting the Vrpreview?
I wish i could measure how much the Hzb gets down to on a cooked exe…
Up to 25 ms for me on a classic project (no VR) with 4.16 and DX12. It happens on packaged game but on specific platforms … Even with occlusion culling, SSR and SSAO disabled. But for me the stat if “HZB” only (from stat GPU command), not mips.
And as I said, even if in your case it happens only on VR preview, in my case it happens in packaged game without using VR. So this issue with HZB is not concerning only editor (or VR preview), contrary to what Hobson confirmed when this thread has been created.
i have said it already,
THE LATENCY OCCURS ON VRPREVIEW, not in a “COOKED EXE”
♪♫♬ would -it-be-wrong-to-say-i “digress” ♪♫♬
So, 33448 is somehow marked as “fixed”, and yet…
4.16.3, the most recent engine version, so all fixes should be implemented.
What’s also peculiar, is that I get solid 60 FPS at the beginning, but then it starts dropping, fast at first, then slower, dropping maybe 1 FPS per second, until it hits rock bottom of 10 FPS
EDIT: I disabled two random widgets, and now the FPS goes well above 100…
Yeah, I have no idea either.
4.18 has resolved this problem.
this might be a bug. UE4.18 has solved this problem.
woah i thought my 40ms was bad.
i have a single point light and floor in minimal default, deleted everyhing else but still getting 40ms. PIE seriously unplayable. It doesnt matter if it only occurs in PIE, we cant package a game every time we change something to test it.
This is 4.16 so can anyone else confirm 4.18 fixes this.
I’m not sure what’s going on here, but I’m in 4.18 and I’m getting this exact issue. I’ve been working in this same project for easily over a month and not run into this. The rest of my scene renders in sub 4ms. 4.18 has not resolved this issue whatsoever. Pretty disappointing.
I ran my project in 4.17.2. the HZB setupmipmaps cost over 10ms. but It’s going faster in 4.18. It’s only cost 4ms. that’s a acceptable time for me. I don’t know what it actually is though. did you figure out the problem in your project?
are you playing in the normal editor viewport or the seperate pie viewport(the play icon with a screen next to it) as mine performs better in the normal editor viewport. it stills happens but less frequent.
i assume its to do with hzbocclusion which ive set to r.HZBOcclusion=0 in console variables but it still happens for some reason.
Running into the same issue on 4.18
wrong, I’m still getting this problem
yes it’s wrong because you are wrong. You are claiming a statement and he’s contradicting it with his experience. stop trying to be witty and pay attention
nope people including me are still getting the issue in 4.18
Messing around with t.maxfps seems to have an effect, if i let the frame rate go to high the HZB setup threads get pretty big but by the lowering the max fps it seems to reduce dramatically. Some sort of bottleneck maybe?
I was having this issue in 4.19.2.
Judging from some of the descriptions here, this won’t apply for everyone, but just in case it helps somebody: somehow I set my DPI scaling rule in the Project Settings to ‘Custom’ (without specifying any kind of custom scaling rule class). Resetting back to the default (‘Shortest Side’) got rid of the ballooning HZB cost.
It’s not surprising that this broke something. Any of the built-in rules (or correctly referencing a custom curve) would probably do the trick. For what it’s worth, I can repro (if you wanna call it that) on my machine by opening a fresh project, setting the scaling to custom (again without referencing a custom class), and opening the widget editor.