What's Next for Streaming - We Need Your Feedback!

Hello Creators!

We believe that Streaming is a key component of scalable, more stable, faster to join, and gigantic experiences on Roblox. While Streaming is a powerful tool, we understand that in some cases Streaming has had difficulty keeping up with the complexity of some experiences.

In this post, we want to share why we’re leaning into Streaming, index all of the work we’ve done recently to fix the problems you’ve reported, discuss what’s next, and request your help to make Streaming even better!

Why Streaming?

Streaming enables you to create truly massive, truly detailed, worlds.

  • Our research shows that devs building with Streaming enabled have chosen to have twice as many instances than non-Streaming, and we expect that number to grow.

Streaming reduces join times by at least 20%.

  • Testing shows that even with more instances, join times improve by at least 20%. Streaming experiences have less to initially load, so players can engage sooner.

2x fewer crashes due to out-of-memory.

  • This significantly improves user experiences on lower end and older devices where out-of-memory crashes are the primary reason experiences unexpectedly stop.

What Have We Done Recently?

These recent releases collectively address many of the issues you might have had with Streaming in the past:

Streaming is easier to program than ever with Streaming Model Modes.

  • The new property Model.StreamingMode makes streaming easier to use with scripting and simplifies porting existing experiences to streaming.

Make your experience faster with Opportunistic Streaming.

  • Set desired streaming out behaviors, including a new opportunistic mode.

No more half streamed in vehicles with Part Instance Updates.

  • Improves how we stream parts that are grouped together into mechanisms and assemblies, such as vehicles and characters.

Reduce streaming pauses with Streaming Integrity Updates.

  • Fewer pauses are caused when objects haven’t been loaded in as a player or vehicle is moving quickly.

Make streaming experiences look great with Model LOD Improvements.

  • Increasing the Model LOD resolution and capturing the model’s shape and color more accurately, resulting in improved quality. Check out the video below that highlights the improvements.

Upcoming Work, and Streaming “on by Default” for New Experiences

Streaming is a key core system, similar to how we think about Physics, Rendering, etc. Here are some of the improvements we’re currently considering for future releases:

  • Even further improvements to LOD visuals (e.g. supporting motion).

  • Updates to our programming model to make coding Streaming enabled experiences more straightforward (e.g. further minimizing need for WaitForChild, simpler usability models).

  • More and improved debugging tools (e.g. networking simulation tools).

  • New educational materials (e.g. better docs, tutorials, etc.).

We are investing so heavily in Streaming because, again, we strongly believe that this technology will help unlock amazing, large, fast to join, and more stable experiences. With your help and support, we want to turn Streaming on by default for all new experiences so that more creators’ experiences will benefit from the improved performance, reliability, and engagement we think that Streaming will bring!

This means:

  • Workspace.StreamingEnabled = true on template places
    • You have the option to toggle this setting off
  • No required changes to existing experiences
    • Experiences with streaming currently disabled will remain disabled

Your Feedback is Requested!

What we want to achieve with this post is to take your pulse on how close we are to turning Streaming on by default for new experiences. We are not flipping this switch until we hear from you.

We would really appreciate your input on the following questions and please share any other comments or concerns you may have down below.

  1. What gameplay scenarios are still difficult to program despite all our updates?

  2. If still not comfortable with Streaming, what additional changes would be needed to make Streaming enabled your first-and-only choice for new experiences?

  3. What is making it hard to convert your existing experiences to Streaming enabled? What would make it easier to do so?

  4. What educational materials would you like to see?

Thank you.


For documentation, it’s unclear if Workspace.PersistentLoaded will fire multiple times for the same player when models are made persistent at runtime. Experimenting shows the answer is “no”.

It would be useful for the event to fire multiple times in that case, or for there to be another event which does. For example, in a game with rounds and a different map for each round, all unloaded maps may be stored in ServerStorage, and code may want to wait or listen for the newly persistent models from the new round’s map to be loaded.

An alternative would be to keep all maps in Workspace at distant positions, but consider a game like Super Bomb Survival, where all maps must be loaded to the same position for viewing from the lobby.


I would love to see a way to preview streaming settings in Studio rather than having to press play and test it there. A real-time view where I can see what my experience looks like with StreamingEnabled while in Studio would help immensely in developing experiences that are tailored to getting the most benefits possible out of it.


Roblox’s streaming system still has no way to define elements that should be streamed at a radius shorter or farther than what Roblox decides.

I want to be able to aggressively stream non-essential things like props or even other player’s vehicles at a distance shorter than Roblox’s dynamic default in order to squeeze more performance out of my experience. I’d also like to stream my world’s landscape at a distance further than Roblox’s dynamic default.

If there were a way to hard-set streaming radii for models / parts, categorize them with an Enum, or set a ‘scale factor’ that adjusts the streaming radius based on Roblox’s dynamic default, that’d be immensely helpful.

Opportunistic streaming was a good start, but it still doesn’t give us the ability to fine-tune streaming to fit our individual needs. Black-box solutions aren’t nearly as helpful to all developers in all circumstances as solutions that allow for fine-tuning per each individuals needs.


I just want to reiterate how massively appreciated these recent updates to Streaming have been.

Originally, the lack of developer control over Streaming was the #1 reason stopping me from ever using it, and it was so frustrating that Roblox had always insisted on forcing everyone into a broken “one size fits all” approach when using Streaming; every game is different and has its own unique needs. However, now that we can reliably ensure that critical assets will always be streamed in at the right time, and we won’t have to worry as much about unexpected script errors, I’m very excited to use Streaming for our next project.

Continued updates which allow us to fine-tune the Streaming system to fit our individual games’ needs will be a huge benefit :slight_smile:


The biggest feature missing from streaming for me is a lack of developer tools for testing and debugging, and it’s the main reason I haven’t used it in a production game yet. Being able to emulate devices with low memory is a good start, but ideally we should have more granular per-object controls to craft repeatable worst-case scenarios so we can make sure all bases are covered.

Thank you for taking the time to ask for feedback before going forward with this change! It’s much appreciated. :grin:


The newest changes to streaming are fantastic; namely, the Atomic model option has done a great deal for our Streaming game with a huge world, Find Everything.

If you look at one of the most-liked feature requests of all time, Custom Replication via Zones/Scenes, you’ll know developers have wanted some sort of volume-based streaming zone option for a long time. Current streaming does not allow developers to do this with ease. A new Object type or scripting functionality that allowed us to stream in areas based on volume would be potentially very useful.

For a more simple and broadly useable feature, I think being able to selectively choose players to stream or completely ignore Models would be a godsend. Replicating things to specific players only has always been a pain point when developing on Roblox, and built-in support would go a long way. This feature would work similarly to the newly-added PersistentPerPlayer option, but any Players who are not whitelisted would not stream in the model whatsoever.


Great communication! Here’s a cookie :cookie:


  1. fine control of streaming, as others have said. I want to remove nearby rocks and pebbles but keep massively distant sky scrapers.

  2. testability of all scenarios, in studio. This means lod viewing and testing too.

  3. ability to selectively replicate things to only certain users and exclude others

  4. streaming zones/volumes including terrain. Although you can code this manually atm it’s a huge pain. We don’t want to have to make everything miles apart in studio to have isolated building interiors or dungeons


10 words: Let us choose instances that are not affected by streaming.
whoops, turns out you already can!


Pretty sure you can already do this by setting an instance’s StreamingMode property to Persistent.


I would like to be able to set my individual loading distance for a model, for example: I want one tree to load with a distance of 512, and another tree with a distance of 256. I consider this to be a very useful feature because it is important to me that small details have a smaller loading distance, while larger ones have a higher one.


Are these those (SE) places that have been on internal mode for the past few months lol

1 Like

We need a way to stream in certain things at a certain radius. For example, I want a giant mountain to be streamed in at 5K studs away, but I don’t always want a random chair to be streamed in. If I could set that mountain to stream in at 5K studs, and that chair at 50 studs, that would be amazing.

As of right now, I’m okay with StreamingEnabled being default on all new created experiences.
Love the communication and the transparency. Please keep this up.


big +1 for this. I would love to switch over to StreamingEnabled, but I would like things like my terrain, buildings, trees, etc to have different distances to stream out.


Honestly, in my game I have “cinematics” and my game displays every now and then certain parts of the world that are far away from the character. Like a door opening, maybe something happening that the player’s camera will focus on that are really far away.

This is the main cause of why I do NOT enable StreamingEnabled. The function that Roblox provides for us RequestStreamAroundAsync to request an area to load in isn’t reliable as the API itself claims. Every time I change a player’s camera I will have to trigger a RemoteEvent to call the function RequestStreamAroundAsync. This is honestly really bad…

If there is a way to solve this issue in the best way possible, please let me know, don’t come up with messy solutions…

I used StreamingEnabled before and it was great until some users on low end devices sent me pictures of the Terrain looking totally black and certain assets not loading completely at all. Trees missing their leaves, some images not loading either, not sure what happened there and if is related.

Here is a picture taken on 2021:

Such images discouraged me from using StreamingEnabled as well as being useless after some time in the game where the player would crash after some time of walking around the map and some things were loaded in already.

Now I can give it another try, if I find a way of allowing cinematics to show up properly.


maybe an option for the models to fade into existence instead of pop in


i have a round based game that loads in new maps every round and i want that to load in nicely without causing a massive lag spike. due to the game being round based the map and lobby area should always be loaded so i can’t allow workspace to stream in/out automatically or use that functionality at all. however it’d be much easier if i can chose to globally load in and out a Model and have the engine handle that for me.

additionally we should have a method Model:GetPersistentPlayer(): Array<Player>


an event Model.PersistentLoaded(): Player


Awesome post! It’s really great to see how far streaming has come and how much is still planned. Speaking from my own experiences with trying to implement streaming into an existing large-world game, I feel confident in saying that streaming and related APIs are no longer the main things blocking adoption.

From my own experience as a developer of a game with a huge, detailed map, the things preventing me from implementing streaming into my projects are now just Studio and server memory.

On our streaming enabled test build with our full gameplay-ready map, studio often crawls down into the 15-20 FPS range and eats up ~15 GB of memory. Selecting services like Workspace or ReplicatedStorage (or really anything with a large number of descendants) will freeze up Studio for 2-3 seconds, searching/filtering for anything is super unresponsive, and starting and stopping tests can take minutes. Saving the place file, publishing updates, and even opening the places (especially with team create enabled) is another huge time loss because of the project size.

And this is just the place file where streaming is actually enabled. We have to work out of smaller / lite version of our game to keep studio performance from being a huge productivity killer. All our map and asset work has to be done in other team creates, and assembled and tested back in the main file(s). No matter how much we try to mitigate Studios performance issues, we can’t ever escape them. As our game grows in size it only gets worse.

These workflows feel counterintuitive to a lot of what Roblox has been working towards when it comes to project and asset management, but you can’t work on a big game without them. These performance issues are a big part of why I switched to a vscode + rojo setup. The amount of development time I’ve been able to take back from waiting for Studio to respond has been huge, even in the lite versions of our development environments.

Server memory is something I spend a lot of time on. Big games, no matter how you pack them, take up a lot of memory and the ~6.5GB we’re allocated on the server is not enough. On a 30 player server, our non-streaming/custom chunking system sits at the ~5.5GB mark. Our gameplay ready streaming build with 1 person in the server starts at 5.5GB and we can push it into the crash zone just by having more players join the server.

There is a lot I can do to convert my existing project into one that is more optimized for streaming, but memory headroom is a huge concern for me as a developer. Being able to build and stream these giant, detailed maps doesn’t mean much to me if the rest of my game has to min-max every MB of RAM left over just to function.

Having a big map is really only half of having a big game, and while streaming has made leaps and bounds to enable big games, other aspects of the engine and creation experience are not yet up to par. I very much look forward to seeing what further improvements are to come!


I think it would be great to be able to set whether you want an instance to be replicated to the client on creation per instance. It would be great for things that only need to be on the server to possibly save performance and internet usage especially if properties on those instances are being rapidly changed.

I don’t expect a change like this to be made but it would be nice especially going alongside other existing features like network ownership and with how dependent roblox is with client and server replication and stuff of that sort.

Other than that I think streaming is super neat and helpful for games with big maps, lots of high quality models, etc.