Heya, just a “quick” question. Am making a game where there will be lots of different levels which the player will be teleported to.
This level, for instance, is around 700x700 studs. I hope to have maybe upwards of 50 levels someday.
The walls on this level are made of meshparts - there are probably around 400 MeshParts on this level alone. Part of me is screaming and saying that having that many parts, let alone MeshParts is insane for a single level.
So, to summarize, how many parts generally would I able to insert into the game before there is some kind of “lag”? Do meshparts have a different number? What if it’s the mesh being re-used?
I know there isn’t a definite answer for this.
And finally:
How can I make better walls so that there is both lesser parts, it looks good, and the player can’t see out of the level. (Have considered just a giant box around the map with 6 faces. Is this better, performance wise?)
First things first: Only really use meshes when you need to. (Ex: for special bricks like a cone or something imported from blender)
Second: Union as much as possible. Unioning decreases the amount of parts in a game, and and is much more optimized than just leaving every part separated.
Third: If you don’t want a player to be able to see out of the level, just make a giant box around the map and set it’s transparency to 0. This way, the players camera can’t go through the box. There may be other ways to do this though.
Meshparts don’t cause an extreme amount of lag on their own in my experience, so my response would be that a map like that is fine. The mesh being re-used doesn’t really matter too much either. If you wanted to have less parts in the walls, then I would recommend combining in the program that you used to make them. As for making it so that the player can not see out of the level, I would just add a limit to their view distance.
View Distance Example
Furthermore, if you are planning on adding multiple levels then I suggest using a map changer so that you don’t have multiple levels in at the same time, since fifty levels of this size would cause noticeable lag. Here is a good youtube tutorial I found explaining how to do that (since it would be too long to explain here).
In all, you don’t have too much to worry about in lag for a pretty much low poly map like this as long as you load the different maps in and out, so you should be all set. Good luck on your game!
I found that while using unions decrease part count, it also increases the amount of polygons in the game. From my time in studio I have seen this to be one of the leading causes in performance issues. It does look cleaner in studio, but it generally can add to the amount of lag in the game. Besides that, the other tips were great and I definitely agree!
Are all those side walls the same single MeshPart?
If so, you’re in luck because what the game is doing is actually only loading that one Mesh, and then since all the other parts use the same Mesh, and its already been loaded in, the game just needs to quickly put it on with no expensive call to get a new mesh.
If not, they all look pretty similar? Why not use a single mesh and then scale it up or down as required.
Using meshes is alright, especially if its the same mesh you are using again and again, because the game only needs to load it once. However, if you start to load tons of completely different meshes, you may start to experience issues.
From my experience and what I’ve been told, unioning actually increases performance in games. Many models that I make are unioned quite a lot and I get less frames with separate parts than unions. Might be dependent on the PC, though.
Unioning left right and centre won’t help you. Yes, unions can be useful, but only if used wisely.
You want as small a triangle count in your union as possible, otherwise it will be expensive to load.
Is the part you are unioning going to be moving around? If so, don’t union unless you have to - the Roblox physics engine has to calculate a lot more information because of the triangles in these unions.
That being said, unions have been much more optimised since their first development, and when using them, make sure to configure your RenderFidelity and Collision box as required!
To sum it up, don’t union for the hell of it, sometimes parts are better than unions
Meshparts are typically good because of the way they load in, having the geometry only loaded once by the server then replicating it (atleast thats what I’ve been told). However, they also have problems loading because they’re based on the website and it can make load times horrendous if the servers are under load. Unions work the same way.
Unions have been having a lot of problems recently with corruption however and I would advise not using them as much as possible. And thus Meshes are the lesser of these two evils.
Being this way, parts should be the way to go when making something like a border. Theyre also optimized to work with Roblox being the main conponent and all. Only problem being the triangle count of these objects, but 400 parts is honestly not that bad.
Meshparts, done right, offer unbeatable performance value in terms of how much detail you can get from a well-designed mesh vs. building something visually equivalent using parts or CSG. The key here is of course the “well designed” part, you can also shoot yourself in the foot by not paying attention to how many triangles your mesh has and using way too many in all your meshes.
400 meshparts can be fine. 40 R15 avatars in a game is 600+ mesh parts, and there are playable games with 100k+ parts in them. But you can’t make a rule of thumb for meshparts using part count alone: 400 meshparts that are 10k tris each is different than 400 meshparts with 4 tris each. 400 unique meshparts is very different from 400 instances of only a few unique meshparts, both for downloading time and for graphics memory usage on systems that support geometry instancing.
What you’ve done with those map border rocks is no problem at all, especially if they are all copies of the same rock (or a small number of variations). Set them to box collision fidelity since they’re as near to boxes as makes no difference, assuming you don’t want players climbing them or care how it looks if they do.
Let’s first establish this! More parts, and more unique meshes do not necessarily mean “lag” (Unless they’re moving of course). It just means a longer load in time for the client to render in all the game assets.
Both are made by triangles, a standard roblox part is 12 triangles.
A mesh part can be anywhere from 12-10,000 Triangles (As of 3/4/19)
Now to clarify, meshes share the same mesh ID. Meaning if one of your mountain meshes upload and render, every other mountain with the same ID would also.
Is it ok to use meshes in great abundance?
Yeah!
100 of the same meshes that are properly optimized would be far better than 100 of the same objects created by either parts or…unions.
You can delete faces that you don’t intend the player to see, use the same mesh and simply resize it, disperse your meshes equally, instead of making seperate meshes for different colors vertex color it directly onto the mesh (You can still apply materials, don’t worry)
Studio is not a 3D Modeling software and shouldn’t be treated like one. For someone to make a CSG car with perfectly smooth edges would take hours on end whereas it could be done under an hour on any 3D Modeling software. Besides, CSG even though has been refined will never compare to hand placed topology of well made meshes.
From my experience with a low end laptop and some testing in studio Unions can be very unpredictable… Even if you union two parts they could be ever so slightly off after unioning (floating point errors) and increase the polygon count by a huge amount. Basic parts vs Unions are probably the way to go but MeshParts sit in the middle since they are more optimized and more predictable.
Edit (I didn’t really give an explanation):
Parts will only have two triangles per side (12), wedge parts have 8 triangles, trusses have a lot, and spheres have even more. Using the same type of part a lot barely impacts performance on a low end device, but the more triangles that part has the more impact it has even with part instancing.
A pretty easy solution to floating point errors in Unions is to export your parts as an obj file and use Blender to convert them into a single mesh for use in Roblox. If you want to get into Negating it gets more complicated though.
Both meshparts and parts/unions rely on tri (number of triangles/faces in a model). Unions can either be less or more laggy than meshparts, depending on the facecount of either or.
With a map like that, I’m sure it’ll be good with meshparts (unless if you have a high amount of extra faces)!
Unless you want to create a detailed terrain hard for Roblox, blender isn’t totally necessary. Normal Roblox parts are fine with this type of wall.
Now it does depend on the user for the lag. Overall it shouldn’t lag. Another problem with using meshes for this type of terrain is it could cause a user to float over it (this depends per mesh). The more unnecessary meshes you use the harder it is for lower quality users to play. 400 meshes shouldn’t effect it a ton. Meshes do cause more lag than normal parts.
Unless you didn’t texture the mesh, it’s more time consuming to re-texture for every single color.
Tell me if this helps or if you have any questions! Looking amazing so far!
