Although it may not be officially supported tooling, it feels as if this page fails to provide a full and accurate picture of the tools available to developers for identifying the sources of both rendering and loading time performance concerns.
This can be replicated by adding additional sections mentioning features such as the extant ability to print the percentage of loading time each instance has taken in console automatically upon loading any edit session in Roblox Studio.
Additionally, it may be worth providing some basic-level explanation of how rendering memory use occurs and how to improve rendering performance - either through the use of guides such as can be found on DevForum right now or through the use of software such as NSight Graphics or RenderDoc.
Hey Polaris, thanks a bunch for the feedback. Do you have any code you’re comfortable sharing for the “percentage of loading time each instance has taken?” I have some crude printouts going (e.g. “15 instances in 0.04 seconds”), but I’m not seeing a straightforward way to get an instance by instance breakdown.
For rendering, you’re right that I doubt we want to delve into the realm of external tools. Are there any bullet points you’d suggest adding here or here?
These won’t be exact messages to put in 1:1, however:
For the “percentage of loading time” portion, the File -> Studio Settings -> Network -> Diagnostics -> Print Join Size Breakdown option, from what I can tell, actually automatically will print the path of the top few most time/network-intense instances in a place to console upon joining a TeamCreate session when enabled.
Along with the File -> Studio Settings -> Network -> Diagnostics -> Print Stream Instance Quota option, it serves as a useful tool for certain optimization work - allowing for developers to see if there are any significant outliers they may be able to address.
Meanwhile, there’s a few things I’d suggest adding to the section regarding draw call optimization:
A note that, when discussing draw calls, each primative option for BasePart instances and each uniquely created SolidMesh asset (CSG-based assets, including UnionOperation and negations) act in the same manner as any other Mesh, would likely help address certain misinformation regarding rendering optimization that has been distressingly pervasive over the years.
An explanation of how Particle draw calls work may be of use here - as they act differently and can have exceedingly drastic performance impacts when used in certain ways (i.e. property ramps between one or more positions above size 10 when LightInfluence is set to a nonzero value). Such cases may necessitate developers intentionally creating a seperate draw call via uploading a duplicate image asset so as to spread out the render performance impact in a manner that can more easily be handled by modern graphics processors.
It would likely be of value to put in a note that it is wise for developers to measure draw calls on multiple graphics level/engine settings when they are able to do so (as can be set via their respective options in File -> Studio Settings -> Rendering), as doing so is vital to capture any platform-specific irregularities.
There may be value in having someone from the rendering team guest-write an article/forum post acting as a deep-dive into how draw calls work on Roblox at some point in order to allow for developers to learn more should they wish to do so. After all, the most effective way to learn more in regards to this type of topic is to learn more about how rendering works from a more technical level.
Downloading a CSG Operation made using CSG 3.0 or newer to a .obj file and directly re-uploading it into Studio does not typically produce an improvement in rendering nor memory use under normal circumstances.
This would make sense under several different sections, to be honest - however, it probably should be written down somewhere as it remains a common misconception.
As far as asset memory usage is concerned, there’s only one or two notes I have to give:
Ensuring that you do not include unnecessary data (i.e. an alpha channel on a solid color image without transparency/AO) can marginally decrease asset memory usage for images. Furthermore, per-compressing images can improve performance in some cases, doing so varies in effectiveness depending on the images in question.
An example script for the following section may be worthwhile to include. Although a better means of enabling developers to manually review assets for duplicates is absolutely possible, such a thing would fall under the scope of a dedicated separate feature request.
Though there is no API to detect similarity of assets automatically, you can collect all the image asset IDs in your place (either manually or with a script), download them, and compare them using external comparison tools.
Extraordinarily helpful, thanks so much. I made some fairly small, calculated changes to Identifying and Improving, particularly around loading times, particle emitters, testing at a variety of graphics levels, and asset stripping/compression. I doubt it’s at the level of detail you’d like, but rather than deep dives into behavior, we typically prefer more straightforward “be careful with X, because Y”-style recommendations.
I have someone in mind who can hopefully review your CSG feedback in the coming weeks; my very basic testing was inconclusive, and it’s not an area of strength for me.
I’m also giving the asset ID grabber/downloader script a look, but depending on level of effort, I might punt on it. Thanks again!