July 17, 2019 - Auto Migration Enabled
If you open a level in Studio that has Unions or MeshParts in them, they will automatically be migrated to the new system. Publishing said place will finalize this migration, which means you will not need to migrate again next time you open the level.
Migrated places should now load on RCC and Studio even faster. (If they had Unions and MeshParts in them…)
Additional benefits of the new system:
- MeshParts and Unions in ServerStorage should no longer replicate physics data to Clients when joining. They will only replicate physics data if they are moved to a container that Client needs to know about.
- Streaming places with MeshParts and Unions should also replicate physics data more intelligently.
If you created new Mesh Part / Part Operation between 9am to 12:43pm PST on May 13, 2019 you may need to change Collision Fidelity and then back to get collisions to work properly, otherwise everything will collide as Block. Your game instances should be fine as I have kept the new pipeline enabled.
I released a change that should be almost invisible to all developers. It simply changes the internal way that we store physics data for Mesh Parts and Part Operations. This change is only active on Mesh Parts or Part Operations created from this point on, meaning old objects still use the old system.
The new system has the following benefits:
- Faster loading (Only noticeable on large levels that use Mesh Parts and Part Operations)
- Simpler storage
- Simpler architecture (This is mostly for Roblox internally)
I wanted to post here to ask anyone to report any issues they experience experience with Part Operation and Mesh Part physics data loading from this point on.
If you want to migrate your Mesh Parts or Part Operations to this new format, you can do so manually by changing Collision Fidelity to something else and back.