On my game, i have a large map with detailed buildings and locations, and I utilize streaming enabled to reduce memory and optimize the experience, however doing this causes some massive lag spikes when streaming in or out parts of the map, causing for a very unpleasant experience, meaning i cannot utilize streaming.
Repro file and steps are contained in staff message
Expected behavior
I expect streaming in and out parts of the map to be smooth and not heavily impact my framerate.
I have an, arguably, drastically more detailed map than what OP has - as we have a 1 to 1 recreation of a city in Kyoto
The streaming in/out lag spikes is jarring, and doesnât align with any other AAA engine platform standards. I had assumed this was always just intended functionality, but seeing other bug reports, wanted to jump in
Here is a video of myself using our taxi system in our, marginally, outrageously detailed map. And, as you can see, the lag spikes are almost entire frame stops:
Our game typically uses VisTools to fix areas where engine fails on optimization, Iâve disabled it for the sake of the above video
For the sake of the video, I also lowered our streaming radius. I have it relatively large right now to mitigate the streaming freeze frames, but my ideal optimization route would be streaming having a lower target radius. Which just isnât possible as is. My ideal radius for such a detail-heavy map would be about 145, but I have to have it at around 1024 so that the game doesnât completely freeze frame
I really wanted to keep streaming radius as low as possible as, in principle, a low streaming radius would allow for a way more optimized experience with much less assets loaded. But as you can see by the literal freeze frames, it does more harm than good
My hope is that perhaps this gets better with Slim? But if this is not intended functionality with streaming, it is REALLY bad
This seems to be an inherent design flaw with instance streaming.
When stuff gets streamed in, youâre having to download all that data so you get Replicator ProcessPacket spikes because of all the new instances being added, on top of the fact that youâre likely having to build those instances as well.
So each time things stream in and out, youâre having to process a bunch of packets and create/destroy instances.
We are investigating what can be done to improve this and reduce frame spikes when instances stream in. Unfortunately I donât have an ETA on any potential improvements.
Are improvements towards lower streaming radiuses one of the issues being looked into?
As displayed above, detailed experiences would benefit greatly from a lower streaming radius â but that is literally not possible in its current state
Sorry, why is using a small value for the min or target radius not possible for you? It isnât clear to me what is happening in your video. What value of min and target are you using?
Do you have streaming integrity mode enabled in your experience? If so what mode are you using?
In my video at 00:27 you will see the video completely freeze. This is NOT normal for us and ONLY happens when streaming is set to a small radius. To stop the intense freeze-frames, radius must be set extremely high or to a point where the radius is large enough that you donât feel the streaming in/out
Our ModelStreamingBehavior is Improved, and StreamingIntegrityMode is PauseOutsideLoadedArea. StreamOutBehavior is Opportunistic
Our ideal radius would be like 124 or 250 ish. As explained, my game is INTENSELY detailed. For such a detailed map, best performance would come from a miniscule streaming radius
However, it is literally not possible to do a radius that small due to literal freeze frames (see video at 00:27). To completely counteract this and stop all freeze framing, the radius (same settings) is set to min 825 and target 1024
@Varyndor is your place publicly accessible? If so can you share a link? If it is private can you give me access? Iâd like to see what is going on in your situation.
Weâve recently (in the last couple weeks) rolled out an improvement to limit how long we spend in the ProcessPacket scopes. This should help significantly with this problem. Please try the scenarios you reported again. We believe this reduce the frame spikes, but it may not completely eliminate them.
Hey! The improvement does seem to have helped quite a bit, overall I am getting less lag spikes then I used to, however I still occasionally get large lag spikes (10+ ms)
Thanks again for reporting this and providing a repro place. We have some improvements in the pipeline that should help with this, and some longer term work under development.
Streaming continues to have the same problem; I even found this link on the forum while searching for it, and since I still have something to report, I preferred to use this post as it discusses the same issue.
I would say that Opportunistic mode ends up being the best for optimization, not only for RAM but also for CPU/GPU. The problem is that the way Streaming works seems to send all instances, and the client only does this within the same frame. I believe that if the instances were inserted into a table and a loop with 33ms (30fps) was performed, it might be smoother, also prioritizing the rendering of instances closer to the surface rather than those further behind.
I also want to add about Streaming that even using identical assets already present in the game, the lag spike is very high. Since games usually use cloned assets, I donât know if Streaming is creating a new instance as if it were unique, but it would be interesting to analyze whether cloning an existing object wouldnât be more performant, since the object itself would already be in memory. (Iâm not an expert in optimization, but I believe this makes sense)
Edit: I also want to add that Streaming seems more like a âChunkâ style where a piece of the map is sent via Streaming, and this seems terrible because the game seems to create all the instances and insert them into the workspace all at once, unlike when the piece is being removed from the Streaming, which seems to be one by one, much smoother. I would say that instead of storing the parts in some table and inserting them all at once, the engine should insert them one after the other, because even if the FPS drops a few percentage points, it doesnât generate this lag spike/freeze in the frame.
This video demonstrates that the problem with Streaming is during insertion, as it throws all the parts into the workspace at once, unlike when removing them. If insertion were as smooth and dynamic in FPS as removal, we would no longer have lag spikes with Streaming.
