Add the ability to instantiate meshes with a new MeshId during runtime

[VegetationBush (FartedWayTooHard)]

Currently, it is impossible to create brand-new mesh parts with brand-new mesh IDs that aren’t currently loaded into the game. The current known methods of creating a mesh part with a MeshId are as such:

• MeshPart:ApplyMesh(). This requires you to have a mesh with the desired MeshId within the game already. One cannot use this method to instantiate new MeshIds.

• InsertService:CreateMeshPartAsync(). This method has the exact behavior that can instantiate meshes during runtime. Sadly, this method is restricted to PluginSecurity, and thus cannot be used during runtime.

• Using SpecialMeshes. Special meshes are very difficult to scale to the desired size, as they use the Scale property rather than the Size property, which is relative to the original imported size rather than the absolute size.

• InsertService:LoadAsset(). This method can theoretically work. LoadAsset is able to load brand-new meshes into the game. However, this isn’t viable for some workflows as one must use the AssetId instead of the MeshId to load the asset, have permission to insert the asset (goodbye every toolbox mesh!), and it also comes with a model attached to it.

Creating brand new MeshParts during runtime is important for a lot of systems. Many fully code-based projects must have their MeshParts instantiated beforehand, which causes inconsistency. Animations using code would also require their MeshParts to be already instantiated, which leaves scripts with extra mesh part children.

It seems like there are a lot of existing APIs that can already create meshes with MeshIds not currently in the game. It would be helpful to expose these APIs to be used in normal scripts, such as that in InsertService:CreateMeshPartAsync() and InsertService:LoadAsset().

An alternative class for dynamically changing meshes without the limitations of SpecialMeshes could be implemented, explained here:

Unlock the ability to change MeshId for Meshparts during runtime OR make SpecialMeshes work exactly like MeshParts

As a Roblox developer, it is currently too hard to recreate meshes on the client via serialization/deserialization when the models themselves are stored on the server for performance and loading time reasons as using SpecialMeshes in place of MeshParts results in degraded visual appearance both due to the lack of Vertex Paint support in SpecialMeshes and the lack of a doublesided property, among other things. Being able to directly set the MeshId of MeshParts would alleviate all the above issue…

[xyrafrost]

You might be able to do this with DynamicMeshes once those are out.

Currently, these two APIs exist, which could theoretically allow you to create a MeshPart from a MeshId at runtime:

• AssetService:CreateDynamicMeshAsync(meshId) > DynamicMesh
• DynamicMesh:CreateMeshPartAsync(collisionFidelity) > MeshPart

DynamicMeshes are not enabled yet, so this is still subject to change.

[InsanityFE4R (INSANITY)]

Or… Or… What if you used ServerStorage to store those assets?

[Dekkonot]

I’m not sure that being allowed to make them during runtime is viable because of the collision data that MeshParts need. It might work, but you’d be relying upon the server do to it and then for every client to receive what might be a very large blob of data, which isn’t great.

[VegetationBush (FartedWayTooHard)]

@xyrafrost

You might be able to do this with DynamicMeshes once those are out.

I’m aware that dynamic meshes can be an alternative. It does currently suit my purpose and may be a solution once it releases. It’s not released yet, so we will wait and see.

---

@InsanityFE4R

Or… Or… What if you used ServerStorage to store those assets?

Please refer to this statement:

@VegetationBush

Currently, it is impossible to create brand-new mesh parts with brand-new mesh IDs that aren’t currently loaded into the game.

These are brand new mesh ids. Storing them in server storage has many drawbacks. Firstly, it’s unconventional, and secondly clients cannot access any of the contents. If replicated service was used instead, you’d just have a bunch of meshes loaded in that may or may not be used. The benefit of a coding-only approach is that content is only loaded in when needed; not until it’s needed.

---

@Dekkonot

I’m not sure that being allowed to make them during runtime is viable because of the collision data that MeshParts need. It might work, but you’d be relying upon the server do to it and then for every client to receive what might be a very large blob of data, which isn’t great.

I understand the concerns about data and collision calculations, but, that doesn’t make a whole lot of sense. We are streaming in all the data to the client when they join the game anyway. InsertService can already itself load brand new mesh parts (new collisions, new geometry, new everything) during runtime. This behavior is totally possible. Yielding when creating these instances is expected. An analogous loading method for InsertService’s LoadAsset method could be implemented, in which a MeshId is provided to load a mesh instead of an AssetId to load a bunch of items.

[OnceCrowned]

I need this for an effect in my game. The only other workaround I can think of does not work since VertexColor does not work in the character

[asadefa]

The alleged reason is because for some reason the game cannot handle generating collision data for new meshes at runtime. A simple solution would just be, if a MeshPart has a MeshId set at runtime, it is forced to use Enum.CollisionFidelity.Box. There, problem solved, instead of preventing it altogether.

[tnavarts]

Updating this thread since I saw it get linked again: InsertService:CreateMeshPartAsync no longer has plugin security and can be used to satisfy this request.

[GunsForGuns34]

does this work on the client? I have some uses for this I can think of that would be very helpful to have on the client, 1 of my games is totally client sided so it would be very nice to be able to do an after image effect of the character that works with packages and accessories. and no I can’t use the mesh part head and accessories feature as the game is in R6. Either way this will be useful to make a similar effect possible in my other game that isn’t entirely client sided :3