i think that occlusion culling, model level of detail for non streaming models, custom level of detail meshes and the option to only replicate objects to certain players would help reduce how many people use streaming enabled for the non intended use cases.
Going to preface this: I’ve read your entire reply. I understand your point of view. However, I can’t expect Roblox to optimize everything for me, and if I’m going to be honest I don’t believe it can. I’d much rather prefer Roblox to give me the tools to optimize my games, rather than Roblox trying to optimize them for me. I’d like to work in tandem with the engine- not against it, or without it.
I’d like to get some information/perspective myself on this- where can I see how much bandwidth streaming is taking up? Is there a debug menu for this? Because from my experience, the vast majority of data is remote events. The second would be physics. When I used streaming, I found net receive to be shockingly low (props to you guys for that!)
GPU overhead is the important part, though. While everything does universally increase FPS, if I have a detailed chair with 25 parts, and I have 50 of those, I think unloading those would save more than the cost of streaming them in and out. Plus, I must also acknowledge the fact that Roblox has no culling for platforms such as desktops. The majority of Roblox players likely have low-end desktops- where bandwidth isn’t that big of a deal. I would like to be the judge of these situations.
Honestly? No. I think that manually specifying what things should look like on each platform is a good idea personally- however I don’t think it should be required. I’d love to customize exactly what each platform sees. I understand it’s not feasible for Roblox to have occlusion culling, but being able to utilize the engine itself to optimize things enough to where it’s not needed would be insane.
so for me a creator who is trying to make the leap to streaming the biggest problems holding me back are the following
code errors: you address you will try to lessen the need for WaitForChild if this can really be done then it would go most of the way for alot of creators. if things can be streamed out and not affect my code then honestly i feel thats a huge obstacle removed having to treat everything like it might not exist and come up with some clever way to stop something important from popping out of existence when im trying to script on it would be awesome
not to mention some annoying things like creating an object on the server then passing the variable of the instanced object to say the client through a remote but it says part is nil because when you recorded the variable and passed it the object didnt exist for the client yet so you sent a variable for a nil object i end up having to try and wait for it to load for the client before sending it off which breaks the flow of what im trying to script having this delay
LOD color inaccuracy: You guys did a fix for this but there are still sometimes when a color defaults to black something using a texture for example like a surface appearance on alpha mode transparency rather than approximating the color from the image it just says nope and goes black sadly even if you give the item with a texture on it a color hoping it would use that it still goes black which is very disheartening
make LOD distance based on distance from a models bounding box rather then its absolute center if the size of a model is large its possible you can touch it without it loading which is definitely not the intended effect all of us expect the distance to be from the objects bounding box not its center like that we dont want you to be touching unloaded objects and unable to see it till you get close enough to its center
Sure, a way to use the LOD system to simply not render far-out objects that doesn’t involve me manually screwing around with Transparency would be great and tackles part of my particular use cases. This doesn’t completely supplant my desire for more fine-tuning with streaming though, as it doesn’t really help with memory usage. I just want to be able to tinker with things, break things, and figure out my own best practices myself without being restricted by annoying built-in guardrails / black-box behavior.
Models should be sent based on their extents, not just their center. Does making your model atomic fix the issue you are seeing? If your model contains multiple disconnected parts the LOD will be displayed until all parts are present, which could result in an issue like you are describing.
how do i detecting Instance Streaming on the server to see if instance exist on a specific client ? the tag method only for client to detect. Maybe something like Instance:GetStreamedPlayers()
In RoVille, I have “Neighborhood” areas where players can place their build plot. A lot of these plots have significantly high part counts with meshes, textures etc.
So these areas are very high part density in most cases. I wouldnt want the streaming radius to be very big for the content loading from the players’ plots.
On the contrary, the rest of the map doesn’t have high part count and would look extremely ugly if we set the streaming radius too low. As highlighted in the below images.
Being able to have a default streaming radius and then set specific streaming radii to specific models would be amazing as it could solve this issue completely.
I always appreciate additions and other changes which provide significant amounts of performance, especially since more complicated games require more specs. If I don’t have to resize my roblox player just to play at 35~ fps, then thats good for me.
Games that allow user generated content will definitely get the much needed boost that’s been missing, especially since some people have really complicated plots/builds.
Personally, I haven’t used too much streaming, so correct me if this is already implemented. But I would like to see the ability to stream parts or groups of parts (such as in a folder) by script command.
This would be really helpful with maps constantly removing chunks of items from the players’ view. For example:
I create a 5-point star-shaped building with 3 stories. The player is in leg 1 of the star on the second floor.
I would program it so that the 1st floor and 3rd floor of leg 1 and all floors in the remaining 4 legs are all streamed out. Anything on the 2nd floor that is outside the streaming radius (based on the auto setting) would be streamed out automatically. With the current implementation, I could be streaming pieces of other legs even though I know for certain that can’t be seen by the player so I can’t utilize all strategies that help with performance. Or if I used replicated storage, the items in storage still use network resources, unlike streaming from Roblox.
As a smaller request, it would be nice to see sectional streaming in studio like unreal engine 5. This way development productivity can be a lot smoother as well.
I’m using StreamingEnabled for a long time but one thing i will really want/needs is a way to make instance replication like adding a custom radius or a function.That will really help us.
Please can we have a function that lets us forcibly unload areas. Example being,
RemoveStreamedInstance(Instance)
I have to currently rely on streaming very big parts of a map, then using my own system to unrender child objects by parenting them to nil, which still has them referenced in memory. Possibly causing issues with streaming desyncing it.
I’ve been switching to a content streaming feature for a big project recently and I must say, it’s a great well thought out improvement except there are a few things that makes the development quite exhausting and tough
VERY IMPORTANT:
“Note that in the unusual case that your script adds a subtree to an already replicated atomic model the subtree will not appear atomically on clients. Subsequent stream in or out of the model will function atomically as expected” - This needs to be fixed. In my experience it’s not that rare to encounter and the worst thing is that it’s easy to miss this behavior while developing.
When creating an object on a server side and immediately sending it in a remote event/function to players, players don’t receive it at all. Would be nice if the received value was a reference that is nil until the object loads
IMPORTANT:
Atomic and non-atomic models are supposed to be streamed out when they are a descendant of the ReplicatedStorage or ReplicatedFirst (ex. Let’s say I have buildings under the workspace and keep their interiors in a replicated storage. Each time a player walks in, a proper one is parented to the workspace from a local script. Why would I keep these interiors streamed in all the time in a replicated storage as it is right now)
If the previous point was to be introduced, all parts without a model ancestor should be persistent, same behavior in the ReplicatedStorage or ReplicatedFirst
LESS IMPORTANT:
There should be a support for locally created attributes and tags for streamable parts.
Streaming distance should include a model size in its calculation apart from a game settings. Bigger models should be visible from further (ex. buildings, bridges), smaller from closer (ex. all kinds of props - plants, urban)
I don’t know what design decisions were made in the past, but for your issue it would be easiest to use the LowMemory mode, set the radius to the lowest value 64, then dynamical load the world around the character as they move. This helps low end devices because the small radius means they can swap our memory sooner for performance reasons or for those on systems with a low amount of system memory. For users with high system memory, the low radius helps with things a mile away from being rendered and burning CPU time on the client since you’ll have control on how far away they can see normally.
Thanks for your feedback on the known issue with post-replication subtree addition. We will discuss prioritizing addressing this problem.
On your point about ReplicatedStorage and ReplicatedFirst, can you give more detail on what you would like to see? Currently streaming only operates on instances under Workspace, so instances under containers like ReplicatedStorage are not subject to stream in/out. Are you saying you would like streaming to be applied to other containers in addition to Workspace?
Thanks for your feedback on the known issue with post-replication subtree addition. We will discuss prioritizing addressing this problem.
Thank you so much, this is honestly the main reason I’ve created this post.
On your point about ReplicatedStorage and ReplicatedFirst, can you give more detail on what you would like to see? Currently streaming only operates on instances under Workspace, so instances under containers like ReplicatedStorage are not subject to stream in/out. Are you saying you would like streaming to be applied to other containers in addition to Workspace?
Yes. I believe all rules should be applied to other containers as well, but with a difference that instances in these containers should not be streamed in even within the StreamingTargetRadius range. Basically a non-atomic model under ReplicatedStorage shouldn’t replicate parts to a client. An atomic model should not exist to a client. Persistent should have everything streamed in.
I want to make this clear. In my first post I said things make the development exhausting. This is not one of them. It doesn’t affect the development, but would make the streaming feature more effective.
My next point was related, because to make it easier for devs sometimes you store parts without a model, rather in a folder under ReplicatedStorage (ex. as a position data). If streaming rules applied in replicated storages you couldn’t even make these parts persistent in that case, so in my opinion they should act like persistent instances
Please give us more analytics. As far as I know, there’s no way for us to know how much memory, and network bandwidth streaming uses. This is crucial information to debug crashes.
Trying to design a massive game for PC and mobile but currently I’m either lacking knowledge or there is no way to set a streaming radius for smaller / weaker devices and allow for higher end devices to store more / unthrottle themselves?