Streaming meshes intermittently fail to unload for unclear reasons

Bug Reports Engine Bugs
#1

Reproduction Steps
Finding a consistent repro was tricky, but this can strangely enough be replicated 100% of the time just by selecting the model at runtime.

The following place file contains a basic cottage house with its LevelOfDetail set to StreamingMesh.

House.rbxl (53.5 KB)

Repro steps:

  1. Open the provided repro place file in Roblox Studio.
  2. Start a test session of the repro place in Play Solo mode.
  3. Paste: settings().Network.EmulatedTotalMemoryInMB = 1 in the command bar.
  4. Walk up to the cottage house until it has been loaded in properly.
  5. Under the explorer window, simply select and deselect the house’s model.
  6. Walk away from the cottage house until the streaming mesh appears.
  7. The cottage house will no longer load if you walk up to it again.

Repro Video:

I am not sure if this repro directly correlates with the problem, but it’s the only 100% consistent way I’ve been able to reproduce the malfunction. Other things such as alt-selecting a part in the model and dragging it, adding/removing decals, changing properties of parts, etc. will occasionally produce similar issues.

Expected Behavior

image
image1720×937 326 KB

The streaming mesh should never have problems unloading, even if something in the model has altered its bounding box or visual appearance.

Actual Behavior

image
image1720×937 267 KB

Streaming meshes sometimes get stuck in a limbo state where the mesh remains active, even if the underlying model has streamed in and can be interacted with.

Workaround
All I can do is turn off streaming meshes on models which are occasionally dynamic. Sometimes the issue corrects itself if the underlying parts are removed under memory pressure, but there’s no way to systematically work around this.

Issue Area: Engine
Issue Type: Display
Impact: High
Frequency: Sometimes
A private message is associated with this bug report

13 Likes
Skinned meshes not rendering properly given the position of the bones
#2

It appears the video on this post wasn’t made public.
I’ve corrected the issue. Apologies for not noticing this sooner!

4 Likes
#3

Thanks for the report and clear repro steps. We are investigating the issue.

We believe this is most likely related to mixing local and remote parts in LOD models. Recommend you avoid mixing those in the same model if possible.

5 Likes
#4

While I can avoid putting local parts into streaming mesh models, it makes things a little sloppy on the hierarchy end of things. Would locally modifying the Transparency of Decals affect anything too by chance?

The streaming mesh really shouldn’t kick in unless a remote part is explicitly marked for removal by the client to reduce the memory consumption. Whatever inferences it’s making now aren’t stable and result in these visual deadlocks.

2 Likes
#5

I realize not mixing local and remote instances in LOD models isn’t ideal, but it is the best workaround I can suggest currently. Changing properties like transparency shouldn’t cause an issue, it is related to adding local instances in the model.

1 Like
#6

I’ll look into this workaround and fix it where applicable, but local changes to models are inevitable in a few places for us.

It’s not entirely clear where all these problems are appearing, though feel free to check out the clip I provided in the private message attached to this post for more visual clarity to where we’re seeing this occur.

1 Like