Streaming Prefetch API and Improvements to Part Handling

Updates Announcements
#1

We’ve recently released a new API to improve game experience with StreamingEnabled, and we are rolling out changes to how we handle the streaming in and out of parts in some situations.

The API, RequestStreamAroundAsync allows games to request that the engine stream around a specified location for a player, in addition to the normal replication focus. This is useful when the game logic thinks that the player may soon be teleported (CFramed) to a new location in the place and the game wants streaming regions to be sent around the new location in preparation for the player being there. This can improve player experience by avoiding streaming pauses and having content ready for the player when they are moved.

Examples of how to use the API are here:

Note that is API does not guarantee what will be streamed around the requested location, or that pauses cannot occur with the API. Other conditions in the engine, such as limited client memory, may prevent the request from being fully satisfied.

Local Part Handling

In response to developer feedback we are changing how parts created in local scripts are treated by streaming. Previously local parts were treated the same as server created parts and streamed out as needed based on memory pressure and distance from the replication focus. This caused headaches for developers since local parts clearly can’t be sent by the server when stream in occurs again. The change we recently enabled causes local parts to never be streamed out, unless they have ancestors that are remote parts. If the local part has remote ancestors then it will follow normal streaming rules. This allows us to give developers more predictable behavior while not overly constraining what can be done in response to memory pressure.

Part Under Part Handling

We are in the process of rolling out improvements to how streaming handles parts that have other parts as ancestors. Since parts can have ancestors that are also parts, and these parts can be arbitrarily far away from the descendant part, players could experience unexpectedly missing parts due to ancestors not being present on the client. The fixes cause ancestor parts to be sent if they are needed for stream in of descendant parts, as well as preventing stream out of ancestors if it would cause needed descendants to be lost.

We still discourage having parts as ancestors of other parts, preferring using models to group parts together.

170 Likes
Allow us to mark parts as constant so they never unload with streaming!
Force Streaming of Certain Parts
Long-Distance Beams not loading with StreamingEnabled
Clients never see BaseParts within a model that has been reparented to ReplicatedStorage on server start
#2
#3

This topic was automatically opened after 13 minutes.

#4

This is going to help me a ton, I’m currently working on a project that will hopefully be able to support 200 player servers while still remaining stable!

I’m gonna need all the help I can get!

3 Likes
#5

Yes, I love improvements to the Streaming feature of Roblox. Slowly but surely, this will allow more and more games to trust it and rely on it especially if their game is massive.

One thing though, you know how it says this on the Hub?

image
image1106×237 17.6 KB

I think there should be a way to check if the request is completed. Perhaps it returns something other than nil when the loading is finished or maybe a function on that returned object? IK that there is the timeOut parameter, but it’d better get the exact time when it finishes loading (which can be different than the constant number we put in). Sure, some clients will take a long time to load in in which we can implement a maximum wait system of some sort, but to guarantee that everything’s loaded in and there is no additional delay, I think this should be added.

Anyways, keep it up, Roblox! :roblox: :roblox_light:

21 Likes
#6

Updates to streaming is very much appreciated :slight_smile:

Currently, I use replication focus as mentioned here

I’m curious… Would using this new API be anymore performant than setting the replication focus?

My use case is that, in a round-based game, I want to set a replication focus in the area of the new map before player teleports.

1 Like
#7

Will this allow us to explicity declare what should not be streamed out?

3 Likes
#8

Very cool to see a new API have been added to Roblox, might find a way to use this one day and test it out, and especially with servers that will hold a lot of players and potential! :eyes:

The new API is very cool to use but curious about what it will do exactly?

Also, it is great that improvements are being made for Part Handling and how they are treated from local scripts and so on, a good thing that the Roblox team has done to improve development for us developers on the platform.

Keep it up! :happy4:

1 Like
#9

Can you call RequestStreamAroundAsync() on the client? Or both the client and the server? I’m hoping both!

Edit: Also, what does the timeout property do? Is that the lifetime we want to stream it in?

Also, what happens if I call this method a lot? Is that ok? How temporary is it?

7 Likes
#11

I’m very much a fan of these improvements.
Will we or can we have the ability to change the target radius for each client? Driving simulation games can go into densely populated areas in baseparts whereby the client will only need to see less because there’s only so much around. And I’m sure there’s other use cases for it too

2 Likes
#12

When the function returns it is completed, as best as it can. If it is done sooner than the timeout it will return earlier. We can’t guarantee it will be loaded since the client may not have sufficient memory available for both the current focus and the requested area.

4 Likes
#13

The risk with using the replication focus is that if you set it far away from the player and they aren’t moved there then they will not get streamed regions around their current location and they may walk off the map or hit streaming pause.

2 Likes
#14

So if I’m understanding this right, this’d be especially useful if you had a spectate feature that allows players to spectate other players that are far away?

in that case, would the area around my player simply stop streaming to my client, though it does not unload?

1 Like
#15

How big does the map need to be for this to have any real improvements to performance?
Kinda a vague question.

Cool features though!

1 Like
#16

If I’m correct, streaming helps memory at the cost of sporadic, eventful replication.

While exploring this for optimizing my case I came to the conclusion it is not for me, and possibly a bad idea. With users not suffering from geometry taking up too much memory but rather not rendering it I noticed that network replication had an indirect relationship with getting the full thing rendered:

With 36KB/S receive:

image
image1000×601 293 KB

With <10 KB/S receive:
image
image1014×624 335 KB

The players devices handle it, if they’re in the center of the boat the thing fully renders with no reported problems. Trimming off the stern is therefore somewhat redundant of whatever is approximating the costs.

image
image822×637 41.8 KB

Investing a week researching and experimenting with no results is a nightmare. So I’d like to ask if memory affects render, and by extension this new streaming API. If my idea of this, illustrated above, has any sense to it. I’m asking if RequestStreamAroundAsync center to the boat might help it render at greater distances, like at the bow and stern, or a submarine a thousand studs away intended to see it.

3 Likes
#17

Will we ever see an addition to the streaming system that allows for only certain objects/actors to be streamed in and out? The use case I see for this is that in large, open worlds, there may be very large objects or terrain that are far away from the player and should ideally always be loaded and never streamed out. However, small objects such as flowers, rocks, etc would be just fine to stream out at large distances.

(I’m not super familiar with the streaming system so I’m unsure if the streaming system already takes this into account.)

2 Likes
Allow us to mark parts as constant so they never unload with streaming!
#18

@Quenty the request API can be called from either the client or the server. The timeout specifies the limit on how long it will try and satisfy the request. If you call it multiple times there is a limit on how many simultaneous requests are active and you may end up cancelling your older requests before the timeout.

@Dev0mar the request API causes streaming to occur around both the replication focus and the new position, but it will cause less regions to be sent to the primary focus than before the request.

@dispeller if you expect to CFrame the player farther away than the target radius from their current position, and you have some advance notice that they might move, then it will be useful.

6 Likes
#19

I just read some stuff. So this is mainly for Wider Device Support and faster loading times?
Very cool

On a game I’m working on, I planned to split the world into a bunch of different places and have the player teleport between these places. That way I could have a larger map with minimal lag.
I might consider switching to using this instead. Or maybe a combo of the two.

1 Like
#20

When will the roadmap be updated to reflect these changes?

image
image1618×76 7.94 KB

4 Likes
#21

The roadmap doesn’t appear to be updated frequently. I think it’s used more as a way to communicate long-term engineering goals to the developers rather than the state of individual components.

Atmospheric Fog, Expressive Output, Enhanced Audio Search, and Plugin Debugger still all say On Track instead of Beta or Live.

6 Likes