Updates to Streaming Enabled

[PysephDEV (Pyseph)]

I’d like to start off by saying - absolutely lovely how transparent you guys are! showing what you plan on working as well as consider working on is incredibly helpful to gauge and plan into the future.

Regarding per-instance control, I believe my (and likely many others) request from this derives from the uncertainty of how streaming works internally. Consider the following two scenarios:

• A small prop is completely contained inside a larger prop, such as a vase within a house. It’s streaming range should thus be affected accordingly to only replicate when in very close range, though I don’t believe this to be the case currently. Roblox wants to automate most of these issues from the player, but this seems hard to do considering edgecases with e.g. windows or transparent walls.
• Deriving off the first point, and this is moreso of a question, is model size considered for streaming? that is, do ‘minor’ and less important props such as flowers get streamed out faster than trees and buildings?

[StefanNL_Plays (Stef)]

Will there be an option to only select specific folders rather then having the entire workspace streamed?

aswell as the option to focus on the playercharacter, playercharacter and playercamera, or just playercamera?

really looking forward to see the possibilities with SE in the future!

[ParallelMayhem]

Bug Fixes

• Level of Detail (LOD) improvements to help with visuals. (In fact, we’ve already shipped a few terrain updates that you might’ve noticed!)

We have noticed a few changes to terrain LOD’s recently yes…
I’m part of a team that makes a combat flight-sim game where we use Roblox terrain for all our maps because of its ease of editing and comparably excellent visual fidelity.

About last week we noticed that the specular/roughness textures on the terrain now load out with distance, which for us results in super jarring “chunks” of different colored terrain.

On top of this, we’ve noticed much worse visuals with our terrain overall which is really disappointing for us and our players considering how well the previous LOD settings we working for us.

So our question is: can we expect more LOD controls specifically for terrain and terrain textures?

Cheers

[heedicalking]

The only reason I want streaming for my game is to quicken the loading speed of large Terrain pieces, but constantly streaming voxels in and out for 60+ players can overload the network and cause terrible ping spikes. Are there any improvements coming to how terrain is handled with streaming? It would be nice to have a way to publish a terrain so that it loads from a CDN rather than directly from the game server. It seems a bit silly to constantly need to transmit voxels for a terrain that’s static. I am targetting large playercounts of 100+ and I found that Streaming can cause a terrible latency for all players due to the amount of objects being transmitted.

[Denz_Noviembre]

Good to see engine performance being worked on, However…

@welblander

might check out for inspiration the new Modern City Template which has Streaming turned on - our early tests show join times for this experience to be ~1.4 seconds versus ~3 seconds with Streaming off!

I did some performance testing with Modern City Template. I wanted to check how well engine can handle detailed worlds.

I duplicated the entire city 5 times and placed them next to each other.
Even with streaming enabled, performance was terrible, CPU usage was over 100 ms, and most of the time I was getting barely 15 fps.

Keep in mind that the map wasn’t as big as it sounds, it was about 4k on 4k studs (with all the cities next to each other.

Then to further test studio performance, I deleted from the game all of the scripts, surface appearances, textures, decals, particle emitters, sounds, proximity prompts, trails, beams, surface guis, all the lights (pointlight, spotlight, surfacelight).
I also turned off CastShadow, CanCollide, CanQuery and CanTouch for all the parts and meshes, removed Unions, and anchored everything.
Changed the lighting technology to “Voxel”.

Even after this the performance was still exactly the same, barely 15 fps, both with streaming enabled on and off.

Sure, join (loading) time is extremely fast, however that is not at all the most important factor in performance. The above test showed that we unfortunately cannot build detailed and massive worlds, no matter how hard we optimize.

This is true also for small, but detailed worlds. Even roblox showcase games (Beyond the Dark, Duvall Drive), have extreme amount of lag.

Will this change anytime soon?

[MetatableIndex]

Adding on to this:

The current LoD is unacceptable for large worlds where terrain is a vital part of the gameplay.

In our game Glacier we have vehicle and infantry warfare, and this kind of terrain distortion ruins the possibility of long range combat or open fields.

Additionally, streaming takes 4 seconds (yes, 4 whole seconds) to load in the terrain when teleporting to different areas of the map. Faster join times are good, but not at the cost of making the game unplayable.

These features are also still very much needed:

Ability for smooth terrain LOD to load higher-detailed models near the camera focus

3 years later, this is still very much a needed feature. Big maps with open world terrain and combat are difficult to play properly at large ranges due to LoD not being controllable. There is no feasible way to currently load in terrain without disrupting player experience. Right now, a workaround is to force the camera and character to be near the terrain intended to load, but this is not ideal as it can cause players to fall (because of streaming) and doesn’t provide an accurate scope camera …

On a high end graphics card, shadows and terrain POP and it's not necessary

I’m going to go ahead and bump this and add a bit more information to this post at the same time. This absolutely needs to be worked on. Big terrain world maps, such as a game I’m developing, pretty much lose a lot of their quality because of this. They look horrid at big distances, all because of an arbitrary LoD limit. With StreamingEnabled enabled and low distance settings for the same, this is even more noticeable, and at some times, really game breaking: [image] This map looks complete…

[Queenlxys]

@welblander

We fixed an issue where mechanisms that used JointsService could be broken when streamed out and back in. While JointsService is still deprecated, it should work better with streaming enabled.

THANKS U, we don’t need to manually fix A-Chassis anymore!!

[NyrionDev (Nyrion)]

Here’s my attempt at doing what you said, I tried to copy the errors and behavior the WaitForChild function has:

function WaitForDescendant(parent: Instance, name: string, t: number?): Instance?
	if parent == nil then error("Argument 1 missing or nil") end
	if name == nil then error("Argument 2 missing or nil") end
	if typeof(parent) ~= "Instance" then error("Argument 1 must be an Instance!") end 
	name = tostring(name) 
	local descendant = parent:FindFirstChild(name, true)
	if descendant then return descendant end
	if type(t) ~= "number" then t = 5 end 
	local start = os.clock()
	local result = nil 
	local connection: RBXScriptConnection
	connection = parent.DescendantAdded:Connect(function(descendant: Instance)
		if descendant.Name ~= name then return end 
		connection:Disconnect()
		result = descendant 
	end)
	repeat task.wait() until result or os.clock()-start > t 
	if not result then 
		connection:Disconnect()
		warn("Infinite yield possible on '"..parent.Name..":WaitForDescendant(\""..name.."\")'") 
		task.wait(3.402823328927018e+38)
	end 
	return result 
end

[BillB1ox (Will)]

@welblander

• We fixed an issue where mechanisms that used JointsService could be broken when streamed out and back in. While JointsService is still deprecated, it should work better with streaming enabled.

• We are working on a few physics issues when objects are streamed in and out.

Not sure which one, but one of these is an issue with my game, Bloxy Kart in the Race place. Turning on StreamingEnabled completely breaks the Kart system probably because it uses legacy joints and Body Movers. I unfortunately tried converting them to the new system but it has not worked out well. As soon as these fixes ship, I will enable StreamingEnabled in the beta version of Bloxy Kart!

[Bakonowychlopak123]

one liner “WaitForDescendant”

repeat task.wait() until workspace:FindFirstChild("Object",true)

you can also

repeat task.wait() until workspace:FindFirstDescendant("Object")

and its the exact same thing both of those search for the descendant

[CatzRule_81 (Catz)]

Uhhhhhh that’s not really good for performance but, ok, it works I guess!

[Pharao13 (PharOs)]

The post is a bit old, but the problem has reappeared lately

Improvements to Model Level Of Detail (LOD)

Found some new bugs, this time it has todo with the rendering of the LOD’s, doing really weird things. Somehow the LOD rips its self apart. [image] The palms on the left that have Streaming Mesh enabled somehow don’t show up, but the palms on the right that also have Streaming Mesh on and who are in the same folder show up for some reason. [image] [image]

[devSparkle]

Thanks for taking the time! I’m aware that there’s a way to create a function that does this. For the record, here’s how I implement it when I need it:

local function WaitForDescendant(Ancestor, Name)
	assert(typeof(Ancestor) == "Instance", "Ancestor is not an Instance")
	assert(type(Name) == "string", "Name is not a string")
	
	local Descendant
	
	repeat
		Descendant = Ancestor:FindFirstChild(Name, true)
			or Ancestor.DescendantAdded:Wait()
	until Descendant and Descendant.Name == Name
	
	return Descendant
end

[devSparkle]

Thanks for taking the time to reply! First of all it’s worth noting that FindFirstDescendant has never been enabled.

Second of all, these methods require polling, which is inefficient, and they don’t support a timeout. To circumvent that, other similarly inefficient methods must be used. I’m advocating for a better, engine-implemented way.

[Aerodymier]

@welblander

Per Model and/or Per Player Radius Controls

• We are discussing allowing custom stream radii for models and players. Server performance and cost are real concerns with solutions here. We are thinking about this further, but we also hope we mitigate this with improvements in other areas.

This especially, is awesome. I’d really want to make this a setting in my game or have it as a script-controlled automatic setting for players with different hardware and network conditions.

By the way wouldn’t it help the server performance more than hurting it? If I have 20 players with 256 min. streaming radius vs 10 with 256 but 10 with 96 for example.

While I’m here I’d like to give some feedback:

• There’s a bug which results in terrain loading spiked (with deformed triangles) if streaming radius is less than 96. It happens with 96 and 64 and doesn’t happen with 128 min. streaming radius, I think this is a known issue, is a fix for this on the way?

• I use a system where elevators teleport to upper floor or another terrain piece. Players can use it together so I can’t yield the elevator for player loading, if I don’t though, some players just fall off of the map while loading. I have to use some sort of invisible local part tricks to fix this, maybe the collision data should be provided earlier than terrain textures or I’m sure Roblox has a better solution, just wanted to give feedback on this.

[Bakonowychlopak123]

well I guess use the FindFirstChild(“name”,true) method (its alternative of FindFirstDescendant when you pass the second argument as true)

[PysephDEV (Pyseph)]

Your code relies on polling and weird magic numbers, here’s a version I’ve used for a long time for my own game:

local function WaitForDescendant(Parent: Instance, Child: string, TimeOut: number?)
    local AlreadyFound = Parent:FindFirstChild(Child, true)
    if AlreadyFound then
        return AlreadyFound
    end

    local Connection
    local TimeOutThread

    local Thread = coroutine.running()

    Connection = Parent.DescendantAdded:Connect(function(Descendant)
        if Descendant.Name == Child then
            Connection:Disconnect()
            if TimeOutThread and coroutine.status(TimeOutThread) == "suspended" then
                task.cancel(TimeOutThread)
            end

            task.spawn(Thread, Descendant)
        end
    end)

    if TimeOut then
        TimeOutThread = task.delay(TimeOut, function()
            if Connection.Connected then
                Connection:Disconnect()
                task.spawn(Thread)
            end
        end)
    end

    return coroutine.yield(Thread)
end

[Maxwell_Edison]

I wonder if any of this solves the consistent replication problems I have been having.

I needed to play an animation when a part spawned, what I was doing before was firing a remotevent with the part as the argument, then animating it. With streaming enabled, even with the parts being marked to always be persistent, the parts were “slow” replicating - They were taking the Streaming process despite being persistent, and therefore came after the remote event fired, not before.

I got around that problem by giving them a unique ID tag so that if this happens, I can use the collection service to figure out what the part is still (probably a weird way to do it, but I had no other options)

Unfortunately this lead to a further consistent bug that I can’t even tell if is in my code or roblox’s - Everything fires correctly, but the things never animated. I think at the time of checking, the properties were seemingly changed correctly but were just… wrong. Like because of how I did it, it just wasn’t applying my changes or something very unusual. I’d print, it’d say it’s made the brick do what I want, but then would still just… not have an effect. Literally could not track this one down because it’s embedded into a lot of unusual code, so it’s hard to tell how far the rabbit hole goes here!

why am I so good at finding ridiculous bugs?

[DieselElevatorsRBLX (Hachiroku)]

So, here is a major streaming issue, and this is the sole reason why I do not use streaming on any of my places.

Let’s say I have a place focused on trains, which happens to be all of mine quite frankly. If I have a train which is, say, 20 cars long, everything is fine. However, if I have a train that is 40-50 cars long, the rear end of the train un-streams because it is farther away and the whole thing freezes and breaks. This is because there is no way to adjust the way object physics streams. The railcars on the train are connected via constraints, usually rods or ropes.

For this reason, my places will never use streaming because trains of that length are commonplace for us. As a replacement, I use a client-sided chunk loader for scenery objects, which isn’t as efficient as streaming would be but using streaming is physically impossible in our places.

[Maxwell_Edison]

I’m not exactly sure what the problem is - Streaming enabled somewhat recently has given the option to make things persistent. You can set the train cars, at least the base/primary parts of them and such, to be permanently streamed in. You can also set the entire train to Atomic, which would mean the train only is either loaded in, or loaded out, with no inbetween.

If the train is being physically controlled by the server, I don’t see how this would cause issue. Can you describe the problem more in-depth, as well as telling me some of the steps you’ve already tried to fix it with? There might be some solutions yet to the issue, rather than it being a problem with streaming enabled.