Inconsistent behavior when rendering StreamingMesh LOD models outside of arbitrary radius

Description of the “inconsistent” behavior:

  1. This only happens with objects that are very distant relative to the origin/player spawn. (11k+ studs)
  2. When the player first joins, they do not see the StreamingMesh rendered for these distant models
  3. Getting within this arbitrary radius (for an object placed at 11k studs and with TargetRadius set to 1,024, this is about ~1k studs in its direction; for the same object with a TargetRadius set to 512, it seems to only render at about ~5k studs) properly renders the object.
  4. Now that the player finally sees this object, they can leave the radius, reset, etc., and the StreamingMesh will still render for them as expected..

Sidenote on other weird behavior:

  • SLIM models (shown as a green cube in repro) don’t seem to render outside of TargetRadius, shouldn’t they behave the same way? If not, I’ll have to request this, since it should be able to replace StreamingMesh, esp. since it has pretty poor performance tri-count wise in my experience.
  • In the main game I was working on (with 500k+ instances/250k parts), the engine didn’t seem to bother rendering streaming meshes for models whose descendants all have CanQuery unticked. I could not reproduce this in the baseplate.

Simple repro steps:

  • EnableSlimAvatars = Disabled
  • ModelStreamingBehavior = Either
  • IntegrityMode = Disabled
  • MinRadius = 64
  • TargetRadius = 1024
  • StreamOutBehavior = Opportunistic
  1. Create a large model that can be seen from afar and set LOD to StreamingMesh
  2. Place it a far distance in one direction, 11k seems to be the minimum with default settings
  3. Test and get within this invisible radius by walking toward the model

Repro file:

Repro.rbxlx (1.4 MB)

  • There is a free model coordinate GUI for easy reference
  • The red cube marks a distance 33k studs from origin, click on the spawner to teleport to and from it
  • At the end of the trail of baseplates are the green (SLIM) and blue cubes

I recorded this video yesterday (the CSG plane was added later to make sure it wasn’t an issue with the lack of complexity my testing models had):

System info (just in case):

  • CPU: AMD Ryzen 5 7600X 6-C @ 4.7GHz
  • RAM: 16GB DDR5
  • GPU: AMD Radeon RX 580 & Raphael iGPU

I last recall messing around with rendering these meshes at such far distances in about 2023 or so. It worked fine then, and I’m pretty sure that this was a recent change.

First bug report!!! :grin:
Second time writing this, I hope it goes through…

Expected behavior

What I expect to happen in this case is that the client will know about and render the StreamingMesh from jump, but this is not how it works. Instead, there’s a weird logic involved that might be useful in some cases, and, in my case, is the opposite.

In my opinion, this behavior goes against what StreamingMesh is advertised as, which is a model that is able to be seen from afar. This could’ve been the designer’s intention, but if it is, the developer should have the ability to control this behavior with another unified “Behavior” setting..

SLIM does render outside TargetRadius, that’s the entire point, but SLIM requires saving your place file to the Roblox cloud (File → Save To Roblox). Can you try again after saving to Roblox? We strongly recommend SLIM over StreamingMesh because the visual quality is much better.

Thanks for the quick reply!

You’re right about the SLIM comment, the place I published to is 7 years old and didn’t have team create enabled.. I’ll have to look more into it, but it seems to be perfect for what I’m doing. Only gripe would be that I’d like to be able to set LOD based on distance in studs instead of size on screen for some less important objects, but I imagine that’s an unpopular opinion.

Anyway, now that I actually understand how it’s supposed to work, I can say for certain that SLIM is affected by this issue too.

Here’s a video showing it with the new SLIM models in green:

I’m assuming this was changed when SLIM was first released, so I’m hoping this will get fixed quickly and isn’t intentional. If not, I think I might experiment with manually adding and removing more ReplicationFocus when the player joins or something.

We have a hard limit at ~10x of the streaming target radius for SLIM due to some of the underlying setup.

This is (currently) expected, and also existed for StreamingMesh. Essentially everything gets streamed out at that bigger radius.

Got it, thanks for clarifying!

Any idea for when this will be looked into and added as a property that developers can toggle (or any other solution for that matter)? I imagine that creating a loading screen and using ReplicationFocus might work, but as I said, this isn’t ideal. It really limits what you can do with massive maps on top of the already existing floating point issues..

Also, you mention that the same behavior has always been in place for StreamingMesh, but I don’t remember experiencing this bug at all, not that I wish to accuse you of lying about it. I think I’ll do a test myself with the old map I was working on just to make sure the distances were large enough for this behavior to even occur.

Any idea for when this will be looked into and added as a property that developers can toggle (or any other solution for that matter)?

We’re looking internally at expanding this range in general, so hopefully you don’t have to! This will take a bit of time, just to be careful of any potential side effects.

Also, you mention that the same behavior has always been in place for StreamingMesh, but I don’t remember experiencing this bug at all

That’s interesting, we haven’t touched the core system dealing with the radius in a while. I’d be interested to know if you had a different experience.