Hello! I’m TheFuzi. I’m working on a battle royale game and I’m currently working on trees. I’ve recently noticed that the mesh I uploaded doesn’t show up.
Here is how it looks in studio/website:
No , it doesnt. Also , I actually figured it out. Placing the meshid into a meshpart wasn’t working. I’ve had to place a specialmesh into a meshpart and insert the id into it and after that it started working.
That shouldn’t be the case. Also you should be able to directly upload the mesh from studio which should be using a local copy even if it wasn’t moderated. It simply wouldn’t show in game until it was done with moderation. Also why are you manually using the ID? You can go the game panel and look under meshes and insert the entire mesh there… Normally you can have multiple meshes selected and insert it at the same time so you don’t have to re-position it.
The way you did it doesn’t really solve the root of the problem, it just “works”. If it keeps happening I would check and see if I can reproduce this problem and make a bug report.
On occasion, a just-inserted mesh will not render. Closing and re-opening studio usually resolves this. When you add a new mesh in Studio, it actually uploads it to Roblox and then downloads it back to your computer using the newly-created contentId, so there is possibility for some race condition where the mesh for the contentId isn’t quite ready to download the first time it tries. Studio does not read the FBX or OBJ file from your local drive right into memory as you might expect. The reason you can see it before it’s moderated is because you’re the owner and have permission to fetch it, not because it’s already local on your machine.
A good test would be to disconnect studio from the internet after its open, and try importing a mesh. Though I’ve never had issues with mesh not rendering. I’ve had issues with decals and such. But as you said restarting studio fixes that issue. It just doesn’t make sense to download a local copy when you have a local copy. That’s why they say the mesh might not appear in games, but I do believe it’s using a local copy of the mesh. From a programming point of view it’s redundant to upload and then download the same mesh. Especially when you have a platform this big, you’d want to save on both bandwidth for the user, and bandwidth for the infrastructure. Roblox server upcost isn’t free ya know.
Edit: When you use mesh IDs however. That does download a remote copy of the mesh.
One extra download is insignificant. Because the local cache expires, you’ll download your own game’s assets thousands of times over the course of developing a game. But if the game has players, even your own downloads are insignificant compared to the many millions of times the asset will be downloaded overall.
More importantly though, fewer code paths is better. You get the asset through the same pipeline as any player, so you know if the upload worked (and are not potentially fooled by a good local copy and failed or corrupted upload). And fewer code paths ultimately means lower maintenance and less chance for bugs from things getting out of sync.
Typically you’d only use the local copy for the first upload. That first mesh part is what uses the local copy if you were to place the meshpart and select the meshID which would then open a file.
If you used bulk import that would upload it to studio, and then when you insert it do so from the meshID afterwards. Though it still uses a local copy. I’ve removed the meshes from my game completely including my inventory and they still load in studio with no issue. Though if you were to playtest they wouldn’t show up. The mentality that one extra download isn’t significant with a platform this big with the millions of other downloads happening across thousands of games… is actually significant. I would actually argue that there isn’t a local cache for local mesh’s. As the local cache would be the files themselves. And even if they were to become unreliable only then would you reference the remote copy.
This is still further backed up by meshes being seen in studio directly after import. As well as when you click on the mesh ID it references the local file, and not the remote asset ID on the website.
What exactly are you talking about? What local file? There is no file created when you click the folder icon associated with the MeshId of a mesh part and browse to import an FBX or OBJ file. Your file is read, serialized into a binary string in memory and POSTed to Roblox’s webserver. Studio gets an HTTP response with the assetIds generated for it (mesh, and texture if there is one) and then downloads the assets from Roblox’s CDN. If the part fails to download (e.g. not ready, or auto-rejected for some reason) you get an invisible part and a message in the Output window like this:
I got this invisible part and message, despite the FBX file being on my local drive and there being no problems with it.
And a one-time developer download is insignificant for something that will be downloaded millions of times. It does not make sense to write and maintain a code optimization for the first time something is downloaded when you anticipate it being downloaded 1 million+ times. You write caching code instead, so that you reduce bandwidth by a factor of 100, rather than by a factor of 1/1000000.
You’re right about the local meshpart. I was referring to this menu. Which references the file you’ve uploaded. As you can see it’s not for meshes but for textures.
I’m aware of what a cache is by the way, I just see no reason you wouldn’t be able to directly cache the local copy instead of doing this “one-time developer download”. At least this isn’t the way my back-end infrastructure works. I saw hints of the same method being used and wrongfully assumed that was the case.