Wouldn’t it make sense to have those parts streamed out by default and only stream them in when possible?
It’s basically what we already have but without having to go through every part in the workspace and selecting persistent to get the illusion of exclusivity
This means that once a subtree arrives there is less need for localscripts to use WaitForChild to ensure that instances have arrived
Good!
Hi
So basically this new way of streaming is atomic, but without all parts of the model being loaded atomically?
Took me a while to figure out all the empty models that had default streaming were causing lag. I’m happy this is now the behavior so others won’t have to run into it.
My fix was to just put almost everything as atomic (99% of models are small, tightly packed parts).
It would be cool if we were able to load in interiors via script, when we want to.
Will this be a thing any time soon?
Why has model uploading become so slow?
I waited 5 minutes behind the map for my entire city to unload
I have opportunistic
and I’ve tried legacy and improved.
Once again i have to ask for manual systems for streaming. I have nothing against the fact that roblox is offering their own automatic and very simple to use streaming solution for games. I believe these can greatly help beginner developers into quickly and efficiently optimizing their own experiences… HOWEVER, my problem is the fact that the automatic solutions are the ONLY ONES that roblox trully supports and allows while anything else that the deverloper’s can make are solutions simply by default way less efficient systems. The lack of support for manual systems in order for us to make our own potentially more performant streaming systems is and will always be a very bad thing regardless of how many improvements and updates the singular automatic one gets. I believe it is delusional to believe that its possible to make a “one size fits all” streaming solution. Every game has its own design, systems and other various things that simply all require different approaches to the same problem of streaming.
Also on a side note, i don’t think its worth sacrificing tons of server resources for a system that normally should be done ONLY on the client.
Hi. Player.ChararacterRegionId : Vector3 is spelt wrong- and has two ra’s.
That’s all
I’m not sure if this change is intentional as per deferred parenting but;
In Legacy model streaming, the model would actually be returned to the client, but with Improved model streaming, the remote function returns nil.
Here’s a code snipped of what I mean
func.OnServerInvoke = function(plr)
local mdl = Instance.new("Model", workspace)
local p = Instance.new("Part", mdl)
p.CFrame = plr.Character.HumanoidRootPart.CFrame
return mdl
end
In Legacy mode, this returns the model to the player, but in Improved mode, it returns nil on the player (I’m guessing the model hasn’t been loaded yet on the client to actually return anything from the server)
Love to see improvements to streaming, it makes a tremendous difference in memory usage.
Can we see more improvements in the direction of streaming LODs? I understand that Roblox prefers to do solutions that affect 99% of the userbase instead of more niche advanced developer features, but these advanced features are what turn Roblox into a professional engine rather than a toy for users looking to push the envelope. I would like to be able to provide my own LODs for roblox to swap out when models stream out. There is a CPU cost to doing this myself in software, and Roblox can likely do this much faster engine-side. I would love a suite of LOD related tooling that enables us to do authored LODs at varying levels that can either persist when streamed out, or cull entirely at distance.
I was previously using streamingmeshes for my biggest foliage models so I could show the overview of a large alien forest from large distances, and I wish I could continue to use them, but it turns out these models are excessively high poly and poorly representative of the original model compared to manually authored LODs (also, they look like pudding in comparison to my sharp poly art style). In an open world with content in every direction, including downwards (into flora-filled caves), since Roblox does not do occlusion culling or distance culling on streamingmodels, they are not good enough to improve performance in my game. IIRC there was mention of occlusion culling at RDC, but I’m not optimistic for this since the majority of my world does not have huge solid occluders, but rather many partially occluding pieces of foliage, it would exclusively help with underground assets only.
Instead of using streamingmodels, I recently set up software distance culling and LODs with MCR’s vis tools and this reduced my scene polycount from a staggering 3 million worst case to barely over 700k, and reduced my drawcalls by half. If I had a high fidelity game, streamingmodels might be very acceptable, but I do not. Due to the low-poly artstyle I already use, and the severe excess of overdraw I have in presenting a vast open world, I need to manually author my LODs for the best visual and performance result, and explicitly hide them when they’re out of reasonable range. In doing this I have to take the trade-off of not using streamingmeshes, so you can’t see the forest overview when it’s all streamed out, which is indicative of the current solution simply not being good enough.
This observation is correct. With legacy mode if you create a part via a remote function then it will not exist on the client when the function returns, and in fact may never exist on the client. This is the reason for the function returning nil. With improved model streaming this behavior is also extended to models, for a similar reason. The model that was just created may be sent later to the client, or never be sent.
While this behavior is by design we do realize this makes some programming use cases more difficult to handle. We are discussing options for simplifying this longer term, but I don’t expect this behavior to change in the near future.
I assume, by that logic, any table references to instances will also be kept?
Every time I see a post about streaming improvements I’m disappointed to see that it’s not the one thing everyone wants and has been asking for for years.
Please give us API for direct replication of instances. It’s incredibly difficult to make a large game without it.
These new changes seem to have broken Streaming Enabled for Prior Extinction.
The Roblox client all of sudden refuses to unload content, 1000s of studs away (roughly 6000 & 5000 respectively for the red lines), even though the render distance is set to 800 studs.
We haven’t touched our Streaming settings for months, and this issue seems to have only appeared within the last ~3 days or so.
Does this help with client freezing when new parts of my map are being streamed in?
This is a big issue with streaming enabled that I am hoping that it will get fixed.
No sadly, even worse news is that I think the new “Improved” has caused even more performance drops as our community members have started to report lots of lag since we had enabled it.
I have another new problem with streaming - Frequent freezes when unloading objects
My assumption - it is from the number of Joints (However, which I do not have on my map and they appear in the process of my game)
That is, the more of them, the more frees up when unloading the city.
For example, on a normal new and empty server everything is fine, the freezes are fleeting.
Now I will attach a video
Alas I can’t reproduce this on a separate game, but I’ll at least just leave it at that, maybe this problem is actually related to Joints
Our game has client freezes for both loading and unloading. Hopefully this is addressed.
A few developers reported that opportunistic stream out had become very slow to stream out.
We identified the cause of this issue and have resolved that problem. It was unrelated to this feature.
it doesnt seem to work anymore idk why
