But you need to add a tag to all your parts. Seems unintuitive.
IMPORTANT: Before reading my replies, please note Iâm curious about more details on this feedback. So please take what I say as sincere questions and exchange of ideas and not as a road-maps or promises for what weâre planning on doing!
I guess the follow-up question is why would you want to do this kind of work yourself? While I agree that you know the context of your game better than we do, depending on what your unimportant props are and what purpose they serve in the game there should only be some subset of Game Engine subsystems that are going to be impacted by them being present in memory at all. If the props main overhead is Rendering, wouldnât you expect the rendering system to optimize this out for you automatically by providing a lower quality rendering, or simply not rendering the object?
I think a similar question to the above, if the Roblox Engine was optimized for stuff like this across the board, wouldnât that be a preferrable solution to having to manage these kinds of problems yourselves?
Thoughts as a System Designer/Engineer to Developers
Internally we try not to think of Streaming as a purely âoptimization systemâ. Itâs a scalability system, predictability, and consistency system. Something that lets you make massive worlds without having to partition, while simplifying the scripting within this context. When it comes to Perf optimization, there are many other Subsystems within the Roblox Engine that need to be responsible for the performance overhead of objects with the Streamed In area. From Physics, Rendering, Sound, and just the Lua Sandbox. If you only need the optimization in only one of those areas then Streaming this kind of stuff out is a pretty large hammer when maybe all you want is to just not tax Rendering System specifically.
A specific example of my personal concern for this
(This is a very naive example, but I think it highlights the difficulty of exposing a lot of micro-controls like multiple radii pretty well)
- Imagine you have a mobile device that has a MASSIVE amount of Memory, but is on a poor connection and poor GPU.
- Because you may assume mobile devices are weaker, you set their âunimportant prop radiusâ to be 1/3 regular streaming radius.
- This means as you run around the world you are constantly Streaming Out props and Streaming In new props as you get closer to them.
- Technically all you wanted to do was reduce GPU overhead of your art, but ended up using Streaming which impacted Bandwidth consumption of your players in a difficult to model way.
- This constant Loading and Unloading is now also Stressing the CPU as itâs taking new data and putting it Memory, which this device has a lot of and could have probably just kept it there dormant.
If you are having to go into every one of your games that you built and manually deciding âactually these objects shouldnât be present on Mobile Devices, and that object should only be present on Xboxâ because of performance reasons, doesnât that feel more like Roblox is missing a different feature to properly help with this?
Alternative Feature Idea
Separate from Streaming and all of the above, if Roblox had a system where you could specify things like âthis object should never replicate to Player Set X, but may replicate to Player Set Yâ, would that also potentially solve some of your use cases? A lot of people requested the ModelStreamingBehavior to also have ExcludedFromPlayer on top of the existing PersistentPerPlayer. The exclusion seems to be something that is relevant outside of the context of Streaming to me, because its an extension of what you can do on the Engine with Local Parts, but more finely tuned to let you spawn objects and specify what other Players or Servers can interact with them, and how they should be synchronized.
Curious to hear your thoughts on this! Again please donât take anything I said as a roadmap, just wanted to have a detailed conversation on these specifics!
Thanks for taking the time to read this and talk to me!
The current voiced concerns which I have seen from this thread seems to stem from a lack of behavior change based on prop size. Previous developers have mentioned streaming scalability based on prop size; larger, mountainous objects streaming at roughly within the same range as smaller, less game-critical assets.
I am not aware of how the streaming system functions internally and how well prop sizes (I presume at least bounding boxes) are still taken into account, but completely eliminating the need to render smaller assets which are completely encompassed by large LoD objects from far away could be a great help for optimizing the aforementioned usecases.
THIS
I went on tried out steaming enabled after learning how it works
and my entire map went from great to crap
mountains surrounding the ocean disappeared
the islands and bridges you expect to see gone
even if the islands were loaded somehow it would be blank because well no trees
it was a nightmare so I just abandoned the idea unless I decided to make a whole steamerscript that turns on some of the trees and just set the mountains to be always visible
I need a higher level of detail that seems almost as if it is real alongside some way to make for example a forested island not be blank
my suggestion is to base it on the expected camera angle
for example, you should not be expected to have players looking from the sky then you should load trees that would be in whatever is the desired visible range so a faraway island covered in trees for example usually if players are not nearby but should be able to see the island the trees on that side should be loaded and possibly a darkened area or something to obscure the rest
that would be amazing if something like that were introduced
Are your mountains made of Parts (and not Terrain)? Our current solution for this is Model.LevelOfDetail being set to StreamingMesh.
Long term we want to figure out what content needs visuals while Streamed Out automatically, and we want to improve the quality of visuals significantly.
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.
all of these should be separate from streaming.
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
This! Using streaming meshes on trees or foliage often looks awful due to the colors being extremely inaccurate.
Original model:
Streaming mesh:
People have been asking for this.
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()
Hereâs a visual example from my game.
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)