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 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.
Your mileage may vary, but we had an internal benchmark place that is a MASSIVE level with lots of Mesh Parts and CSGs that was taking 34 seconds to load, drop down to 17 seconds or less, but that 17 seconds includes other things that it was loading that we didn’t optimize.
If you isolate Mesh Parts and Part Operations the improvements were anywhere between 4x to 3x.
Basically it depends on how many Mesh Parts or CSGs you were loading to begin wish.
Unfortunately not, but it only should be enabled for any CSGs that have had their physics data reprocessed as of this morning.
Do these changes also apply to live time csg? It seems like that has been ignored since it was released as well as ignored by most developers. I’d like to use that during the summer but it takes a good bit of time to load from the server to clients so would this new update reduce that render time or is that a networking issue?
Something not being “supported” doesn’t say much on whether you can or can’t do it.
Edit: Since my last post got flagged ill just stick it here.
tl;dr if my post was: Promoting exclusively long term solutions and not discussing short-term solutions is awful. We can’t wait 2 years just for functionality to be added in Studio. Let the developer decide if they should be or not be messing with it. Everybody is prepared for short-term solutions to need adaptation with updates.
You should not be messing with custom file formats because they capable of changing without any announcement or warning.
If anyone needs to inspect the contents of an .rbxmx for any reason, this implies that either there is some functionality missing in Roblox Studio, or they are doing something they absolutely should not be.