WorldModel instances consume physics step time every frame regardless of whether they contain any content or are visible to the player. Even completely empty WorldModels incur this per-instance simulation cost. With as few as ~30 empty WorldModels present, there is a measurable and noticeable FPS drop.
This makes WorldModels impractical to use at scale in UI contexts — for example, an inventory grid, character selection screen, or any scrollable layout where dozens of WorldModel viewports exist simultaneously but only a handful are on-screen at any given time.
Reproduction Steps:
Create an empty baseplate.
Via a LocalScript, create ~30+ ViewportFrames with Worldmodels. Set the ViewportFrames to Visible = false.
Observe frame time / FPS with the MicroProfiler.
Note that physics step time scales with the number of WorldModels present, even though none of them are actually visible or rendering.
Expected Behavior:
Empty or inactive WorldModels should have negligible (near-zero) per-frame physics cost. A WorldModel with no content, or one that isn’t visible/active, should not consume a meaningful share of the physics budget.
Actual Behavior:
Every WorldModel unconditionally participates in the physics step and consumes step time each frame. ~30 empty WorldModels is enough to produce a noticeable FPS drop, and the cost scales linearly, making layouts with hundreds of viewport previews (e.g., a shop grid with 500+ items) unusable.
Workaround:
The only known workaround is reparenting WorldModels to nil when off-screen and back when visible. However, a single reparent operation can take on the order of milliseconds, and performing ~20 of them during a single scroll event causes severe FPS spikes — so the workaround is impractical for responsive UI. There is currently no viable way to avoid the cost.
Impact: High — affects any experience using multiple WorldModels for UI (shop grids, character customization previews, equipment inspectors, pet/mount showcases). Especially harmful on mobile and lower-end devices where the physics budget is already tight.
Frequency: Constantly — reproduces 100% of the time whenever multiple WorldModels exist.
i hate whiteknighting, but this sounds logical.
Let’s assume I turn away and after some time return back: at which state I should expect to find things? Probably, they should not be frozen while I am not looking at them.
It was a feature request originally, but after being on a call with DevRel, I was told to make it a bug report instead
Also, the issue is that they update even if parented under a frame that is invisible. i.e., nothing is visually rendered or shown, yet under the hood it still updates rig animations. Imagine an inventory of 300 items, with only 20 at a time being actually visible. You’d think it should only render those 20 visible items, but it instead pays for all 300 at all times.
Sorry, I don’t know who this is, and how it is valuable being in a call with this person, so you have decided to bring this up here, but sure thing.
I am no way against fixing this.
I just presumed that the best optimization of A is not doing A at all.
In this case this means: everything what WorldModel’s physics provides to viewports also will freeze.
And, as you probably already suspect, that would raise other sort of complains: for example, let’s assume there’s a 1000 frames animation, player turns away on 50 frame for 200 frames, and on his return the animation should be at frame 250, as the player was looking at this all the time.
But if they will fix performance with nothing freezing, I am all for it.
Thanks!
Just to confirm, this isn’t a recent performance regression, correct? My understanding is in line with what @af_2048 posted, adding WorldModels to your experience is expected to degrade perf.
That would be correct. I originally made an Engine Feature Request post on this, asking for a WorldModel.Enabled property to toggle simulation, but after bringing it up to developer relations in a call, I was recommended to make it a bug report instead as they gain more traction.
I don’t have any qualms with this being closed as not a bug, it’s just unfortunate that WorldModels remain supremely expensive; as mentioned, them updating even when outside of ScrollingFrame bounds or when parented under a Visible = false frame leads to them bring unrealistic for any inventory scenario.
