Part Instancing - pre-release announcement

Batching Effeciency? Add this please

1 Like

Great thread! Really interesting to read.

One question regarding batching efficiency…

Is this limited to each individual cluster?

If I have two identical MeshParts in close proximity, they are both rendered in one single draw call. But, if I position them further apart, they’re split into different clusters and are rendered in two separate draw calls.

Will the latter have a negative performance impact?

5 Likes

This is a gold mine of effeciency knowledge. This information should be put on a wiki page for easy reference in the future.

3 Likes

Will instancing apply to adornments?

Finally!

Currently we only instance within one cluster so if two meshes are far apart they will render as separate draw calls. This will likely change later. Note that the memory for mesh geometry is shared across clusters - we just don’t batch draw calls across clusters.

4 Likes

How close does two parts/meshes need to be for them to be considered in the same cluster? Is there a certain threshold or do they work like “chunks”?

Thank you for such an informative post :smile:

This is great, seeing the rendering engine become more optimised is something I’m always happy to see.

3 Likes

This is the type of post I really enjoy seeing, very full of details without getting too technical, but enough to get my mind working on how to be more efficient in my building.

3 Likes

They work like chunks with size 128x64x128 studs. FWIW I would not advise designing your levels for this or anything - these details may change and shouldn’t be critical to performance with further improvements to the system (such as cross-chunk draw call merging)

Yeah this is correct. Each unique combination of stud types on surfaces results in unique internal geometry and we can’t instance that. So if you have a block smooth-on-all-sides and a block that has one surface marked as studs, we won’t render them in one draw call. You might want to use smooth-on-all-sides blocks for other reasons (such as performance of place loading due to internal physics operations that run on place load).

2 Likes

Want to update the thread to mention the progress:

  1. Part Instancing
    We’ve been going through the rollout, discovering a few small bugs and fixing them along the way. It’s really close as far as we know - it’s currently disabled, but we’ll try to enable it in the coming weeks on desktop. Didn’t quite make RDC US, but will definitely make RDC EU :wink:

  2. Inter-cluster instancing
    We’ve implemented a feature that allows merging objects from different clusters into a single draw call dynamically. This is live of desktop as of right now and currently means that any Mesh/CSG parts that are clones of each other and are in the view will be rendered with a single draw call regardless of where they are. This also opens up opportunities for significant optimization of transparent part rendering - with part instancing and this combined, we’re seeing less overhead for transparent parts which is awesome.

  3. macOS performance
    We’ve discovered a performance regression with instancing (also reported here https://devforum.roblox.com/t/roblox-critical-metal-graphics-mode-on-mac-cause-drops-in-fps-to-rendering-many-parts) that was affecting both part instancing (that was enabled for ~1 hour last week) and mesh/csg instancing, and was only impacting NVidia GPUs on Mac. This issue has since been fixed, so on macOS/NVidia mesh & csg parts should render faster now

  4. Part instancing and levels with really high part count
    The initial release of part instancing uses “dynamic” instance data submission - the data for each part that describes the visual appearance of the part is uploaded to GPU every frame. This works fine for levels with reasonable number of parts that are visible - e.g. 10-20k - but starts hitting performance issues for really aggressive scenes e.g. 100k visible parts. We’re working on a change that, on a per-cluster basis, caches the part instance data in GPU buffers and updates those. These updates should be much faster than the reclustering operations that could happen in the previous system, which hopefully should make the new system work well even on levels with millions of blocks.

30 Likes

Will the live time CSG on the roadmap work with instancing as well?

2 Likes

Yes

I tested this out with CloneTrooper’s mod manager and it’s amazing. Parts no longer vanish at quality 1. Can’t wait for its official release!

8 Likes

We’ve enabled part instancing again :slight_smile: on desktop (PC & Mac) and in Studio. We don’t have any known bugs and performance should be good in all cases - the issues I’ve mentioned with levels with millions of blocks have been addressed. Don’t hesitate to let us know if you find any rendering issues or performance problems with the new system.

We’re planning to roll this system out to consoles and mobile in the coming weeks, with the exception of Android where instancing isn’t currently active unless your phone has Vulkan support. We have a plan to ship mesh/CSG instancing on GLES3 Android devices, but it’s likely that part instancing will only be active on Vulkan devices on that platform for the remainder of this year.

5 Likes

I hate to potentially burst your bubble but could this bug be related? It popped up within the last hour.

2 Likes

We don’t have any known bugs

This sentence is now false :frowning: We’ll take a look at both issues. FWIW as a work around for special meshes disappearing, you should be able to increase the size of the part they’re attached to until the bug stops happening… edit oops I got it wrong, we don’t actually use part size for this… I think there might not be a good workaround for this, so we’ll probably need to disable this.

3 Likes

Awesome, thanks for all the hard work you guys put into this!

1 Like