Level Streaming (possibly?) Issues.

[Moura]

Hey there!

I’m facing a bit of a hiccup with what I think are streaming levels in my VR project for Quest 2/Quest Pro. Let me give you the lowdown:

So, picture this: I’m creating a multiplayer VR experience where players hang out on a platform and teleport to different levels, kinda like stepping into an elevator. In the screenshot I attached, you can see all the levels in the editor. That cool blue box in the middle? That’s our “elevator,” and each of those other things around it is a different level, and they’re all in their own streaming levels.

Now, here’s the issue: After building the project and running it on the Quest, whenever I’m in a level and look towards the center of the world (where the blue box is), I get a serious hiccup and a big drop in FPS. I mean, it’s like the Matrix glitching out. But here’s the weird part – if I turn away from the center of the world and look in any other direction, everything is smooth sailing again, like buttery-smooth FPS.

Now, here’s the kicker – only the level I’m in and the persistent level are supposed to be loaded. The rest get unloaded when not in use. So why does it feel like these other levels are still messing with my performance?

Do you have any ideas, suggestions, or tips to help me wrap my head around this and fix it? Thanks a million for your help!

[Moura]

UPDATE #1: Profiling and Optimization Progress

I delved deeper into profiling and optimization to get a handle on our VR performance puzzle. (Although i’m still a bit confused with all the graphs and stats, need more time to learn and understand what everything means, but all values were well under control without any obvious issues).

To be honest, I didn’t stumble upon any groundbreaking insights. However, the Unreal documentation came to the rescue with some fundamental VR guidance.

During my investigation, I conducted tests on each level and noticed something peculiar – a few levels exhibited FPS drops, even within the editor (I’m running a RTX 3090, on a ryzen 9, so it’s pretty weird). So maybe, this oddity might be the root cause of the issue on the Quest.

Unreal’s VR tips covered a wide range of topics, from collision handling to LODs, materials, and lighting optimizations, addressing every aspect that could potentially affect VR performance.

I meticulously revisited each problematic level, inspecting every mesh, LOD setting, collision configuration, and lighting arrangement. I ensured they were all configured for optimal performance, given the performance issues we’ve been facing.

Surprisingly, after these adjustments, the FPS drop issue ceased to manifest within the editor. I basically made everything default, and set it up again - with the same settings as before… That’s why it is confusing that it gained performance, having exactly the same settings and disposition on the levels.

Now, my focus is on testing the project on the standalone Quest. I’ll keep you updated on the outcome.

Any feedback and tips are always welcome!
Thanks for your time!

[VictorLerp]

Testing performance in editor for VR is often going to be inaccurate. It can be used to track down major things, but hitches in editor can be a range of unrelated reasons to the application itself. The editor is performance heavy, and runs processes (even while VR previewing) that wouldn’t occur when running as a build on device.

[Moura]

UPDATE #2: The Confusion Continues

Alright, so here’s the scoop after testing this whole shebang in standalone mode – and believe me, it’s been a rollercoaster of emotions.

Let’s start with the upsides:

• Those optimization tweaks I talked about in the last update? Well, they did some good stuff. While they didn’t magically turn our performance into a superstar, I did notice improvements in certain levels.
• I took our VR experience for a spin, teleporting back and forth to every level in every possible sequence – and it went surprisingly smooth. No major hiccups to speak of, just some minor tweaks here and there.

Now, onto the not-so-great stuff:

• Here’s where things get a bit whacky. The smooth sailing I just mentioned? Yeah, that only lasted for a few rounds. Out of the blue, I’d hop into a level, and bam – the same old performance and FPS gremlins were back in action.
• What was once buttery-smooth became mysteriously plagued by these issues, and there’s no clear rhyme or reason to it.
• I cycled through all the levels, and the problem tagged along for every teleport ride, with some levels being slightly more cursed than others.

So, where does the glitch in the matrix lie? Well, I’m still scratching my head a bit, but it seems like it might have something to do with the code that handles our teleports, loads, and unloads.

Let me break down the code situation for you:

The load/unload events:

this images are the same line of code:
1-

2-

3-

• First off, there’s this panel on the elevator with a bunch of buttons, one for each level.

1* - When I tap a button, it triggers an event called “move elevator” and passes along the button number. The event then does its thing, adjusting panel info from a structure and applying it. After that, it checks if we’re dealing with levels 0 or 1.

2/3* - Levels 0 and 1 are the cool ones where the elevator actually moves up and down slowly. If it’s not one of those, the elevator shield closes up shop, loads the next level, unloads the previous one – rinse and repeat.

I’m still in a bit of a head-scratching phase here, but I’ll keep digging to uncover the source of this issue.

Thanks for your time!

[Moura]

Hello,

First of all, thanks for getting in touch!

I wanted to start by saying that I’ve come across your work here and there, and I even caught a livestream a few months ago about VR with Alex Coloumbe– and man… really impressive stuff!

I’ve been diving into the world of PC/VRmyself, with full-on ray tracing, and the results have been nothing short of incredible - Although that’s a whole different story!

---

When it comes to working within the editor, I did notice something interesting. Despite the fact that the results in the editor aren’t always spot-on accurate – I made some fixes to what appeared to be causing issues in the editor, along with some necessary optimizations, and it did help mitigate the problem to some extent.

Initially, I was enjoying a smooth experience, but then, out of the blue, things took a turn for the worse.

During standalone testing, I happened to spot a red error message right around the same time I noticed that some textures were taking a bit longer to load, and that’s when the FPS issue reared its head.

Here are a few specifics:

• I’ve made sure that none of my textures exceed 2048x2048 pixels.
• I’ve also made an effort to minimize the use of transparent elements.
• I’ve got about 10-12 static lights, one in each level, and they don’t overlap.
• On the shader complexity front, everything seems to be in the brownish-red zone, indicating that they’re not exactly ideal, though I’ve been struggling to significantly improve this.
• I’ve implemented LODs as expected.
• Collision-wise, there isn’t much going on anywhere.
• In each level, almost everything is completely static, apart from some fishes in a couple of levels that are underwater.

Now, here’s the kicker: Each level is actually quite light on assets. Some might have a few more triangles than strictly necessary, but nothing that should be causing this level of performance trouble, especially after it ran smoothly for a few rounds.

At this point, I’m starting to suspect it might be a logic error. Perhaps something’s awry with the way I’m handling the loading and unloading processes, or it’s possible that I’m not entirely loading the streaming levels as I should.

To sum it up, I’m in a bit of a head-scratching phase, trying to make sense of this perplexing situation.

If you’ve got any insights or suggestions, I’d be all ears!
Thanks for your time!

[VictorLerp]

Thanks for the kind words

Can you reproduce this while loading the same level over and over, or does it only reproduce with different levels?

[Moura]

Hey,
Things were all good in the first two levels (the ants are in level 2)of my VR experience for the Quest. But when I hit level three, performance went south – and it stayed that way, no matter where I went.

I played detective this morning and cracked the case. The problem was the blueprint that spawns the ants, who follow a set path along a spline. This blueprint lived in the second level’s streaming world, coming and going with it.

Now, here’s where it gets interesting: In the second level, everything was A-OK. Ants spawned and got destroyed when they reached the end of their journey on the spline. No problems there. But when I left that level, the ants that hadn’t reached the end of the spline hung around, never getting destroyed causing trouble when I returned, and even if not, they stay there.

And it wasn’t just about the number of ants. I tried optimizing them, making them 2D instead of 3D, randomizing spawn times, and simplifying or removing animations – but the issue stuck around. With 1 or 100 ants, exact same result.

So, my solution for now is saying goodbye to the ants. I don’t have the time to dive deep into fixing this at the moment, so I removed the ant system.

The result? Smooth experience, capped at 90 FPS.

If I ever revisit this issue, I’ll be sure to share how I fixed it.

Thanks for your time @VictorLerp