Models set to StreamingMesh LoD reset their position to import location on publication

Bug Reports Studio Bugs
,
1

When you publish from one game over to another Enum.ModelLevelOfDetail.StreamingMesh based models will reset their streamed out position back to their import location. When we publish over to the new workspace we have to open it and run this script to fix the issue:

for i, v in game.Workspace:GetDescendants() do 
	if v:IsA("Model") and v.LevelOfDetail == Enum.ModelLevelOfDetail.StreamingMesh then 
		v.LevelOfDetail = Enum.ModelLevelOfDetail.Automatic 
		task.wait() 
		v.LevelOfDetail = Enum.ModelLevelOfDetail.StreamingMesh 
	end
end

Heres a video highlighting the issue:

Expected behavior

When you publish to a new game with the setting on models, those models should stream out in their static position instead of positioning themselves back to their import location.

5 Likes
2

Hi @Krcnos,

Thank you for the report. I was unable to reproduce the issue on my end.

Here are the steps I followed:

  1. Created a new place with Streaming enabled.
  2. Imported a 3D model, set its position, and changed its LevelOfDetail to StreamingMesh.
  3. Published the place to a different Roblox place ID.
  4. Observed the model’s LOD at the same position, which appeared correct.

Could you please provide a more detailed set of reproduction steps or share your place file where the issue is occurring?

3

Hey!

This is Kronos ( Development and Operations Lead for War Tycoon ). This happens in all our environments. In terms of the repo steps, it’s whenever we publish the game.

I can send you a file to the game privately if possible?

4

Please send me the file directly. Also, when did the problem begin?

5

Hi @KronosFUBAR,

Thank you for providing the place file for review. After publishing it to a separate environment, I was unable to reproduce the error.

My current hypothesis is that the issue may be related to our asynchronous process for calculating a StreamingMesh’s LOD. This is a resource-intensive task that runs in the background. It’s possible that when you move the mesh and then quickly close Studio, the calculation is interrupted before the updated LOD data is saved.

Could you please help us verify this?

  1. Can you confirm if you are seeing this issue consistently with the same set of meshes?
  2. Could you try waiting for a longer period (e.g., 10 seconds for each model) after relocating a mesh before closing Studio to see if the issue resolves? This would give the background process ample time to complete.

We appreciate your assistance in troubleshooting this.

6

Hey @narheas,

I believe you’re misunderstanding how to replicate this issue, we don’t move the mesh at all, we just publish the workspace and the issue happens.
I have attached a video to show how this issue happens, it can be replicated 100% of the time for us by anyone on our team, doesn’t matter what device you’re on or who does it and it also doesnt matter what workspace you’re publishing too.

The video is a little bit long so I have attached timestamps:
https://streamable.com/u0tb6h
0:00 - 0:16 | Showing off that both workspaces have the StreamingMesh set for the models
0:16 - 0:52 | Showing that the StreamingMesh works fine in the KizmoTek Workspace before being overwritten (It works fine in Development Hub too)
1:09 - 1:38 | Publishing Development Hub over KizmoTek Workspace
1:38 - 2:10 | Leaving Development Hub and joining KizmoTek Workspace, showcasing that the models are still set to StreamingMesh and were not moved prior to publishing
2:11 - 2:50 | Showing that the streaming meshes are no longer visible after the workspace got published over
2:57 - 3:16 | Running the script we attached above to fix the issue (It just toggles the StreamingMesh property)
3:17 - 3:56 | Showcasing that the issue is fixed after running that script

This issue is really annoying because we need to remember to run this script every single time we want to publish to the live game.
Please let me know if you have more questions.

7

Hi @KizmoTek,

Thanks so much for the detailed bug report and for providing the place file – it’s extremely helpful for our investigation.

I wanted to give you an update. Our team has spent time trying to reproduce the issue using your file, but unfortunately, we haven’t been able to trigger the bug on our end. For us, the models are keeping their correct positions after publishing.

This suggests the issue might be occurring under more specific conditions. Since we can’t reproduce it directly, our next step is to add some internal telemetry to help us gather more data on what might be causing the positions to reset.

We’ll keep this report open and continue to investigate. If you happen to find any other clues for the bug, please share it here.

Thanks again for your patience and for bringing this to our attention!

8

Hey @narheas,

No worries, I am not sure exactly what steps you guys are using to try and recreate the issue but if you need to add telemetry data in our workspace to help find the problem, we would be more than happy to assist.
Please let us know if anything is needed.

1 Like
9

Hi @KizmoTek,

We haven’t been able to reproduce the ModelLOD issue on our side so far. In the meantime, I wanted to introduce Scalable Lightweight Interactive Models (SLIM), our newer model LOD system that’s available in Studio Beta. You can try it by switching the relevant models’ LevelOfDetail to SLIM.

SLIM can help with:
• Higher visual quality for streamed-out models at comparable performance to the current ModelLOD.
• More consistent transitions by keeping all MeshPart LODs in sync within a model.
• Smaller place files since composite LOD assets are stored in the cloud and fetched on demand.

If you’re open to it, please give SLIM a try and let me know whether it improves the visuals or mitigates what you’re seeing with ModelLOD.

10

No worries, this issue appears to have been fixed sometime ago so I am not sure if something you guys did fixed it.

Thanks, we will be looking into SLIM once it is live!

1 Like