I’m sorry, if I am posting this to the wrong place, but I have a question about Weld and WeldConstraint. I read the documentations and searched online, but I couldn’t find any answer.
For example, I have a push and pull door, without scripts, using HingeConstraint and DragDetector, and I want to add a door handle.
The door itself (the moving part) is a union, so it is just one piece and it works. When adding the door handle and its details, how should I weld the door handle pieces to the main moving part, so that I would get the best performance. Should I do it like this (there are door handles on each side of the door):
I may be wrong but this looks like a case where its impact on performance wouldn’t be meaningful. I would do it in whichever way is easiest for you and gives you the best workflow if you ever need to make changes. Personally, the second image looks the most intuitive and easy to understand, but performance should be negligible.
Hello! Very nice post, but I’ll add here a little tip not many people know
If you inspect the default brick model on blender, you’ll see it has an unnecesary ammount of vertex for a something that has such a basic geometry (image below)
Primitives (blocks, spheres, cylinders) from Roblox don’t have to be downloaded at run time but this blender block would be. Waste of memory and waste of loading time.
Roblox primitives are pre-downloaded meaning they load instantly in game. A MeshPart, no matter how basic its geometry is, will have to be downloaded from the website.
If a client has slow internet and your game has many unique MeshParts (different IDs) then you’re going to slow it down even further for no reason.
Ain’t no one is going to do like Entry Point dev and design their levels using primitives, besides even then you still have to model some stuff like weapons and other complex things and also textures (unless you use built-in ones) are require to be downloaded from the website (unless they add a option to make an asset be persistent so it will only download it first time the player joins but loads it from cache even if they close the roblox application) but most of those complex games utilize Meshes so Primitives can’t solve that. You’re best bet is to put it in workspace (so it tries to load it when the game first starts) or utilize ContentProvider.
Even built-in assets take some milliseconds to load that asset, it just because they are pre-installed and thus local it seems it’s instant when in reality it’s not as the engine has to allocate resources to load that asset
The person (who you responded to even) was saying to use a MeshPart that has a geometry identical to a Roblox primitive. This has nothing to do with map creation, style, textures, or complex object shapes.
I was pointing out how their “performance booster” was a drain on users with bad network and useless.
The quads of the Blender cube will have to be converted to Triangles anyway. Besides using the built-in Roblox mesh is more efficient than downloading a custom Blender mesh into Roblox.
Regarding the second parameter of Instance.new(): Strictly speaking, using the second parameter of Instance.new() is not what makes code slow over setting the parent in another line. The issue is when the parent property is set FIRST, then all the subsequent property changes have to be processed by ROBLOX, replicated, etc. but when the parent property is set LAST, then much of the redundant work is avoided.
Using Instance.new() with the second parameter is not a problem if you will not be changing any of the properties immediately afterwards (e.g., Debris:AddItem(Instance.new("ForceField", Character), 10) ), or if the parent is already not a descendant of game.
Using the recursion of :FindFirstChild is perfectly reasonable, there’s no reason to use a for loop, since you’d result with the exact same stuff as if you were to just print what :FindFirstChild returned.
There’s no reason not to use it, however, if you’re really that against :FindFirstChild with recursion, there’s also :FindFirstDescendant("Name")(it might still be a beta feature, never can remember what is and isn’t these days)
Turning off CastShadow does not improve performance.
It literally says in the roblox documentation on basepart: “Note that this feature is not designed for performance enhancement. It should only be disabled on parts where you want to hide the shadows the part casts. Disabling this property for a given part may cause visual artifacts on the shadows cast upon that part.”
There’s no way that disabling the feature on parts that don’t need it isn’t helping performance. It’s probably a micro-optimization but it doesn’t mean it doesn’t help.
As far as I know using RunService or task.wait() instead of while wait() do while task.wait() do or wait() doesn’t improve performance, and i think in some cases it might decrease performance. And no I’m not discouraging RunService and task.wait() and infact I do encourage using RunService and task.wait() but not always. I still use wait() even tho I know about task.wait(). If you just your code to yield for a certain amount of time then use wait(). You should use wait() for lower priority stuff and task.wait() for higher priority stuff. Correct me if I’m wrong.
Something worth noting. Sometimes if you want to un render something, you can simply set the CFrame to a large number, roblox will automatically un render the item without reparenting it (parenting does cost performance). Though this has very specific use cases.
