[Full Release] Scene Analysis Tool


[quote]

[Update] July 10, 2026


Hi Creators,

Today, we’re excited to launch the new Scene Analysis tool that lets you quickly identify and resolve performance issues in your game, on both client and server. You should be able to catch and debug issues before they impact your players, and our goal is to give you the tools to do it

With it, you’ll be able to flip through different modes, including script memory, unparented instances, audio memory, animation memory, and an instance composition view. It also provides an extended scene triangle breakdown with counts for things like particles and terrain triangles. Each view will give you a real-time treemap view of what is consuming the most resources, both in the editor and when you open a test session, and then directly trace it back to the instances causing the usage.

You can also access Scene Analysis data programmatically through Class.SceneAnalysisService,more on the service here. Each method returns tables containing nested children with the same data the visual display uses.

Why should I use this tool?

We highly recommend opening the Scene Analysis tool every now and then throughout development, especially when you’ve recently written a lot of code or added a bunch of assets. It’s most powerful when you have it open during a test session; it’s the easiest way to spot “silent killers” like scripts cloning unparented parts, heavy memory usage from scripts, sounds or animations, or that “simple” new asset that’s secretly rendering a million triangles.

Regularly checking will allow you to tackle any issues faster; letting it accrue for too long and you may create a tangle of tech debt that you’ll need to spend time to unwind and resolve.

To try Scene Analysis:

  1. Enable the Scene Analysis beta feature in File > Beta Features.
  2. In the menu bar, select Window > Performance Summary > Scene Analysis.

Scene Analysis Views

  • Script Memory View: Pinpoints Luau memory usage across scripts and modules to help you optimize table and script allocations. Right-click any script to jump directly to it in the Explorer.

  • Unparented Instance View: Detects scripts holding onto object references to help you identify and fix potential memory leaks. Scripts holding onto Instances is completely normal on its own, but if you’re investigating a memory leak this view makes it easy to spot a script doing something unexpected. It pairs well with the Dev Console’s Luau Heap Memory Profiler when you need deeper allocation info.

  • Instance Composition View: Provides a high-level audit of all active instances to help you balance scene complexity and reduce replication costs. Maybe you didn’t mean to have 25,000 particle emitters - this view will let you know.

  • Audio Memory View: Monitors the memory footprint of audio assets and locates all active instances for efficient resource unloading. Right-click any audio asset to select all instances referencing it.

  • Animation Memory View: Tracks the lifecycle of animation assets to prevent common memory leaks caused by lingering script references. Animations are one of the most common memory leaks we see in production: Roblox aggressively unloads unused animation assets, but scripts often cause animations to stick around after their parent model has been destroyed. Right-click any animation to select all instances using it.

  • Triangle Composition View: Breaks down drawcalls and triangles to help you optimize viewport performance and scene density.

Hover over each rectangle in the treemap to understand what the asset is, and click to jump directly to the responsible instances in the list view below.

Script Memory Usage - On the left, you can see how much memory each script is using; the larger the rectangle, the more memory is being used.

Instance Composition - This provides a count of how many instances are in the scene; the larger the rectangle, the more instances.

What’s next for performance tooling

We plan to expand the Scene Analysis tool to include more metrics and different views, and we’ll share more as soon as it’s ready. Scene Analysis currently shows values from your local machine only, and memory usage will vary on players’ devices. We’re planning a device performance simulation API for tighter Scene Analysis integration with simulated devices.

We’re also building alerts into analytics so you know when there’s a spike in crash rates and other major regressions. The Assistant and MCP Server can already tap into Scene Analysis data through the APIs, and we’re working on ways to make it even more useful in your agentic workflows.

In the meantime, we’d love to hear what else you’d like to see us add here! Leave a comment or question with your thoughts below!

Big thanks to @KoalaSpaceProgram, @BobaTops, @MontxiMontxi and @Rusi_002 for their work in building this, and special thanks to @IcyTides and @ignotuscaligo.

376 Likes

This topic was automatically opened after 10 minutes.

I was present during the live showcase and Q&A of the scene analysis tool, and I do have to say, this is one of the best additions yet, we can finally have a tool that helps us dig deep and clean performance issues without needing to spend hours trying to find it with other tools. The microprofiler is nice and all, however it’s too complicated for new developers.

I’m speaking on behalf of all the developers, keep on pushing more optimization updates, and thank you very much, we’re looking forward to what y’all bring in the future​:100::fire:

56 Likes

Working on my own projects and at major studios, we had to create our own tools to measure performance and memory impacts in games/assets. With this addition, it becomes much easier for all developers to scale their games to reach more people with more precise optimizations.

Great job, Roblox

9 Likes

I have wanted for years to learn where I could optimize my game. No such tools have existed, or the tools that did exist weren’t user friendly. I can’t wait to dive in. Thank you to all involved, and please keep these optimization focused updates coming!!

36 Likes

Nice stuff!
What APIs does this tool use to read the script memory, is it from game.stats.Memory (which is hopefully fixed after a couple of months since my bug report)?

Side note would like the UI a bit more compact to only show metadata when hovering a square like this. Would that be possible? Making it scrollable would be nice too!

11 Likes

Absolutely banger performance tool, and I’m sure none are surprised to see you worked on it! Congrats on your first forum announcement!

3 Likes

Internally there is a new service., SceneAnalysisService that rummages our internal systems for the different memory views. This service pretty much returns 1:1 the same data that the treemap is displaying, so that agentic workflows can “see” the charts.

The data is pulled from the same sources as devconsole, we did indeed fix a couple of issues around memory → script attribution, but I don’t know if we addressed your particular bugs - do you have a link perchance?

11 Likes

Internally there is a new service.

Can this service be used on runtime or from plugins?

do you have a link perchance?

4 Likes

Really glad to see this shipping, this is something I’ve needed for a while. Having both a visual and MCP for it is a big win.

The feature request I’d love to see on the roadmap: historical snapshots / timeline comparison. Right now the treemap is a live view/paused view it seems, which is great for catching issues in the moment, but a lot of the nastier memory leaks are gradual — they don’t trigger any obvious spike, they just quietly grow over a session. Being able to pin a baseline snapshot at session start and then diff it against the current state 10 minutes later would make it far easier to isolate exactly which script or instance type is the culprit. Additionally, comparing a patched-branch vs. unpatched branch could also give nice insights too in order to see where improvements are still needed and what has been resolved.

Even something lightweight would be enough to turn “memory seems higher than before” into an actionable diagnosis.

Appreciate the SceneAnalysisService API exposure as well.

Kudos to you all at ROBLOX

1 Like

This is an incredibly valuable tool and exactly what I had in mind when I was discussing the limitations of the crash memory dumps.

Apologies if I’ve misunderstood but it seems this is only possible to use in studio at the moment yes? If so are there plans to get this into live games amongst the existing suite of memory analysis views accessible in the dev console? A lot of the issues I would be most eager to see with this probably don’t emerge until many hours of active play and only at scale.

7 Likes

yay now i can figure out what garbage i forgot to clear

2 Likes

Yup eventually. The beta might restrict access to sceneanalysisservice on clients right now, but real soon now.

6 Likes

Exactly what I was thinking when I wrote on historical snapshots / timeline comparison in my reply. Most of the leaks I’ve personally had to hunt down were completely invisible in a 5-minute test session, and it’s only when you’ve got a full server running for an extended period that the gradual climb becomes obvious. A baseline-vs-now diff would’ve saved me a lot of time.

2 Likes

Yes i agree with this post it would be wonderful if there was a version of this tool that could be integrated into live game whether as an addon to developer console or a seperate thing.

For me personally, I rarely notice or think about memory leaks while developing and only realize major issues during live servers that have been up for hours, so it would be a great addition to use this during live servers as well!

2 Likes

This is a good first step! My primary concern is being able to identify what exactly in a scene is contributing most to draw calls. In a large scene, using the Render summary, or this new tool (which provide similar information), it’s still nearly impossible to identify. Are there any plans for tools that would visually show me what exactly is problematic? Maybe a heatmap of sorts? Or, potentially even just a breakdown in the UI of what instances are contributing most to draw calls.

4 Likes

Not yet, we’re on it though.
The services exist on the server and we have plans to capture this data from prod to our analytics backend.

7 Likes

We want this too. Attribution of drawcalls to their parent instances is pretty tricky, but not impossible.

2 Likes

Looking forward to seeing how that shapes up. Have you considered snapshots/timeline comparisons, unless I have missed that it exists?

1 Like

When we gonna get heatmap
Char requirement char requirement

2 Likes