UPDATE - 2021
This post is slightly old now so some information on the topics discussed may be out of date or incorrect. Another post may come out at some point updating this information but this is something to keep in mind when reading this post as of now.
________________
2008. The year where games on the small but relatively ambitious platform “ROBLOX” were the simplest they could get. With limited development resources, many developers were confined to the basic brick and pre-made meshes that co-existed around those times. Yet even at those times, we managed to create innovative builds at that time, even some that are still critically acclaimed today.
Flip forward a few years, and this limitation that we were bound to is gone. Not only are we able to use bricks and meshes, but we can upload our own meshes now. CSG now exists and suddenly the quality of our builds has increased thanks to precise building tools. However, as more features are added and used in a game, the more prone it is to performance issues.
That’s where you come in, the reader of this article! With your help, we can save the World of Robloxia from poor habits of new, by remembering where we came from.
But how can I optimise my builds to be less performance heavy?
Well, it’s actually much more straight forward than you think.
There are a few areas of the game of which the part would consume memory from:
Rendering of the part (What the player sees)
The Physics of a part (How the external environment can interact with the part)
and finally
The Texture/Material of the Part (The Material that the parts hold, and the textures on that part)
I will go into a few of these areas in depth for you as well as provide you a few tips, on this guide!
Textures and Materials
So you may think that textures might only account for a tiny portion of memory, but having too many in one place can be a painstaking job for the server, but for the player too.
Fun fact, did you know that:
“A brick with textures on all 6 sides is roughly 7x more expensive to draw than a plain brick with a material. ”
This means, that for every part that has a decal or texture on every side, the server will have to do 7x the work and memory you’d need for a normal part. This is because Decal’s and Textures have a transparent backing, so having additional or unnecessary textures on a part will mean the server has to render the original part, then for each side, render the texture on top of that part.
So wait, does this mean that I can’t use textures at all!?!?
No no no, that’s not what I’m saying! Textures and decals are a great tool and you should definitely use them where necessary, but when you don’t need to use them, you should avoid them. An example of this is shown below.
As you can see, on the left, it’ll take more time to load up and more time to render than it would than the right object, which has less textures.
Optimisation involves not taking out detail, but trying to abstract anything un-necessary. A possible application of this method is on building props that can only be seen on 3 sides or 1 side.
Meh, I can live without textures, I’ll just use materials instead!
Well, that can be one method for reducing your memory usage, but you should still try be wary with what materials you are using, particularly Neon and Glass. These two are the most consuming of them all, due to their abilities to warp what you see through or glow so bright you burn your eyes. While I love using these both, don’t use it in excess.
Does part count really matter?
This is a question that a lot of builders ask themselves everyday. It can be difficult to judge it, however this really should come down to what type of game you want to make. Do you want a cartoony map with block like houses? Use lower poly models and a simple building approach. Or maybe you want a highly immersive RPG, if so, add a few extra bricks on those walls. Maybe you want to be really ambitious and build the eiffel tower!
A Roblox Eiffel Tower built by legoseed | The Eiffel Tower - Roblox
So what your saying is, the quantity of bricks you use shouldn’t matter
Brick count does matter! It is no doubt that if you put too many bricks in your game at once, you will most definitely crash your client! If you happen to love creating detailed structures and labyrinths of architecture, here are a few techniques you may find useful!:
Knowing The difference between Parts, Meshes and UnionOperations.
There is a massive difference between these 3 of course! One is basic, one is created from the basic object, and the other is something made outside of Roblox (imagine that omg). However, what separates them a lot in my eyes, is how much memory they use.
Basic parts have a low efficiency rate per unit of detail as they are a simple object and usually there are alot involved in one space. Their physics performance is probably the best out of all of the others. However, this is assuming that they aren’t squished and welded all together. If they are, then that is gonna cause you a few problems.
Union operations have a medium efficiency rate per unit of detail, because it gets a little bit more complex from the original part. It has an identical physics performance to Meshes.
Meshes have a good efficiency rate per unit of detail, and can be good as you can optimise meshes efficiently in a program like blender. The physics performance is also identical to meshes.
In the end, you should always make sure you are using your memory efficiently by using the Performance Analyser and test which object type would be better for one thing. You may find that some 20 parts structures might lag less than a union or a mesh part, or vice versa. Sometimes, if your pushed for time, it might be better to sacrifice a bit more memory in favour of your time constraints, but try to be efficient and at least make the majority of your game smooth.
ie. unioning instead of meshing would probably be fine if its last minute or something similar, just don’t get into a habit of doing it often.
(thanks for reminding me to clarify this @Aotrou)
But Mario, I thought Unions were bad!?!?!
They can be bad if used in large quantities, in a small space, and especially if those unions are complex. When I use unions in details, I always attempt to set the CollisionFidelity to hull, so that way it simplifies the touch area around it. Better yet, you can set it to box, and simplify the collision area to a box region round the union(similar to a part). You might find this useful with meshes as well, but only use this if your union isn’t going to be touched. If it is likely to get touched, and is causing lag issues, you should try and optimise it more or switch to a part based/mesh based alternative.
What about CanColliding my parts?
Sorry everyone! This is another myth that was almost waiting to get busted! CanColliding parts will only have an effect on moving objects within close proximity. So if you had details on a building that the player could reach, you should can collide false them and put a hit box instead, but if the player would be unable to reach them, it wouldn’t necessarily matter either. zeuxcg actually lead a really nice talk on this at RDC 18 so heres the link.
Optimising Terrain
Terrain is actually not as bad as you think when it comes to memory consumption, but there is a catch.
How does terrain work, what is a voxel?
Voxels represent points in 3 dimensional space, that hold key information about that grid like area. For example, in terms of Roblox, a voxel would hold the material that the specific point should display, and an occupancy which shows how much space around the centre a voxel is occupying. Using these voxels, a contouring algorithm is used to generate polygons on the surface, and each voxel relies on a nearby neighbour to connect up with.
Photo from blog.roblox.com demonstrating terrain with similar occupancy data but different materials.
Memory wise, like anything, you will eventually run out if you use mass amounts of terrain. However, by removing redundancy, we can prevent simple things like terrain issues from causing issues.
What do you mean by redundancy?
Keeping in mind the above, we can tell that it would be better to have simple terrain in an area that detail wouldn’t matter as much in, than an area that isn’t seen as much but has a high level of detail. However , there are certain instances where this might work and others where it might not. You should always consider with anything whether you actually need it and whether it’ll have much impact.
So what areas of my build should I make redundant?
Roblox’s system is built for optimisation, so you’ll actually find that having a filled out mountain in comparison is likely to be better.
To test this theory, I generated some mountain terrain (using Roblox’s tools), and I recorded the memory it took up first, then I hollowed out the outside bits that the player wouldn’t necessarily interact with.
On the left, you see a roughly hollowed out terrain using Roblox’s erosion and region tools, and on the right is plain generated mountain terrain. This is all shown from one side at the same position.
As you can see, the left one clearly takes up less memory. This is because alot of the un-necessary areas below were removed, and less voxels were needed. However, this is in no way shape or form optimisation . This can be very different for all kinds of terrain and while there might be a drop, hollowing out too much of areas of your map can actually be the cause of excess memory.
After experimenting a bit further on the hollowed out version, you’ll find that using the hollow tool alone will cause you to create more detail than necessary, increasing the voxel and physics memory up to 3mb and 5mb.
So what should I do to make my terrain better?
Personally, I would try to use the Performance widget, and monitor Terrain Physics and Voxels. This is a great tool that you should use to manage whether you could improve on your memory consumption, and will prove especially useful when calculating whether terrain is being utilised well. It is also good to monitor textures, animation, physics and other things that might have an impact on memory.
What about the materials that a part holds?
You’d be surprised! Terrain actually doesn’t have much impact on memory, so you should use a variety of it when building. The only exception to this, is water, which has a slight difference in memory consumption, but you should try and use that too!
Transparency, the hidden devil of performance
Lots of parts with varying transparencies are bad for performance. This attribute of a part should be used scarcely and you should either stick to Transparency 1 or 0. However, how are you meant to get a glass like effect without having a transparency between 1 and 0, while maintaining performance?
The answer is actually use less parts . There’s no way to fix how much memory a window takes up, only how many parts there are in the window. By optimising the number of parts in windows (or by merging parts to create 1), you actually reduce the work the server has to do, as they only have to render 1 part over multiple parts.
On the left, we see 3 glass parts taking up an area, when it could just be 1 glass part.
Most of all, AVOID PUTTING DECALS AND TEXTURES ON FULLY TRANSPARENT OBJECTS . According to Zeuxcg, it can cause a lot of issues for mobile performance and wouldn’t be an ideal option in a day of age where cross platform compatibility is becoming the norm.
Conclusion
Thanks for reading my first learning resource post! I hope this’ll help you. In the future if there is anything that I come across that may be of use, I’ll try and update this as much as I can. My personal tips at the end of all of this are:
- Avoid Texture and Decal Redundancy
- Use Performance and Memory Statistics and the Developer Console to monitor in-game and studio memory usage, so you can make an accurate decision on what needs optimising
- Be careful with your usage of semi-transparent objects.
- Use a variety of parts in your builds , specifically where one would be better than another.
- Abstract your builds where necessary.
If you guys like watching videos, here’s the panel on“Designing for Performance” at RDC 2018. I used it to fact check some of my things, and also has some information on other analysing methods, scripting optimisation and more! Go check it out.
. Ultra useful, bookmarked, shared, and going to be used!
